Gray areas in software licensing

This year saw a new addition to FOSDEM in Brussels - "legal issues" gained its own DevRoom and joined the long list of topics presented and discussed during the conference. I was privileged to be asked to speak at the track, and when Bradley Kuhn asked me what I'd like to speak about, my initial reaction was the theme: "how much I hate having to care about the law".

Developers hate the law. Or, to be more precise, I hate the law. At least, whenever I'm working on a software project. In my opinion, every time a software developer has to stop and think about the law, that's a bug. Either he wants to do something that he shouldn't be doing, or the law is getting in the way of him doing something which it would be reasonable for him to do.

In case it's not obvious yet, I am not a lawyer, so nothing in here should be taken as legal advice. But, over the years, while working as a GIMP developer, as community and product manager of the OpenWengo project, or as an independent consultant, I have had to stop and consider the potential impact of the law on what I was doing. And every time that I have sought legal advice on the issues, the result has been unsatisfactory. Here are a few examples from my personal experience.

GIMP plug-ins

In the late 1990s and early 2000s, the licensing of plug-ins was a hot topic in the GIMP community that came up repeatedly. Does the GPL allow people to develop proprietary GIMP plug-ins? It was certainly the intention of the developers active at the time to allow proprietary plug-ins. To explain why this question is even interesting, some technical details on GIMP plug-ins are useful.

GIMP plug-ins run in a separate process from the GIMP core. They link to libgimp, a library that was licensed under the LGPL in 1997, which is a wrapper around the PDB, the Procedural Database. The Procedural Database is how plug-ins communicate with the core GPL application: data is sent via shared memory, with the PDB defining arguments and return values from plug-in functions. Plug-ins can call core functions, again via the PDB, to get image data from a drawable (a GIMP object representing anything you can draw on), or for any of a range of core functions.

But some argued that since GIMP plug-ins could only work with the GIMP core, that they were really derivative works, and were thus covered by the GPL. When we asked for definitive legal advice on the issue, the answer we got back was not entirely satisfying.

Maybe.

Ugh. So to clarify the situation, the GIMP developers added a license clarification to the source code, alongside the GNU GPL COPYING file, stating that we considered plug-ins to be "mere aggregation", and not a "derivative work". This may not be legally rigorous, but it was enough to allow us to forget about the issue and get back to coding.

Distributing GIMP plug-ins

That is, until it was pointed out by Debian that GIMP was shipping some GPL-incompatible code in plug-ins that we were distributing in the gimp .tar.gz. This issue ended up blocking the release of GIMP 1.2.4 for over a year. So the question arose: can we include non-GPL plug-ins in a GIMP package? The answer was, you guessed it, "maybe". At least, that's as far as we could tell by discussing it in a Debian bug report and on gimp-developer.

While GIMP plug-ins might be a "mere aggregation" with the GIMP core, apparently, there was an expectation that all the plug-ins which were shipped with GIMP would be GPL compatible. Over the years, we had included a number of code snippets from other open source projects which were licensed under other licenses. One of the projects was SIOD, Scheme in one Defun, a Scheme implementation by George Carrette. SIOD was the back-end of Script-fu, GIMP's scripting plug-in, at the time. SIOD had a very liberal license which included an "advertising clause", requiring that "the permission notice appear in supporting documentation", a clause which was widely argued to be incompatible with the GPL at that time. It turned out that there were about a dozen occurrences of this advertising clause in the code for plug-ins at the time.

Since Debian wouldn't ship GIMP with these plug-ins unless we made the licensing consistent, and since some GIMP developers also expected us to ship only GPL-compatible plug-ins, this was a major problem. So I and others spent a month in 2003 chasing down authors at five-year-old email addresses, removing or rewriting code snippets when we could do so, and on occasion removing offending copyright headers when we decided that the amount of code covered by the problematic licenses was so small that it was not a problem. I am sure I would have preferred to do other things with my time - and I was certainly not as methodical as Gervase Markham when he was relicensing Mozilla code - a process that took over 4 years. Were we legally rigorous? Maybe.

OpenWengo codecs

My next example is audio codecs from the OpenWengo project (site now dead). Some codecs like G729 were patent encumbered. In addition, widely used reference implementations of codecs like iLBC were included as sample code in standards documents and were only available under GPL-incompatible and non-free software licenses. The way we tried to get around this problem was to encapsulate these codecs in a standard API, and install them in a common directory. At start-up, we scanned the directory, and used dlopen() to open the libraries present there. We could then call the standard function to register the codecs and pass data streams for decoding and encoding.

A question arose for some of the non-GPL codecs: could we do something in the start-up process to make it easier for the user to obtain these codecs? One possibility would be to present the user with a dialog, as part of the first application start-up, which fetched the proprietary codecs and installed them in the common directory. But, would that be against the spirit of the GPL, and have us running the risk of being called a GPL violator by one of our users?

The answer, apparently, is "maybe".

By divorcing the loading of the plug-in at run-time from the distribution of the plug-in, we were probably absolving ourselves of any GPL obligations. At least, that is the legal advice Wengo obtained at the time. However, whether making it easier to get the codecs at start-up was the legal equivalent to including the codecs in the package was, at best, ambiguous.

Hunspell dictionaries

Last year, I was asked an interesting question by a client: Can I include Hunspell and the Czech dictionary in a proprietary application?

The answer, of course, is "maybe".

Hunspell changed its license in 2006, to the MPL/GPL/LGPL tri-license to enable inclusion in Mozilla. It is used as the spell-checker for OpenOffice.org/LibreOffice as well as Mozilla Thunderbird and Firefox. Of course, the tri-license enables the embedding of Hunspell in proprietary applications. So where's the problem? It turns out that some Hunspell dictionaries, including Catalan, Danish and Czech, are licensed under GPL only. It's a bit curious why anyone would use the GPL, a license intended for use with source code, for a dictionary. Regardless, the question is: does including Hunspell in another application, with a GPL dictionary, constitute a derivative work, or an aggregation?

At one level, the question is whether it even makes sense for a dictionary to have a license. Thanks to Feist v Rural, copyright only applies to a "work" if there is significant creativity involved in it. If a Hunspell dictionary were just a list of words in alphabetical order, then at least in the US, copyright would not apply. However, in other jurisdictions, there are laws covering the constitution of databases, and some form of protection is afforded to the author. In addition, a Hunspell dictionary isn't really just a list of words - it also contains grammatical and hyphenation information, which involves some creativity. So there's a solid argument that the dictionary is copyrightable.

The second question is whether including the dictionary with Hunspell and other software makes a derivative work, or an aggregate work. One part of that is whether the component is useful without the Hunspell spellchecker. Since it's just a dictionary, it can be used with other spell-checkers, including aspell. Hunspell could easily use another Czech dictionary released under another license. So, since the two bits are easily dissociable, Hunspell with the dictionary probably makes an aggregate work, and the license of the dictionary does not impose any requirements on other software shipped with it. This is the advice that the OpenOffice.org project received from the FSF licensing list, and so the GPL dictionaries are included in the LibreOffice and OpenOffice.org distributions.

Mozilla, on the other hand, do not ship any GPL dictionaries. When I asked Gervase why, he answered:

In other words, the intent of the author trumps all in this case, for Mozilla.

So - maybe.

Conversations with lawyers

The problem for developers is that conversations with lawyers typically end up with "maybe". We're looking for what we may and may not do, and often, in the absence of jurisprudence, lawyers deal in shades of gray. All too often, the end result for developers is to avoid any risk.

A friend once told me a story of a meeting with her boss and "legal", where she came out of the meeting disappointed. When her boss asked her what was wrong, she said "the lawyers told us we can't do what we'd like to." To which he replied, "No, they just told us the risks involved. Now we have to decide whether we're prepared to accept those risks or not." Instead of being the end of the conversation, "maybe" could be the start of it. Lawyers (and , in the free software world, some non-lawyers) will help you identify risks. But then it is up to the project to decide whether to take the risks or not.