A licensing information surprise on FreeBSD

I love FreeBSD. If perhaps the relationship has been cooler in recent years, it was because I was messing around with a red-headed stepsister called OpenSolaris and because suspend didn’t work on the laptop I was mostly using for the past two years.

KDE on FreeBSD is very much alive. Oh, and there’s EuroBSDCon in the Netherlands in a month and a half.

In my case, FreeBSD remains the go-to place for getting stuff done at the server end of things. Today, that meant installing bugzilla so I could test a patchfor bugzilla information harvesting in XML format. I love how it’s a dead-simple "portinstall bugzilla" and it does whatever heavy lifting and interactive configuration is necessary.

While running that, I did notice the following license information line in the output (screenshot of a FreeBSD VM in VirtualBox):

So this is telling me I’ve accepted ART10 GPLv1 — I know that’s Artistic License 1.0 and version 1 of the GPL, (which is probably considered deprecated and replaced by GPLv2 and GPLv3).

I like this. It tells me, when I’m installing something, what the license obligations are. Naturally it’s Free Software, so my freedom to use it for any purpose doesn’t hinge on the license. However, if I were to further distribute the software (eg. as a VM image), then the license obligations are relevant, and I’m happy to have this stated up-front.

Some things Oracle just doesn’t get

Yesterday at the NLUUG conference I picked up a Solaris 11 Express CD in a nice brownish CD sleeve (I say "nice" because it feels and looks different from the generic white sleeves). Here’s a scan of the back of the sleeve, with a big sticker over the flap (click on image for a larger, readable version).

scan of cd sleeve

I thought shrink-wrap licenses went out with Disco, or something like that?

A little searching gets me to the license text so I can read it before opening the package to get at the license itself. The one saving grace is that the license condition is "opening this sealed software package and using the software" (emphasis mine) so it’s not classic shrink-wrap.

In classic fashion, though, I can’t give away this CD to someone else, not even if they want to use it to develop or demonstrate an application on Oracle Solaris.

If we turn to the license text itself, the section on "Open Source Software" rubs me in every possible wrong way, starting from the definition

"Open Source" software – software available without charge for use, modification and distribution – is often licensed under terms that require the user to make the user’s modifications to the Open Source software or any software that the user ‘combines’ with the Open Source software freely available in source code form.

It’s increasingly difficult to engage with Oracle Solaris except as a commercial entity; increasingly difficult to easily check if the software you produce (you in the sense of "a Free Software community") might work on that OS. Combine that with a compiler that’s also increasingly hard to get and, well .. it certainly seems like there’s no interest in third-party software development except on a commercial basis.

We’ve been keeping Qt on Solaris (with Sun Studio) going for three years now. That has led to many patches in the compiler, many in WebKit, and most of the time we’ve got a good working relationship with upstream (i.e. Nokia / QDF). I still think we can deliver a Qt suitable for other applications’ use (maybe not VirtualBox, but that’s still dreamable). Now the Qt modules maturity list shows that Solaris (along with the proprietary UNIXes that still exist; remember at some point Solaris distinguished itself from those by being reasonably-almost-open) is "done". Needs new maintainer. That bodes ill from an upstream-support perspective.

Note about the compiler: you can’t get patches (beyond the released 12.2 version) without a support contract, as far as I can tell. So there’s no easy way to get a version of Sun’s C++ compiler that has all of the bug fixes prompted by the KDE4-Solaris project. The partly-patched version I still have on my Solaris machines is falling behind, so that I can’t even compile all the stuff I’m trying to package. This is one of the reasons the KDE4-Solaris project is looking hard at both gcc and Pathscale.

A tiny licensing light

I read nu.nl — a Dutch news website which isn’t very good newswise, but whose layout loads quickly on my phone — fairly often. I was most surprised to find the following tag on a map in an article:

Map tagged (C) NordNordWest/Vardion/NU.nl/GNU FDL 1.2

(it’s a map of Libya, you can see it if you scroll down). I was surprised to see the map labeled with the GNU FDL. So that means that this particular map can be aggregated into other work (see the GNU FDL v.1.2, section 7). I’m just left wondering why the GNU FDL would be used here .. I hardly expect it to be out of the goodness of their (nu.nl) hearts. I would have guessed Open Street Map derived, but that’s CC-BY-SA.

MySQL connectors and the GPLv3

[ Just a repeat, but useful for upstreams and downstreams and people building modern apps using MySQL’s connector libraries and other components that need GPLv3 ] Via David Ayers, I read that the GPLv3 has been added to the FOSS License Exception on the MySQL website (disregard the "Updated" date at the top of that page, this is fairly recent). This means that the GPLv2 licensed library may be combined with GPLv3 code, leaving the combined work as a whole under the terms of the GPLv3, while only the terms of the GPLv2 apply to the client libraries.

Some things to note if you read that exception page closely: "GPL" there means "GPLv2" except in the table of FOSS licenses, where it means GPLv3. Clause 2b means "this exception applies if no other part of the work forces you to use GPLv2". Clause 2d adds additional source distribution requirements beyond what you’d have to do otherwise. The page also still refers to Sun, so it needs another update anyway, one which might get a good going-over by Oracle’s lawyers.

Let a Thousand Licenses Bloom

A software license lets you do something that you otherwise would not be allowed to do, given the limited permissions granted by Copyright law. That is, it changes the “all rights reserved” into “some permissions granted and all other rights reserved.” Which permissions those are depends on the license; which exceptions to “all rights” exist depends on the jurisdiction under which you’re operating (e.g. while “Fair Use” is something you can do in the United States, that concept doesn’t exist everywhere).

There’s lots of software licenses. There’s even lots of Free Software licenses. The Free Software licenses all grant you permission to do at least four things: use, study, modify and share. Sometimes they allow more. The BSD license allows proprietization. The Apache license allows the use of patents embodied in the software (important in jurisdictions with patents). The GNU General Public License allows you to format shift (e.g. you may publish a GPL licensed program as a T-shirt).

The flip side of permissions is that of conditions: often the permissions are granted provided that you do something else. For instance that you pay for the permission (a proprietary, commercial license would require that). Or that you give the source code of the program to recipients of the binary (as the GPLv2 says). Or that you send your modifications to the original author if you distribute the code in modified form.

The conditions may also include a condition that the same license applies to derivative works. The GPLv2 has such a condition. The EUPL has such a license (plus an escape clause). The CDDL has one. This kind of condition creates an “species” around a single license of like-licensed software. Such a species has software individuals that can be freely combined and modified and shared, since it all falls under the same license.

This kind of condition also creates a division, one between species, because you can’t “breed” between species. The conditions of licenses of two different species cannot be satisfied simultaneously, so you can’t do it. As a consequence, we see that the same functionality is developed multiple times under different licenses. Some might call that wasteful. It’s out in the open, though, and reimplementation only needs to happen once for each species, so the waste of effort is limited. Who knows how much sloth and useless duplication occurs behind closed doors? In any case, we find that a license with conditions creates its own species and that most software combination works within that species.

So-called “permissive” licenses can cross the species divisions, simply because they do not have any conditions that prevent them from being integrated into another species.

If you’re a software developer who is combining pieces of software which are under different licenses, you need to be aware of the species differences. Indeed, sorting out which code can be combined with which can be a considerable effort. The FSF lists dozens of Free Software licenses and whether they’re compatible with the GPLv2 and the GPLv3 — and even the GPLv2 and GPLv3 are different species.

So we have two problems with having lots of species: that of duplication of implementation effort (yes, I too have had to ignore an available Free Software component that did what I needed and had to re-implement it badly because of license incompatibility) and of effort involved in checking for compatibility.

The underlying problem — that of having many license species — is what we call license proliferation: there’s lots of licenses, and more show up all the time. Black Duck software identifies some 1200 of them. The OSI has 60-odd licenses. That’s a lot of extra effort.

So when people ask the FSFE about software licenses, in particular about creating a license with new conditions or that varies an existing one, we say “don’t do it.

That bears repeating:

Do not write a new (Free) software license. Just don’t. Really. Pick an existing license that does what you need. And if there isn’t one, then what you want is probably not a good idea.

I’m aware that’s an argument from authority. That’s not always a good kind of argument to use. However, you need to be aware that in creating a new species (by creating a new license) you’re committing yourself to the whole rigamarole of re-implementation, and excluding people from outside the species.

Now, as with almost every rule (except rule 34), sometimes the rule is just a guideline. People who know what they’re doing can bend the rules.

There can be really good reasons to bend the rules. For instance, new dangers show up that threaten the Free Software ecosystem. These dangers may be a reason to introduce a new license to counter them — patents, for instance. Who would have though, too, of valuable trademarks in Free Software? They’re explicitly mentioned in the more modern licenses. A simple permissive license that disclaims warranty might not be sufficient if regulatory frameworks change. And in some areas of business, existing regulations might require things of a software license that the existing ones do not provide.

So there can be good reasons to change. And in spite of my position that license proliferation is bad, I’m going to applaud the Mozilla Foundation for choosing to look into updating the MPL (coverage from the Register here).

The MPL is a file-based license, not a work-based license, so it creates species in a different way. Clause 6.2 of the existing MPL allows a transparent upgrade procedure, so I think the proliferation aspect of this license update doesn’t need to be stressed. They’re doing the right thing. The content of the license change isn’t firmly fixed yet: Mozilla is still in the comment phase. Results are expected later in 2010. I’m looking forward to meeting some of the people driving the process in Mozilla next month, for a chat over a glass of wine as to which bits of compatibility are the most important.

So here’s to licenses; let a thousand choices bloom.

PS. Ideally, I think that each license would make a clear statement about what it means in each of the essential areas of licensing. Unfortunately, those “essential areas” have changed over the years, so many do not do so. I hope for a clear new world where we have a small collection of modern licenses (say, Apache v2, GPLv3, MPLv2 and a new permissive license) that define the main species of Free Software.

PPS. Although I think that this applies to every blog post, I think I should add explicitly here: this post does not reflect an official FSFE position on the Mozilla license.

On freeing a project

I saw over on LWN.net (a very valuable resource for technology articles, well worth your $5), that a RAW picture editor called RawTherapee had been re-licensed from Freeware (gratis, but proprietary) to Free Software, under the GPLv3. The application is something I won’t use myself, and I can’t even manage the comparison to DigiKam (which I don’t use either). Technologically it looks quite cool, from the cmake-based build (yes, having a build system that supports cross-platform development effectively can be a wonderful thing) to the (comprehensive and multi-lingual) ODT manuals. I miss the nice KDE reporting of missing dependencies summarized in a list at the end, though. Something to contribute, over there.

The author, Gábor Horváth, states some interesting reasons for freeing the whole thing; I personally think the “family” argument is the strongest one, and it’s important to spend time with your (small) kids. Of course, at 10 months you can still code with the baby on your tummy. The other motivations are largely a matter of growing the community of developers and contributors in order to get better coverage of all the aspects of development (GUI, documentation, algorithms, translations) and smoother development by not depending on a single individual. All good reasons, to be sure. Whether these are good motivations to choose GPLv3, I don’t know (over some other copyleft license that encourages community building).

I’m going to admit a very non-charitable reason for looking more closely at RawTherapee: I was intending to bitch and moan about the state of the source code and the licensing and then point out how it should be done, by gorm. Instead, I can point to RawTherapee (as of SVN revision 31) as an example of a Free Software project done (pretty) well:

  • (good) Clear license choice; although the license is in a file called “copying” instead of the canonical “COPYING”, it’s the complete text of the GPLv3.
  • (good) Every file has a complete copyright header, including sufficient license text and an identifiable copyright holder. As the project grows, it will be interesting to see if it manages to keep a good grip on its contributors — that is, if everyone who adds a copyrightable contribution to the code actually adds a meaningful copyright holder line to the file headers. This would be, roughly, clause 5a of the GPLv3.
  • (bad) The distribution from SVN includes a few pre-compiled libraries (jpeg, lcms, png, tiff, z) for windows and accompanying header files. Of that lot, jpeg doesn’t mention its license terms in the file header (but refers to a README that has been lost). I hunted down the relevant source distribution, and the README contains a license that stipulates that README must be included with the distribution if any source is distributed. Right, minor point, but something to clean up in a next release — although I’d like to think that it also illustrates that the license in the jpeglib header should be clearer. lcms is MIT licensed, the png license doesn’t seem to allow binary distribution at all — the permissions it gives are for source. On the other hand, the use of the code as a component in a product is encouraged — that suggests binary use is ok, but it’s not exactly explicit. Tiff is MIT again (when I say “MIT” I mean “Simple permissive 1-clause, possibly with a restriction on endorsement”) and libz is also permissive. So just one minor blot.

Anyway, a tip of the hat to Gábor for doing it right (and doing the right thing) and I wish him lots of success with his project.

License Badges, 0.7 version

I’ve added some bits and pieces to my badges-for-licenses scheme, mostly based on comments received from readers. Most notably, I’ve added the LGPL, added links to the license texts, twiddled the CSS a bit, added mouse-over warning messages to those licenses that deserve a warning, and improved the description of some of the badges. What still needs doing — and I wonder how to achieve a good balance between having an overview of licenses that is short enough to be readable, and the subtleties of licensing reality — is writing up a good piece on how these badges reflect the most important pointsof each license, but do not state the complete effect of each license (unlike Creative Commons licenses, where each set of icons maps to one set of license terms).

The next round of updates will basically be adding more licenses, improving some of the icons, snazzing up the presentation a bit and importing the whole thing into the FSFE site. That’s for just before FOSDEM, I think.

Another note on dual-licensing

I recently wrote about the FreeType license and its double license and why it was necessary. It’s an interesting situation (for FreeType itself) because there’s the GPLv2 and a second Free Software license involved — the FTL, which is basically a 3-clause BSD license with attribution required.

Often, though, when we talk about dual licensed we mean a situation where one license is a Free Software license and the other is a fully proprietary one. Bear in mind that the 3-clause BSD license allows proprietization as long as you satisfy the attribution clause and the license distribution clause, so it’s not a world of practical difference, but one of intent. The suit filed around Palm’s PDF viewer on the Pre illustrates the effect differences of intent can have.

One way you can look at dual-licensed software is that you have “the usual license” (which in our context is a Free Software license, probably some version of the GPL) and that for some users who cannot abide by the terms of that Free Software license, you sell exceptions. Richard Stallman writes on the subject — I found it via groklaw, where also one of the first comments uses the phrase “selling indulgences,” which I think is much more evocative.

So the point is that if you are the copyright holder — the sole copyright holder, because you need to have the right to re-license the code — then you can sell an indulgence to someone who cannot abide by the Free Software terms, but whom you consider worthy to use the software nonetheless. Yes, that’s plenty subjective. My phrasing is also slightly wrong, because you don’t have to be the sole holder: there are other ways of ensuring that you can grant the indulgence even with multiple rightsholders (a contract or license grant would do). In any case: you can do this for specific reasons while still supporting and producing Free Software.

This is also RMS’s pragmatic point: while the FSF does not follow this practice, that doesn’t mean others cannot while still being “ok”. And I think that’s good news for GPL’ed libraries out there. For users of GPL libraries, bear in mind that intent matters, and that the GPLv3 offers a grace period that the GPLv2 does not — and that might be important when dealing with entities whose intents are not entirely clear.

The FreeType License

The FreeType library is released under a dual license: you can choose either the FTL (FreeType License) or the GPL, version 2. That means that a software stack that uses FreeType has to be license-compatible with one or the other (or both). In cases where the rest of the software stack also allows choices, this can be slightly complex. You end up with a combinatorial explosion of licenses — in theory, if not in practice.

But why is a choice necessary, anyway?

At issue is the “attribution clause”. This is common in the BSD family of licenses: the clauses usually say that you must attribute or credit the authors in the documentation accompanying the (binary distribution of the) software. Let’s look at the attribution clause of the FTL itself:

Redistribution in binary form must provide a disclaimer that states that the software is based in part of the work of the FreeType Team, in the distribution documentation. We also encourage you to put an URL to the FreeType web page in your documentation, though this isn’t mandatory.

OK, that’s fine. You can do that, by adding exactly that to your documentation. It’s not an onerous licensing requirement. But it is part of the license and must remain part of the license. This collides with the GPL version 2 because that license demands that the entire derivative work be licensed as GPL version 2 — that’s clause 2b, and the explanation in clause 2, and clause 6. Clause 6 in particular adds “You may not impose any further restrictions on the recipients’ exercise of the rights granted herein.” And the attribution clause is exactly a restriction that is not allowed by the GPLv2: the license demands that you put something in the documentation, the GPL version 2 does not allow you to add that demand to the license of the whole, end of story.

Well, it would be end of story except that two efforts in the realm of license compatibility have happened: FreeType itself is also available under the GPL version 2, so if you really want to you can apply the GPLv2 to your program and be done with it (this is good for Free Software, but one could argue that it drops the permissiveness of the BSD-style license because now you can’t produce a proprietary, binary version and satisfy the license through attribution). And on the GPL side, the GPL version 3 has clause 7b which specifically allows distribution under the GPL version 3 with an additional restriction of the form

b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it;

This is just called an additional restriction because that’s the language of the GPL. Attribution in the documentation is, like I said earlier, hardly an onerous restriction. Well .. maybe. That’s something we’ll come to some other day. In any case, it means you can write your software under the terms of the GPL version 3, then add FreeType to it under the terms of the FTL and release the whole under the GPL version 3 with an additional restriction.

To return to my earlier consideration of KDE license policies: there’s nothing there that makes it impossible to have GPLv3-or-later code in there license-wise, because you can make compatible choices. But that’s a very small sample, and KDE policy remains otherwise.

KDE Licensing Policy

I have been invoked by John Layt to explain some bits of the KDE licensing policy. It’s related to my recent writing on copyright assignment in the sense that it discusses reasons for picking particular licenses and how licenses interact. The back story is the KDE Licensing Policy, which lays down which licenses are acceptable in the various parts of the KDE platform technologies and applications. Roughly, the libraries need to be liberally licensed (which means they can be taken proprietary or shipped with otherwise closed devices — a common choice of GUI libraries nowadays). More concretely: (LGPL 2.1+) or (LGPL 2.1 or LGPL 3 or later approved) or BSD or MIT or X11. The idea is that you can either go for any version of LGPL from 2.1 onwards, or only selected versions of the LGPL which have been approved by the membership of KDE e.V. (if you don’t want to give a blanket permission to the FSF to update the license terms) or something very liberal.

You must offer the choice, though: you cannot put just the LGPL 2.1 on there: it must be “or later”. You also cannot just put LGPL 3 on there. It must be “version 2.1 or version 3 or any later version approved by the membership.” That’s KDE policy. There is a technical (well, licensing-technical) reason for this as well, and that is license compatibility.

The issue of compatibility is more pronounced in applications, where we also allow GPL variations similar to the LGPL variations mentioned above. The reason is that the GPL version 3 is incompatible with the GPL version 2. As long as there is GPL version 2-only code somewhere in the software stack, we must be able to license the software under something compatible with that license — and that means the application code must be available under GPLv2 (or something else, but not GPLv3-only). Let’s take a look at the licenses used in libraries in a typical KDE application. I’ll use Konqueror on Kubuntu 9.04 as an example, with ldd providing the list of libraries. Here’s just a partial list:

LGPLv2 libacl.so.1
LGPLv2+ libattr.so.1
PD libaudio.so.2
BSD libbz2.so.1.0
LGPLv2+ libc.so.6
LGPLv2+ libdl.so.2
MIT libexpat.so.1
X11 libfontconfig.so.1
FTL, GPL libfreetype.so.6
LGPLv2+ libgthread-2.0.so.0
MIT libICE.so.6
LGPLv2+ libkdecore.so.5
BSD libpcre.so.3
zlib libpng12.so.0
LGPLv2+ libQtCore.so.4
LGPLv2+ libuuid.so.1

Now, it’s important to choose at the moment of running, a license for each component such that the whole is compatible. For each component there must be a concrete choice made. So for libfreetype I could choose the GPL (I guess it’s version 2 only then, but the Debian copyright file gave me no additional information and I’m too lazy right now to look it up), and then all the other choices I make need to be GPLv2 compatible. And now you see the problem looming: if I choose GPLv2 for the Freetype part, then I can’t mix in any GPLv3-only components. Or conversely, when you put in GPLv3 code into a KDE application, you are forcing GPLv3-compatible choices in the rest of the stack.

I don’t see any GPLv3 incompatible components in this listing, but that doesn’t mean there are none anywhere in the stack, ever. So we don’t want to force the choice for GPLv3 by including GPLv3-only code. For the purpose of risk avoidance we have the policy requiring licensing as GPLv2-or-later so that we can, if need be, choose the GPLv2 version to remain compatible with GPLv2-only compatible libraries. So it’s basically us keeping license compatibility with software components using older licenses. But it’s uncomfortable to me, because at some point we might end up in a jam with license versions as other parts of the software stack migrate (although very unlikely with all the liberally-licenses software in the stack).