Python modules, licenses, and more

Today, I want to present you some things I have asked myself and some ideas about them. You should not expect the information to be correct. Therefore, if you find mistakes, please leave a comment.

Copyright statements / Comments

MIT license: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. – If you had a python module released under the MIT license, and this is in the comment of the module and you somehow ship only pyc or pyo files, you would be violating the license by not including the copyright notice, because these files do not contain the modules. This is also true for many other licenses, but this seems to be the best example.

If you include this in the docstrings, you would only violate such license terms if you distribute bytecode created with the -OO option. This also does not apply if the code is a program which prints the license (eg. via a commandline –license option).

GPL vs LGPL

Is there any difference at all? The LGPL requires you to publish all changes you make to the code, while the GPL also requires you to publish source files you have created. This also means that you can’t link a non-free program to a GPL library, but you can link it to a LGPL library.

Because Python modules are not linked to each other, everything you do is normally considered a use of the module. Therefore, if there is a module G released under the GPL, and a module X released under a different, incompatible license X, you would still be able to use the facilities provided by the module G. This also effects subclassing classes of G in X.

Due to the enormous flexibility provided by Python you can easily break the intented rules of the GPL. Instead of editing the class definition you subclass the class and edit it. You can also replace stuff inside the module G during run-time, simply by setting the relevant attributes.

In summary, Python makes it very easy to work around the restrictions of the GPL, therefore, using the LGPL instead of the GPL makes no sense. You can’t give others more rights than they already have. You would just make it easier for others in case they want to write new code and want to copy some of yours.

What about the AGPL?

The AGPL exposes (compared to the GPL3) further restrictions on using the software on eg. websites. It is intended for programs which may be used by SaaS providers. Like with the GPL, the enormous flexibility of Python compensates most of the restrictions the license.

BTW, which license to choose?

I normally choose to release my programs and modules, etc. under the terms of the GNU General Public License, version 3 (or at your option) any later version. But it also depends on the size of the project. When I work on small scripts, like hardlink, I generally choose the MIT license. This is also somehow related to the fact that I don’t want to have a license which takes more than 50% of the size of my project.

This is actually a bit different to what Bruce Perens does. Bruce recommends 3 types of licenses. The first one is what he calls the “gift” license. He recommends the Apache License 2.0, because it provides better “protection from software patent lawsuites”. The MIT license is another example for this type of license. While not providing the patent protection, this is not that critical for persons like me who live in Germany. Furthermore, the number of patents possibly infringed by the code is proportional to the amount of code.

The second type he recommends is a “sharing-with-rules” license, like the GPL 3. Like him, I mostly use this license for my code. Sometimes I also use the GPL 2, but only when I am required to do so, or because of tradition. In generally, I only upgrade software from GPL-2+ to GPL-3+ when I introduce new features, not for bug fixes or similar.

The third type he describes is the “in-between license”, like the LGPL. As I pointed out above, this type of license is not much different than the GPL, at least if applied to Python modules. Therefore, I never release any Python module under such a license. Things may be different for C libraries (and others), but I never released one.

Documentation, etc.

Well, I license all my documentation under the same license as the software. This makes it easier for the user because he does not need to read yet another license (at least if he reads all the licenses of the software he uses). If I distribute non-code content independent of code, I generally choose a Creative Commons License (CC-BY-SA 3.0, CC-BY 3.0), Germany.

This also has an effect on this blog. From now on, all content (ever) provided by me via this blog is licensed under the terms of the Creative Commons Attribution-Share Alike 3.0 Germany, unless a different license information is included as part of the post. The design and comments from other persons are not included.

Why I wrote this

Really, I don’t know. Maybe I just want to write something, maybe I want to write these things down, so I can read them. Anyway, please tell me if I my conclusions/ideas are wrong.

Update 1: There was a mistake “should expect the information to be correct”, fixed now: “should not expect […]”. I may be wrong with the GPL vs. LGPL thing, have not completely checked this. (2009-02-18 19:18 CET)

Update 2: Seems the GPL vs LGPL thing is not correct, as written by “Anonymous” and Bruce. (2009-02-18 19:26 CET)

20 thoughts on “Python modules, licenses, and more

  1. You are mistaken about the GNU GPL and the GNU Lesser GPL. Their major difference is with regard to the licensing of _derivative works_, and provides linking of binaries as an _example_ of that.

    Subclassing a class in a GPL’d module is the very definition of a derived work.

    Try to remember that you cannot clever your way out of the GPL’s requirements.

  2. @Anonymous: Subclassing is a use of the interface. Quoting LGPL: “Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library.”

    But what about replacing something during runtime? If I say G.the_function = X.the_internal_function, is this a derived work or not?

  3. Image a non-free module X and the LGPL-module L.

    Furthermore, the non-free module X can not be seen as a “Combined Work” with module L, if both are distributed separately.

    In terms of the GNU Lesser General Public License, version 3, the module L is “The Library” and module X is an “Application”.

  4. The only parts where the word “interface” is mentioned in the GNU GPL (version 3) concern either displaying the license (as in an user interface) and where the expression “Standard Interface” is defined. The GNU GPL version 3 makes no exception for derived works that use an interface; indeed all of them do in one form or another.

    With regard to the Lesser GPL you are quite correct, if indeed subclassing is defined as part of the exported interface. However, the GNU Lesser GPL is distinct from the GNU GPL.

  5. I think you are making some fundamental mistakes in your analysis, and “Anonymous” hit on one reason above. You need to think about derivative works, because the right to create a derivative work is one of the defined rights in copyright law. A subclass is derivative work of the superclass. A program containing a module, regardless of how linking works, is a derivative work of the module.

    Bruce

  6. Be careful, as far as I know, the law does not legally recognise the concept of a file, as happens to be defined by your OS.

    So if you ship .pyc files that do not include the MIT license inside themselves, but you *do* include the license elsewhere in the files you ship, you are in compliance with the license AFAICS.

  7. The copyright notice is true for all licenses, including GPL and LGPL. Which is why you should always keep a LICENSE or COPYING file around with the license in it.

    Besides, who ships .py[co] files?

    One of the things you should keep in mind is that if you license your library under the GPL license only GPL code can use it.

  8. @Julan,

    You wrote:

    “it is a bit confusing that LGPL treats subclassing as “use”, whereas the GPL treats it as “derivative work””

    It’s actually copright law that makes such things derivative works. What LGPL and GPL do is give you the right to make derivative works in certain conditions. LGPL allows additional conditions over those in GPL.

  9. @Armin Ronacher:

    You wrote:

    “One of the things you should keep in mind is that if you license your library under the GPL license only GPL code can use it.”

    Not only GPL code but all code which is licensed under a GPL-Compatible Free Software license. Quite a lot of licenses are GPL-Compatible (http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses). I would even say that (almost) all famous Free Software licenses are GPL compatible (mod. BSD license, X11, MIT, Apache, LGPL, AGPL, etc.).

  10. > The LGPL requires you to publish all changes you make to the code, while the GPL also requires you to publish source files you have created.

    Neither the GPL nor the LGPL require any publication of changes. You can make private changes and never publish a thing.

    What the GPL and LGPL do require is that, *if* you choose to redistribute a derived work in some form (e.g. a program), you must also make available *to the same recipients* the source form of the modified work.

    You don’t have to make that offer to anyone except those to whom you have already chosen to distribute the modified work, so it’s false to call that “publishing”.

  11. @Ben: I know this difference, I just had no other word when writing.

    @Armin: Not completely true. The application just needs to be re-licensable to GPL by its recipient. In fact the code can be MIT license, but the resulting binary is GPL. Another example is when a library with the same API is available as GPL and proprietary. Your code can be proprietary as well, but the resulting binary may only be linked to the proprietary version of the library. (QT used to do it this way, if I am not mistaken)

  12. “One of the things you should keep in mind is that if you license your library under the GPL license only GPL code can use it.”

    This is quite true in all *practical terms*.

    This is why we have LGPL.

  13. @Armin Ronacher

    sorry, you pointed me to a quite large article and i’m not sure what i should search for.

    But let me refer to http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible

    I think this explains everyting. To combine GPL code with other Code the two licenses have to be compatible. The whole work than will be distributed under the terms of the GPL but the different parts will keep their license.
    For example you can take a BSD Kernel driver and add it to the Kernel Linux. Linux as a whole than will continue to be GPL but the specific driver is still BSD-licensed. This is possible because the BSD-license is a GPL compatible license.

    The Software Freedom Law Center has even a guide how to combine GPL code and GPL-compatible code: http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html

    anonyous:
    No, we have the LGPL to combine the code with non-Free Software licenses (and GPL incompatible licenses). (Annotation: Here “combine” means only in the ways the LGPL permits it, e.g. linking)

  14. Ad MIT: The http://mirbsd.de/MirOS-Licence and some
    other “copyleft”-style licences allow the terms to
    be reproduced in the docs instead of the sources or
    binaries as well (you only need one copy each).

    Ad GPL virus: this is what the FSF wants you to be-
    lieve. Just propaganda. You are right, it does not
    get linked in Python anyway, *plus* you do not di-
    stribute the combined “work” (except if you let the
    process dump core after loading a GPL’d module, then
    publish the core dump).
    Read http://groups.google.com/group/comp.lang.python/msg/29c7588fbecd8289
    too, please. And do not give in to the FSF.

  15. @mirabilos:

    First of all, I am a Fellow of the Free Software Foundation Europe. Therefore, I am normally FSF-friendly.

    Secondly, the MIT license allows to do this in the document. It just has to be in the “Software”, and “Software” refers to the software and the associated documentation files.

    Thirdly, you can release your code under a non-GPL license, as long as this license does not expose further restrictions. But if you actually execute the code (in Python), or link it (in other languages), you are bound to the terms of the GPL if you want to distribute anything created of the combined work (core dump).

    Thus you can e.g. release your code under the Apache 2.0 license and use the GPLed python-apt. But you normally won’t do this, because you are bound to the GPL module when executing it, or distributing it together as a whole.

    Quoting http://www.fsf.org/licensing/licenses/gpl-faq.html#NFUseGPLPlugins:

    “In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.”

    In the future, I will release more applications under permissive licenses like the Apache License, version 2.0.

    Such licenses are also helpful when you just want to discuss a piece of code with someone else, without giving him the right to publish it (ie. when you discuss setting the password directly in the code).

    Also they are much easier to understand, and much shorter about 200 lines (Apache-2.0) versus 600 lines (GPL3).

  16. As I said, I may be wrong with my assumptions. This was just something I always asked myself.

    Well, I did not read all of the licensing FAQ, therefore I don’t know everything.

Comments are closed.