When licenses attack

An entry published by James Bennett on July 14, 2009, Part of the categories Misc, Pedantics and Python. 13 comments posted.

Jacob posted twenty questions about the GPL. Zed followed with an explanation of why he placed Lamson under the GPL. This has provoked some discussion around the internets, some of which I have read and some of which I’ve ignored.

Unfortunately, there’s a lot of noise drowning out useful discussion, much of it centered around alleging — directly or indirectly — that if you ask questions about how the GPL interacts with other licenses, you must be trying to “get around” the GPL, or take someone’s GPL code and use it against their wishes. This is quite sad, because the question of how the GPL interacts with non-GPL open-source licenses is both interesting and important.

I don’t have any doubts about Jacob’s or Zed’s bona fides when it comes to Free/open-source software. I know both of them well enough to know that they’re really smart guys who are producing and giving away incredibly useful software. So if they’re talking about this, it’s not because anybody’s trying to be sneaky or do end runs around someone else’s licensing.

And, to be honest, I’d really like a straight answer on how the different licenses interact. Jacob mostly confined himself to simple hypotheticals, which is fine, but to get the point across I’d like to mention some specific pieces of software and show how confusion and conflicts can pop up.

Some real examples

Suppose you’re writing an application in Python, and you use the readline and/or rlcompleter libraries. These are interfaces to GNU readline, which is GPL software, and so many people would argue — quite possibly correctly — that if you distribute that application you’re obligated to do so under the terms of the GPL.

Now, suppose your application also needs to do SSL. Python has a module for that, but what happens if you use it? Well, now you’re also interfacing with OpenSSL, which has a viral advertising clause in its license. And viral advertising clauses and the GPL cannot legally mix, which means you may be up a creek. There may be a solution to this (GPLv3 has a somewhat similar clause to the one mentioned there), but there may not be, and nobody really knows.

So if you need both readline and SSL support and you’re conscientiously doing your best to comply with the relevant licenses, what can you do? Right now, you can:

  1. Never distribute your application, since then you won’t incur any of the GPL’s distribution requirements (though a lot of Jacob’s questions poke into the nooks and crannies of just what counts as “distribution”), or
  2. Write your own version of one or both of those libraries, or write interfaces to alternative versions and hope you can find alternatives with compatible licensing, or
  3. Give up and not write your application.

It’s that last one which worries me: Free/open-source licensing should never serve to impair the production of Free/open-source software.

A more mundane example is the code for my recently-published book. I’m doing my best to get a code package out there, but right now I’m literally up against a licensing snag: one of the projects it covers is a weblog application which can post links to delicious, and the Python library which does that is GPL. I don’t personally have a problem with that and I don’t really care what license the code ends up under, but I need to know which license I’m obligated to use, and right now I don’t, because there’s a lot of confusion over when the GPL will be invoked by use in Python code.

Even more mundane, but interesting: the other day I saw someone asking about GeoDjango (aka django.contrib.gis), which provides geographic extensions to Django’s ORM. This person wanted to build and distribute an application using Django and the GIS add-ons, and was wondering how that ends up licensed, because if you use PostgreSQL, you enable GIS in the database though PostGIS, which is GPL.

I’m reasonably certain that the GPL doesn’t reach up into the Django layer in that case (PostGIS, if used, is separate, lives on the other side of a process boundary, isn’t “linked to” from the Django side as far as I know, and contrib.gis simply generates queries according to an open, standard interface, and leaves it to the end user to provide a database server implementation to send those queries to). But the fact that people ask these questions points to an awful lot of confusion about just how different licenses interact.

This is why we need answers

Nobody that I know is trying to steal anyone else’s code or sneak around someone else’s license. As someone who both benefits from and produces freely-licensed software, I wouldn’t stand for that. But well-meaning people can easily get bogged down in the morass that is license terms. To deal with this problem, the types of questions Jacob was asking yesterday need clear, common answers, many of which are not currently found in the FAQ documents of popular licenses (e.g., what exactly is “linking” in the context of a language like Python? If software is only used inside a particular company, is it being “distributed”?). Of course, any such answers would be subject to “until a court rules definitively one way or another”, but anything would be better than what we have right now.

On July 14, 2009, Ian Bicking said:

A long time ago (I think it was in the 90’s) the FSF basically said that simply putting code on the same medium (in a single tarball, CD, etc) doesn’t mean that the GPL’s requirements apply to everything in that medium. I believe the case at the time was Linux distributions which were distributed with proprietary software.

So if you are distributing GPL code that does not imply anything about software that is simply distributed alongside. A bunch of code examples and Linux distributions seem basically equivalent. Also if your examples are under the BSD or some GPL-compatible license, it doesn’t really matter.

Do you include code listings from GPL software in your book? If you do that, and assuming your book isn’t licensed as open source, I would treat the GPL code like you’d treat proprietary code (e.g. “All Rights Reserved” but source-available code). I wouldn’t feel reluctant in any way to describe how to use proprietary code in this context, so I’d treat GPL code the same. I do think it is not okay to use the GPL code itself as a teaching tool in the book; just like with proprietary code you’d have to arrange that with the author of the code.

Also many cases are protected under fair use, and it is reasonable to assume that GPL authors have a liberal opinion of what constitutes fair use.

On July 14, 2009, Jens Knutson said:

If software is only used inside a particular company, is it being “distributed”?

This is already covered by the FSF’s GPL FAQ.

I think the really interesting questions here are the ones about what constitutes “linking” in languages like Python.

On July 14, 2009, James Bennett said:

@Ian

The book covers, among other things, the process of building a weblog application with Django. One of the features is a model which stores and displays bookmarks — a linkroll. And one of the features built on that is cross-posting: save a bookmark in the Django admin, and it goes both into your database and to your account at delicious.

It does so using pydelicious, which is GPL, and covers none of the code in that module; it simply explains how to download and install pydelicious and then which function to call to post a link. So the book itself is simply documenting how to use a particular piece of software (and mainly does so to show some of the things you need to do when talking to web-based services, like avoiding Unicode strings since they can’t go over the wire).

The accompanying code package, however, will contain a file which imports from pydelicious. As I understand it, this means that the code package must — at least in the part of it containing that application — be GPL.

On July 14, 2009, Jared Kuolt said:

This page had a handy graphic:

Compatibility graph

On July 14, 2009, Not an issue to BSD/ISC users said:

This isn’t an issue to BSD/ISC users.

Your licenses grant everything that the GPL and GPL3 licenses grant, they are allowed to integrate. What isn’t allowed to happen is that upon distribution, your code is still proprietary (e.g. you refuse to grant copyleft rights to end-users).

Do not worry about mixing BSD and GPL2/3 code at the file level. Just don’t mix it within files.

On July 14, 2009, How to combine BSD and GPL said:

http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html

On July 14, 2009, Carl said:

Wouldn’t just including a delicious library without modifying it be like how OS X includes gcc and Xcode calls and is quite reliant on it, but neither are GPL?

On July 14, 2009, Ask Solem said:

The accompanying code package, however, will contain a file which imports from pydelicious. As I understand it, this means that the code package must — at least in the part of it containing that application — be GPL.

If the application just imports from pydelicious, and doesn’t include the pydelicious library in its distribution , it’s the user of the software that uses pydelicious, not the application.

Although I release my software under the modified BSD license, GPL dependencies are fetched using setup.py et. al. I’ve also seen other commercial vendors do the same, e.g more than one audio editor I know of has MP3 encoding support as plugins where they tell you how to download and install the LAME library yourself.

I can’t possibly see how they could restrict me from doing this, but I’m not a lawyer, so I really hope your understanding is incorrect.

On July 14, 2009, Stop Abuse said:

@Ask Solem, stop violating the GPL. Seriously. Your BSD code can link to GPL code just fine. You simply have to follow the GPL license when someone asks for all the code because you’ve made a derivative.

On July 14, 2009, Dave K said:

GPL is a (bad) virus.

Any ideology that forces itself on others is inherently reductive to their freedom and creativity.

The GPL has resulted in lots of great open source software, but it’s also resulted in a lot of closed source software, a lot of which is much better. And if the much better point enrages people it’s proof they’re ideological extremists and they’re treating the GPL as an unquestionable religion.

The fact is, even if it’s for the greater good, when you force someone to do something (like open their code) it’s less free than not forcing them. Sure they can opt to not use your code, but then you in taking that stand you must condone vendor lock in, because that’s a choice too.

On July 15, 2009, Ask Solem said:

@Stop Abuse, But I haven’t made a derivative. The user that runs my software is executing GPL code when my programs run. The software does not ship with any GPL code at all. It simply assumes the required GPL code is installed on the system.

On July 15, 2009, Alex Gaynor said:

Carl: OS X doesn’t actually call any internal GCC functions. Every action it takes is done through Unix pipes, and by insulating all communication across multiple processes it doesn’t invoke the GPL.

On August 8, 2009, Graeme said:

I think the answer to what linking is in the context of Python is in the GNU’s GPL FAQ’s regarding interpreted languages.

A number of comments to the 20 questions point out, correctly, that many of them are answered by the GPL FAQ (1,2,4-8), or are obvious (12,13, 15-19). I am pretty sure that 9-11 are answered by saying that subsidiaries are legally separate persons.

Comments for this entry are closed. If you'd like to share your thoughts on this entry with me, please contact me directly.

ponybadge