It seems they're mostly trying to avoid a license-dilution problem, where there'd be 50 incompatible versions of the GPL floating around confusing everyone.
It seems they're mostly trying to avoid a license-dilution problem, where there'd be 50 incompatible versions of the GPL floating around confusing everyone.
This is clearly in reference to the LICENSE DOCUMENT and not the LICENSE ITSELF.
Forgive the shouting, but this situation seems childish anyway.
I've said before that I would be fine with a "DERIVATIVES UNDER DIFFERENT NAMES" clause, but that's not how I interpreted the clause absolutely no training in law.
I think you've got it right there. A cursory search of Wikipedia shows parodies may fall under fair use, never mind the copyright notice: http://en.wikipedia.org/wiki/Parody#Copyright_issues
(In theory, the reason EULAs work is because when you run the program, you are copying it from disk to RAM. This is why they are believed to be very shaky, as copyright law does not specifically consider copying from disk to RAM inside a black box to be "copying".
The GPL is on firmer ground, because it covers copying for distribution to other people. That is a situation that copyright law is specific about.)
This is exactly why people like me get confused about such things. From the little reading I've done I tend toward the "copyrights sound like the solution, and everything else is a twisted interpretation of that" point of view, but I'm only well read enough to know that I'm not well read enough to have an actual opinion.
But you are not allowed to modify an existing license document someone is already using with their code.
Granted, that's not the first time this conversation has included the (to me) specifier so I may be in the minority on the amusement on this one.
I can't release MIT licensed code that links against a GPL'd library. That's a pretty huge incompatibility if you ask me.
I can't release MIT licensed code that links against a GPL'd library. That's a pretty huge incompatibility if you ask me.
Of course you can. The belief that the GPL is "viral" or can somehow infect unrelated software is spread by groups opposed to widespread creation of GPL'd software.The GPL is a copyright license. It applies only to cases covered under copyright, eg, distribution of the original and derived works. This means you can release code under any license that links to GPL'd code. If you create a derived work (eg, compiled binary) from both original works, you'd need to abide by the terms of both licenses.
For example, say you have an application under the MIT license, and you'd like to support a GPL'd library. The resulting license tree would look like this:
MIT (app code) GPL (library code)
| |
-------------------
|
GPL (app binary)http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibrary...
Does mention "or compatible license".
And I'm really confused about dynamic languages that aren't explicitly compiled before distribution.
The FAQ entry deals with derived works (eg, compiled binaries). If your code's license is not GPL-compatible, then any work derived from both your code and GPL'd code cannot be legally distributed -- for example, it is illegal to distribute a binary which is statically linked against BSD-4 and GPL code. The ability to distribute binaries is why GPL compatibility is so important.
This applies to dynamic languages as well. Python or Ruby code can be distributed under any license the author wishes, but works created from a combination of that code and GPL'd code must be covered by the GPL.
For example, say Alice creates a Python library libalice and publishes it under the GPL. Bob writes an application BobApp which uses that library, and publishes it under the X11 license. Charlie uses py2exe to create an easily distributable version of BobApp, which includes a private copy of libalice. The licenses are:
libalice: GPL
BobApp: X11
Charlie's BobApp.exe: (GPL + X11 + Python license) -> GPL
If you'd like, you can think of licenses mathematically: license(foo + bar) = license(foo) + license(bar). If the licenses are compatible, then the strictest license is used for the derived work. If the licenses are not compatible, the derived work cannot be distributed.US copyright law, fundamentally, is not complicated. The hard part is figuring out what "derived work" means, which depends on local laws and customs, and which you need to be a lawyer to figure out. Luckily, most cases involving software are very clear-cut, so even lay-people can get by with just a copy of the relevant regulation.