There has been lots of interesting discussion about dynamic languages and the GPL, but much of it seems to miss the main point: with many dynamic languages, the terms of the GPL are an irrelevance.
In the comments on the above page, Peter Gerdes seems to be one of the few who does get this:
@Morty Yidel
It doesn't matter what the GPL says in situations 2 & 3. What matters here is copyright law.
The GPL is a license that lets you create and distribute copies of certain software. You are only bound by the terms of that license when you need the license as a matter of copyright law.
In 2 & 3 you aren't distributing any GPLed software thus you need only abide by the GPL if it is a derivitive work of a GPLed program. As I said that's a complex question but it's one that can only be answered by looking at copyright law and precedent not the GPL. Moreover, if merely using an API makes your code a derivitive work of the library servicing the API it's hard to see how programs like WINE aren't infringing.
If someone wants to apply the terms of the GPL, they first have to demonstrate something that would otherwise be copyright infringement. As the GPL (v2) says:
5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
So, if I sit down at my computer and type (for the sake of argument):
echo 'import qt' > test.py
and then distribute test.py, have I created a derivative work of Qt (or any other GPL library)? Since I could type all of that without having a drop of Qt source code on my computer, I'd argue it's pretty difficult to say that this is a derivative work. Of course, once I go further and actually start using more the API than just the name 'qt', there is the chance that someone important might decide that by virtue of my use of an API, the program constitutes a derivative work of the library. (If they did, that would have huge implications — every Linux program, not to mention Linux itself, would become a derivative of Unix itself, for example, because it uses Unix API's, and every Win32 program would be a Windows derivative...)
This, of course, is completely different from C/C++, where in order to compile an executable, the compiler #includes parts of the actual source code of the library into the executable, thereby automatically triggering the need for an exemption from copyright laws.
With Python and Javascript, nothing of the sort occurs for the user to get the developer's software. If the developer decides to test their program before distributing, they may well need copies of the library code, either in source or object form, on their machine, but that has nothing to do with their distribution of their own code.
Now, the GPL (or whatever), may have terms explicitly forbidding you from finding some sneaky way around the licence, such as dynamic languages or web interfaces etc. But it doesn't matter. The licence could require you to sacrifice your first-born child to the gods of Jupiter for even thinking of doing such a thing, but the licence is irrelevant, since you haven't done anything that would require you to accept its terms.
So, unless judges are going to rule that use of APIs constitutes copyright infringement, all software licenses of this kind are simply irrelevant in this case.
This is one of the things that makes me shy away from the GPL. I'm a really grateful beneficiary of all that it has helped to safeguard, but as it relies on copyright law which may well be completely irrelevant for dynamic languages, it seems somewhat unwise to lean on it for any of my own financial security. More and more it seems that being paid for writing code, and not for the code itself, is the way programmers should make their living. Just because copyright law may have supported certain practices in the past doesn't mean we have a right to that continuing.
Comments §
echo 'import qt' > test.py
but only distribute test.py. To make your point, you should also distribute qt.so and its dependencies. Now part 5 of the license should seem a lot more relevant to you.
Incidentally, you could have written
echo '#include <qwidget.h>' > test.cpp
instead and distributed that, so there's nothing special about interpreted languages in this regard. The only difference would be that test.py may be more useful to some people than test.cpp, and neither is useful without the required libraries.
But if you're not doing that -- if you're distributing something which does not contain any part of the GPL'd code -- the only way to trigger the GPL is by producing a derivative work, since copyright law requires the copyright holder's permission to distribute that. And what exactly constitutes a "derivative work", when multiple separately-produced pieces are to be combined by an end user, is something on which there's no clear legal consensus.
So there's definitely a good point in here
Which argues that if X requires Y to work, and cannot work without it, then X is a derivative of Y, and it does not matter when the linking occurs.
So if your python code requires a library that is under the gpl and not the lgpl then you have a problem. Or the Free Software Foundation thinks you do. Granted this hasn't been tested in court.
You are right about interpreted code not being special, but the GPL kind of assumes that you are going to want to distribute object files. With my Python projects, I never do that -- if I have some dependencies, I would instruct people to get them separately, or have the installer download the latest version.
In fact, even with C/C++, one common way around GPL problems, especially with the Linux kernel and proprietary modules, is to distribute gcc plus source, and have modules built dynamically. In that way you are not distributing anything which is a derivative of the kernel source.
@Konrad:
I'm pretty unconvinced by that argument.
First, if you extend it logically, then you have to say that if any part of your required software stack is GPL (e.g. kernel, OS, shell, web server...) then it all must be GPL, since it is 'required' for the parts above it to work. The only way to stop that kind of nonsense is to recognise that some parts have not been produced by copying others, even though they may share some commonalities (e.g. how they are laying out integers in memory).
Second, my basic argument here is that whatever the GPL has to say about 'aggregation' or 'linking' etc, and whatever the FSF thinks that means, is irrelevant because the licence is not necessary if I haven't created a derivative work. The key issue is whether use of an API constitutes creating a derivative work, and that has to be decided simply by courts, without *any* reference to the GPL or FSF — their opinions count for nothing here.
Don't ask me to justify it in terms of the wording of the GPL - I haven't the time or the inclination - but it's my understanding of the advice the Plone Foundation (of which I'm a member, but not a board member) has received from people I assume know what they're talking about. :-)
Cheers,
Martin
As to the question of the Unix API, the point is there were several implemented systems, so it didn't cause new kernels to become derived works. The Linux kernel does have a specific exception to avoid applications using its native APIs from becoming GPL-covered, which is the reason why they don't.
How is that possible? It would mean that the license model never matters for any python project because the very moment they touch a GPL covered python code ALL their code becomes GPL as well!
By the way: I find this post useful in understanding the reasons for wanting to use the GPL: http://www.contenthere.net/2009/07/apache-software-license-hippo-and-bluenog.html
You can say whatever you want about what the GPL includes inside itself, but *if copyright law does not force the program to be considered a derived work*, something the GPL has *no* say in, then it does not hold the GPL has any power over dynamic programs.
You can of course make your own implementation of the GNU readline API and then link your program against that. But you would have to actually do that, not just say that it's a possibility and then go on using GNU readline anyway.
What are you really saying when you do "echo import qt > test.py" and distribute test.py? Are you saying, "look at this nice GUI library that I made"? I doubt it. To get a workable argument either way your example should be something that is protected by copyright law, and your trivial one-liner library isn't. For some reason I thought of Zeno's paradox of Achilles and the tortoise when I read the rest of your argument...
You're right to point out that when the distributed program (interpreted or compiled) links with the GPL library on the user's system, this now affects what the user can do with it (see below for details), but I was really only pointing out that there's no reason to make a distinction between interpreted and compiled languages, as Luke later points out in his reply.
@luke:
Although your solution of combining pieces at installation time might get round the problem you have of distributing GPL components with your non-GPL code, but there might be other side effects you are overlooking - see below.
@James, @luke:
Although you should talk to a lawyer rather than relying on an FAQ, it's interesting to read some entries from the GNU Licenses FAQ.
These suggest that you have to use a GPL-compatible license for your code:
http://www.gnu.org/licenses/gpl-faq.html#PortProgramToGL
http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
The last one is interesting because it says that, once combined, the user can treat the combined work as a GPL-licensed entity.
If you use a GPL-incompatible license, all bets are probably off. Search for "incompatible" in that document for more details. ;-)
* Real-world example 1, GPL Ghostscript & CutePDF:
GPL Ghostscript is a well known GPL licensed product for working with PDF and Postscript files. It is used widely.
Cute PDF is a product that creates a virtual PDF printer to create PDF files from any application that can print to the printer. It has both free and commercial versions. Neither version is GPL licensed, and no source code is available for either version.
Cute PDF does not include any part of GPL Ghostscript within its code. It does, however make use of whatever version of Ghostscript the user has installed on their machine. The have separate links on their page for the --user-- to download and install at their own choice, allowing the --user-- to accept the GPL license, and be responsible for adhering to it.
* Real-world example 2, Microsoft WIndows & Captive:
Captive is a project that give NTFS read/write support to *NIX systems, using the original Microsoft Windows ntfs.sys driver. Were Captive to include the ntfs.sys file in their distribution, it would be in violation of Microsoft's licensing. To get around this issue, the software is distributed without the nfts.sys file. When the --user-- installs Captive, they are prompted for the location of the ntfs.sys file, on an existing, validly licensed installation of Windows. Again, the --user-- takes the responsibility to accept and maintain the license agreement for Captive and for Windows separately.
Simply having your application --use-- the facilities of another does not mean the same as having your application --include-- or --link to-- another. If it did, Microsoft would have pursued that one in court, and won, years ago.
If you do not include any part of a licensed system (GPL or otherwise) in your distribution, then the licensing of that system bears no relation to yours. It remains separate and apart until action is taken by the person who is --accepting-- the licenses, and using the different system together. Otherwise, --any-- application would be subject to the licensing terms of the operating system it is run on, and that is ludicrous.
Regarding your references to the gnu.org site:
if you read these sections, you will see that they also make reference to plugins where fork or exec are used to call them, as not requiring GPL compatible licensing.
http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF
http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins
You should also note that these same sections use the wording, "we believe" when referring to dynamically linking to a plugin. This implies an opinion on their own part, that has not been tried in the courts, and has no legal precedent. It is only an opinion.
In other words, until someone decides to take a case to court and establish precedent, even dynamic linking after user installation does not carry relevance to the license of the application or the plugin.
The only way it would apply, is if the application license or the plugin license specifically stated under what conditions they may be installed. The GPL license contains no such verbiage, and would cripple itself if it did.
Yes, there's a range of different ways to combine application and "library" code. However, the original example would use dynamic linking, and even the use of a pure Python module seems to me to be closer to the traditional concept of linking than to the use of plugins.
As you point out, the use of linking is a contentious issue for many people, and this is even mentioned in the FAQ:
"Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide."
[http://www.gnu.org/licenses/gpl-faq.html#MereAggregation]
The GPL (version 2) is a little confusing in that it refers to "copying" and "distribution" as separate acts, and although it seems that the act of distribution in this case gets around some restrictions of the license, I would still want to understand what is meant by "copying" in more detail because I imagine that this is the basis for the arguments about linking.
There is evidence that people other than the FSF consider linking, even at run-time, to be an issue. Getting the most mileage out of the example given in this blog, we can look at the need for an exception to Qt's GPL licensing, allowing commercial/proprietary licensees to link against pre-installed GPL versions of the library:
http://doc.trolltech.com/4.3/license-gpl-exceptions.html
This article at the Software Freedom Law Center also mentions the need for GPL exceptions:
http://www.softwarefreedom.org/blog/2009/jan/27/gcc-exception/
Although the reason for needing them is assumed rather than stated, I presume that it's something they have considered in some detail. This article does, however, cover the subject of system libraries and copyleft, so it's interesting in that regard as well.