E pur si muove

Python modules and the GPL: I still don't get it

Tuesday, November 03, 2009

I've never understood if you can use GPL python modules (or packages) in GPL-incompatibly licensed code. Today I re-read the GPL looking for this and am tempted to think yes, you can. The GPL says:

1. You may copy and distribute verbatim copies of the Program's source code as you receive it [...]

This is simple enough, what if you need to change it? This gets more interesting:

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, [...] provided that you also meet all of these conditions:


b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.


These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

As I uderstand this it means you can happily ship a GPL python module next to a GPL-incompatible module, even when the second uses API calls from the first. As long you are always offering to give the source of the GPL module, including modifications if you made any, you are fine. The two modules are individually identifiable sections and can be reasonably considered independent and separate works, or so I reckon at least.

But wait, the non-GPL module uses the API of the GPL module, is it still independent and separable then? In my humble opinion the GPL says it must be reasonably considered independtent and separate, so yes. It's feasable to take away the GPL module and replace it by another one that offers the same API, hence I would argue they are separable (feasable and easy are not synonyms!).

According to my reasoning it should also be legal to use GPL C libraries in non-GPL programs as long as you use them as shared libraries and not as a static library. But why does the Lesser General Public License (LGPL) exist then? Qoting the the LGPL preamble (emphasis mine):

When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library.

Now a shared C library is linked by the dynamic linker before the application gets started. If the library is not present the application will fail horribly, I guess this is why they consider it legally speaking a combined work. When using a python module the python interpreter will happily start and depending on how the application is written can fail gracefully or even provide partial functionality.

The GPL FAQ argues that it depends on the technical means used to run the final application whether the modules should both be GPL or not. The arguments seem to suggest that if code runs in shared address space as GPL-licensed code, then the whole must comply to the GPL. Given that translation of a work is considered a derrivative we can assume python translates the python code (interprets it) and then executes the results in the same address space, therefore all must comply to the GPL (including python itself).

I'm still hard pushed to call the non-GPL module a derrivative work of the GPL module however. And in a lenghty article (apparenlty written by real lawyers, definitely worth a read!) the authors argue that legally it depends on a lot more then the technicality to determine if a work becomes a derrivative work or not (and that's where it all revolves around: if its a derrivative and you distribute it the GPL applies). This does indeed seem a lot more logical: imagine you accept the interpretation in the GPL FAQ, all you need to do to distribute the two modules is use pyro or some other form of inter-process communication (excluding shared memory according to the GPL FAQ, this again I find hard to accept) and use the APIs of the modules over this IPC layer.

The above article describes how some courts have judged this derrivation question and gives a couple of pointers itself. Essentially it common sense, but that's hard to qantify as even the GPL FAQ fails. I should really summarise the factors in a paragraph here, but I was formally trained to be an engineer and not a lawyer so am not used to summarising lawyer articles (and frankly I'm too lazy to perform the exercise right now). Beside I'd probably skip a lot of subtle points so you're best off reading the article yourself.

I do have a conclusion however: if you have a python module which is not GPL-compatible but uses the API of another python module covered by the GPL chances are you are fine if: (i) you are not taking away market share of the GPL module. And (ii) you are not derriving or extending the creative work or copyrightable content of the module. But there's no distinct line, common sense is your friend (and enemy).

Tuesday, November 03, 2009 | Labels: |


Winni said...

I'm afraid that there's a lot of wishful thinking in your train of thought. Just look at how strict MySQL AB, now SUN, handle the "community edition" of MySQL. According to their interpretation, you are even creating derived work when you write code that implements their protocol to communicate with the MySQL server. Read again: When you implement their protocol specification in your own code, you are forced to put your work under the GPL - or purchase a proprietary license.

Now your example with two modules that are calling each other is even simpler: Your non-GPL module clearly uses and requires the GPLed module, thus the GPL very clearly forces you to put your own module under the GPL as well. There is no discussion about that, I'm afraid.

The only way to use GPLed code in your own application without having to GPL your own software is when the GPLed code is running as an own independent process and your own app only communicates it via some communication layer. (Unless, of course, somebody like MySQL tells you that even that approach forces your work under the GPL.)

Unfortunately, it all comes down to this: If you do not want to put your own work under the GPL, avoid GPLed third party code/modules/software at all costs.

LPGLed or MIT/BSD-licensed software is a completely different story.

Anonymous said...

You are misreading the GPL license.

Any code that makes use of a GPL module must be GPL as well if you choose to distribute it to someone else. The whole shared/dynamic issue is meant to clarify non-obvious use cases of the library.

In python when you import a module it is clearly obvious that you are actually using the module in your program, it is loaded among your modules after all. So don't

Other way to say this is that you may not mix GPL and non GPL code if this latter license does not allow you to relicense it under GPL.

Anonymous said...

What's not so clear is whether importing GPL'd module and calling their API is by itself a copyright violation. If this use does not infringe on the copyright of the GPL library authors, then the GPL DOES NOT MATTER.

The GPL grants you extra rights in cases where you would otherwise be infringing on someone else's copyright. If you don't infringe, you don't need to adhere to the GPL's requirements.

Now, I've read in a few places that simply using a public API has been tested in court and found to not infringe copyright. (but IANAL and can't cite any refernces on this). If this is true, it renders the GPL worthless as a means of restricting the commercial use of python code.

Paul said...

Anonymous #2 writes, "The GPL grants you extra rights in cases where you would otherwise be infringing on someone else's copyright."

More or less true. By default, you don't have the right to redistribute a copyrighted work.

"If you don't infringe, you don't need to adhere to the GPL's requirements."

You have this backward. If you don't adhere to the GPL's requirements and have no other licence to redistribute the work, then you infringe by redistributing that work.

There appears to be two arguments in this article: that by writing something that only uses a GPL-licensed module, it's not a derived work; that Python modules are only loosely connected to each other and don't "affect" each other's licences.

In response to the first argument, it should be noted that various large Free Software projects have licensed their works under the LGPL, but have been obliged to also license those works under the GPL when linking to GPL-licensed libraries. (This actually demolishes the "FSF are telling me how to license my code" argument, since the same code can be licensed purely under the LGPL if linking to LGPL-licensed libraries.) So, the consensus is that a system which relies upon and links to GPL-licensed libraries must be licensable under the GPL.

See this FAQ entry for the FSF's position:

They mention "the program as it is actually run" specifically.

In response to the second argument, the FSF believes that if the library code gets to live in the same address space and shares data structures, then the running code is a derived work:

As always, you have to look at what the GPL tries to achieve in order to understand the intent of the licence. If a program uses GPL-licensed code, the intent is that the user should be able to receive the source code for the entire running system and to be able to modify, run and redistribute the result.

Anonymous said...

python has special licence and is not GPL

New comments are not allowed.

Subscribe to: Post Comments (Atom)