Bobulate

[ 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.

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.

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.

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.

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 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.

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).

A little while back, Michael Meeks published a lengthy piece about copyright assignment (not nearly as lengthy as the articles he links to on untangling Wittgenstein’s net). Go on, read it (Michael’s stuff, not the net). It’s worth your time. When you get to the bottom, follow the link to Dave Neary’s take on assignment as well.

I’m going to take the time to respond to Michael and Dave with two different hats on: my FSFE hat (work-work, where I do legal and licensing stuff in the Freedom Task Force) and my KDE hat (volunteer work, where I have hacked on various bits and pieces for over a decade). This isn’t an entirely independent article on assignment, but looks at their comments on it. First off: there’s no right answer. Just like I say during my licensing talks at conferences: it (licensing or copyright assignment) is a choice that needs to be made, and that choice needs to be compatible with your goals, your morals, your business needs (if any), your sense of community (if any) and your desire to deal with administrative details.

One or two points of fact, though: the FSF does not require assignment — not for all GNU projects, at least. For some, yes. I made this exact same mistake at the GNU hacker’s meeting in Gothenburg last month. After all, it’s easy to find articles stating that the FSF requires assignment — even on the FSF site — and not so easy to find ones that do not. After all, it’s hard to search for the absence of a document. Andy Wingo can probably point out some.

Qt is still subject to a contributor agreement, but it is not a copyright assignment, but rather a license — in other words, the original author retains the copyright but grants the Qt organization (that is, Nokia Oy) a very broad copyright license (including sublicensing) and a patent license (for patents covered by the contribution). There’s some pretend remuneration. There’s little in the way of protection offered to the contributor, but I think it would take some far-fetched scenarios to find a patent danger in there (but do comment on their existence).

Michael’s examination of assignment forms (including Sun’s SCA) is missing one form that is used in Europe (and elsewhere), and that is FSFE’s Fiduciary License Agreement (FLA). This is a copyright assignment form — no patents involved, which makes some sense because there’s no software patents as such in Europe — that assigns those assignable rights to a Fiduciary, and then licenses those rights back. The assignable rights vary a little by jurisdiction (and Europe has lots of them), so that makes the form a little bit longer than it might otherwise be. In addition, there are variations as to whether you can assign future work or not — things like that.

(1) Subject to the provision of § 2, Beneficiary assigns to FSFE the Copyright in computer programs and other copyrightable material world-wide, or in countries where such an assignment is not possible, grants an exclusive licence, including, inter alia:

Here the FSFE is the Fiduciary. The Fiduciary is a party you trust to handle the copyright responsibly. By default you own the copyright — and I assume you trust yourself to do the right thing with licensing on the work you do for yourself — and the rights (most of them, anyway) are assigned to your estate. Presumably you trust your executors to do the right thing as well.

That actually leads into one of the reasons that you might want to think about copyright assignment — or at least about what happens with your code and the rights to your code when you’re no longer actively involved with the Free Software projects you contribute to. It happens — people drop out, no longer want to participate, or indeed pass away. Copyright assignment is one way to manage the risk (and possibly administrative burden) attached to something long-lasting like copyright.

Back to the FLA: the effect of clause 1 is that the Fiduciary gets control over the rights to display, reproduce, distribute, create modified or derived works and to allow third parties to do so. While re-licensing isn’t explicitly in there, the authorization to third parties implies it. There needs to be an exclusive license so that the Fiduciary knows they are the one party who may act as if they hold the rights. So once the Fiduciary has the rights, what happens?

(2) FSFE grants to Beneficiary a non-exclusive, worldwide, perpetual and unrestricted licence in the Software. This right’s [and licence’s] scope shall encompass and include all the rights [and licences] specified in § 1. Furthermore, FSFE grants to Beneficiary additional nonexclusive, transferable license to use, reproduce, redistribute and make available the Software as needed for releases of the Software under other licences. This re-transfer shall not limit the scope of FSFE’s exclusive licence in the Software and FSFE’s rights pursuant to §1.

You get it all back and can continue to license, sublicense, modify, etc. the work. In other words, you can continue to behave almost as if it were still your copyright. This is important because the Fiduciary wants to support the use of the software as much as possible. So you’re even free to create a derivative work and make it available under another license. I have not considered whether it would be possible to release it under a proprietary license — there might be some tricky interactions between the assignment and the re-assignment.

This FSFE FLA is available under a license that allows modification, so you can take the FLA and modify it for your own purposes. KDE has done so. The KDE FLA adds some restrictions to what the Fiduciary is allowed to do in terms of relicensing, but these clauses were added after some lengthy deliberation.

In any case, an FLA is an adaptable mechanism for assigning copyright to a Fiduciary — some party you trust. Just having the tool available doesn’t mean much, though: there are issues of policy as well. To return to the beginning: some projects / organizations have a policy of requiring assignment (though some instrument). Others do not. KDE is unusual in that it makes it possible to assign copyright to the organization, but does not require contributors to do so.

So let’s carry on with Michael’s comments.

To whom are you assigning it? This is a very important question — because you need to trust the fiduciary. Michael points out that a non-profit (association or foundation, with a constitution written to support particular goals) is probably a better Fiduciary than a corporation. The reason for that is relatively straightforward: money. You can buy a company, buying a non-profit is much more difficult. Not impossible, mind you. The FSFE acts as Fiduciary for a few projects. KDE e.V. acts for its own project. When asked, I tend to advise finding an existing trusted party (like FSFE or KDE e.V. or perhaps the Linux Foundation) who is willing to act as Fiduciary (FSFE takes it case-by-case, KDE e.V. is probably most interested in KDE-technology related projects, and I can’t speak for the Linux Foundation but they strike me as a potential partner). Setting up your own organization is possible, but has some costs. Those are costs in filing and administration, in setting up meetings, and providing long-term viability to the organization.

An assignment document should have an escape clause if the Fiduciary turns out not to be faithful (fides is Latin for faithful, more-or-less). The FSFE assignment has such a termination (or auto-revert) clause. So does the KDE one. So does the FSF’s assignment. Michael points out a few others, and such a clause should be seen as an additional form of risk-mitigation

Benefits and risks: Note well that “single owner” and “re-licensing” are listed as both a benefit and a risk. Which is as it should be: a single copyright holder also means a single point of failure (in terms of a take-over) while multiple holders means many points of failure (in terms of necessary re-licensing or negotiation). But a single copyright holder means success because it can manage negotiations, sublicensing, re-licensing and assets (in the sense of “your software has value to its users” even if not monetized) and multiple copyright holders is a success because of its resilience in the face of take-overs and flexibility in accomodating different viewpoints.

Again, it depends on what you think is most important and how you weigh the risks. I like the KDE e.V. approach with a non-profit association that holds a fair amount of the rights — but nowhere near all of them, on any part of the code — and then multiple individual (and corporate) rightsholders. That makes it both resilient and possible to go to court saying “we (KDE e.V.) represent a 30% stake in the copyright in this work”.

That last item relates to “defending the code.” There simply haven’t been enough cases of license enforcement to say whether a centralized copyright holder is useful or not. Harald (through gpl-violations.org) is very successful in enforcement in Europe, but he has rights (including assigned copyright!) to some well-defined and popular pieces of the Linux kernel which are fairly easy to detect. Besides which, not every developer wants to get involved in this stuff, so it might be difficult to find any individual developer to enter into a copyright enforcement suit.

On re-licensing I would add that “license tourism” by a Fiduciary should be avoided, perhaps by wording in the FLA, perhaps in the constitution of the Fiduciary. You don’t want to start with (say) the GPL and end up with the code under something totallylargely incompatible (Artistic). So once again: you need to trust the Fiduciary and set up some policy to make sure it all works.

Barriers to entry: This is, in fact, a biggie. It depends on the community creating the software whether asking or requiring assignment will be a barrier or not. I can imagine that in an established loosely-knit community of individual developers (read: the KDE community) introducing assignment is both scary and seen as a barrier to entry. That’s why you could choose the optional-assignment route, for partial centralization. In a corporate led project, assignment may be much less of a barrier. In mixed settings, I think optional-assignment or a really darn good explanation is needed (an explanation that I won’t be able to provide here, as it depends very much on individual circumstance).

Dave writes very briefly: he refers to assignment as a “superfluous barrier to entry”. I disagree with that — it can be superfluous, or, given explanation and circumstances, can be quite necessary. For a project with a community of individuals with no monetization of the software itself planned and an established brand and a broad scope (e.g. desktop projects) it probably is the former.

It’s at this point — in listing items under barriers to entry — that I feel Michael is lacking clarity. There’s a number of problems listed, in the moral, social and organizational spheres, all of which may influence the influx of contributions and affect user uptake of the software. However, I don’t see how these are specific to copyright assignment. When thinking of participating in a project, “the paralysis of uncertainty” can strike for any of a number of reasons. Licensing? Trademarks? Maybe the project is run by complete jerks only I haven’t realized it yet? Perhaps Mr. Knightly does feel affection for Jane Fairfax, and merely dissembles to poor Harriet Smith as a cover? [Sorry, I’ve been reading Jane Austen’s Emma and it will lead to any number of conspiracy theories.] The same applies to corporate unwillingness and scarcity: these are not issues that are particularly brought to a head by copyright assignment, but always exist in open collaborative projects.

The “death of trust” (gosh, isn’t that a melodramatic title) touches on two issues: the trust expressed (or lack thereof) by demanding an agreement beforehand and the issue of recognition when rights have been assigned. The former can be a real barrier to entry — but that was Dave’s point. The latter is easy to deal with, and indeed should be dealt with, by identifying individuals where that makes sense. For instance, my contributions to KPilot (since deceased) should be administered like so in the copyright header in the source files:

Copyright [year] KDE e.V. [contact email]
Author: Adriaan de Groot

The reason for still listing individual authors even after assignment is because of moral rights — pesky non-assignable, non-transferrable, non-heritable (I think) rights. Plus, it’s a means of giving recognition (if so desired) while correctly stating where the copyright (or exploitation rights) resides.

Carrying on to the end — from here until the Recommendations at the end of Michael’s piece I have trouble understanding what the problem is, unless it’s “do not assignments to untrusted parties who have an incentive to proprietize” — we find the Recommendations. Sensible recommendations, by and large. I especially appreciate the suggestion of a proxy for approving license updates — I had not seen that before. But all in all, it comes down to a very old Dilbert punchline: “try identifying the problem, then solving it.” That means considering the role you play (contributor, manager) and the style of contributions to the software and intentions for future growth.

Last week, Diego Iastrubni asked removing GPL code, prompted by MonoDevelop’s announcement that it had removed all the GPL code in its codebase, thus opening the road to proprietary plugins.

Well Diego, there’s an app organization for that. Depending on your jurisdiction, you could ask the Free Software Foundation in the United States, the Free Software Foundation Europe in Europe, the Free Software Foundation Latin America in Latin America (are you seeing a pattern here?). The FSF in the United States is the steward of the GPL (all versions) and the organization in charge of interpreting the intent of the GPL. Of course, certain matters on interpretation will end up in courts — because it is not only about the intent of the license, but also what it actually says.

There are also national centres of competence regarding licensing issues and the use of Free Software. In Finland you might want to ask COSS; in Spain, CENATIC or ASOLIF; in the Netherlands, NOiV; in the United States, the Linux Foundation. Any of those might be able to help out with this kind of question. I won’t pretend that they definitely will: it depends on the context and workload and whether the question makes sense in their context.

Fortunately, an organization like FSFE has education and information provision written into its constitution (but not its budget: support the FSFE to help it continue to help you and the rest of the Free Software world). So here’s an attempt at an answer — which does not constitute legal advice and which does not constitute an interpretation of the GPL.

So let’s follow through Diego’s question:

I have this application which I license under the terms of BSD, and I saw a GPL library (lets call it libbar ) which might help me. I incorporate the library by dinamic linking. Now my application is effectly a GPL binary, sweet.

It is vitally important to distinguish between source and object forms of the software here, as well as keeping track of mechanisms of linking. Let’s try to strip this down to a bare minimum number of components. A program A written entirely by you using no external (third-party) components and released by you under the terms of the 2-clause BSD license. That’s fine. Now suppose you modify your application to use an interface provided by a GPL library (like libbar, in Diego’s example). Does that make your program a work that must be licensed under the GPL? Maybe. Does that make the object form of the program linked to GNU readline a work that can only be distributed under the terms of the GPL? Yes. So you must ship the object with the text of the GPL, with a source code offer (either the complete source or a written offer, as usual). Still, the sources retain the license that you originally put on them (BSD 2-clause, which is GPL-compatible, so this is possible).

Now you replace libbar (the GPL library) with a newly written, 2-clause BSD-licensed, libbar_bsd. It might implement the same API as libbar, or it might implement a slightly different one and you modify your application A accordingly. Does that change the licensing possibilities that you have? Yes. you can release A under the 2-clause BSD license — again, keeping in mind other obligations you might have. If you were forced to re-license the source under the GPL (see Maybe, above), then there may be issues. If you are the sole copyright holder, then of course you can re-license. But you need to double-check any contributions you may have received to the codebase. With the new A, you can release object versions including libbar_bsd, under the 2-clause BSD license.

Lets assume, my application uses (derives classes, whatever) code from libbar. If I remove the GPL code and change it by BSD code – my work even though it does not contain GPL code – it’s a derived work, due to compile time constrains. Am I correct?

I think this scenario has two different interpretations: if A uses functions from the library then — like I said previously — the object is definitely GPL licensed and the source might need to be. But if you actually have derived classes and modified code from libbar, then it’s going to be a great deal more difficult, because your source is in itself a derived work. I’m not sure how to understand the “remove the GPL code” here: if there is no GPL source code in the application and it doesn’t link to any GPL libraries in object form then there’s no reason that the GPL need apply.

Let’s look at Diego’s other scenario:

Lets assume that libbar, uses abstract classes/methods from libfoo (which is BSD). Lets assume that my application uses the interfaces exposed in libfoo, then libbar extends those interfaces, and I am not directly using libbar. When I use my new BSD library, my application is not compiled against any GPL code (just linked to) and it never used it directly. My old code was GPL by run-time constrains and, and the new one is BSD. Am I correct?

In this scenario, application A uses libfoo (presumably unrelated, although it apparently provides functionality to libbar), so there’s no GPL code involved at all. The parenthetical comment “(just linked to)” I don’t understand: why would the application A link to libbar at all if it doesn’t use it and libbar is en independent development?

So that leaves us with that dreaded “Maybe” from earlier. Paul Pacheco commented on Diego’s blog with exactly the right bits of the GPL — the trailer to clause 2 of the GPLv2; GPLv3 doesn’t have the same language. But perhaps even more important, the GPLv2 says:

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

In other words, distributing your work which is both an identifiable part of the whole work and which is not derived from the GPL library (and I’ll claim that using an interface is not in itself sufficient to create a derivative work), then the source continues to be licensable however you like, but the object must be distributed under the GPL. The sources you provide that correspond to that object form must be distributed under the terms of the GPL — strange but true.

It took a little while, but I wrapped up the licenses-as-icons with a summary in tabular form. It’s not on this blog, because I don’t know how to pull in fancy CSS and tables into wordpress. Instead, it lives on one of my personal sites for now. It will move to the FSFE pages in due course, once I’ve had some of the other people in the Freedom Task Force look over it. The page is largely auto-generated now by a little python program that understands the labels given to the different licenses. There is plenty of room for improvement: links to the license texts, better explanations of what the badges mean, etc.

One thing I’m quite happy with is the family overview: it shows which licenses are the same when compared using only the qualities reflected in the badges. So it shows MIT and BSD 2-clause as the same — which I’m willing to accept. Unfortunately, due to the granularity of the badges, it also shows some things together (or at least indistinguishable based on the badges) that do not belong together.

There’s one badge missing: “allows relicensing”, which would for instance distinguish between OSL and AFL (as I pointed out when reading them previously). And it might make sense for every license that gets a warning marker to be excluded from the family groupings entirely, so as to avoid the possibility of confusion there.

Thanks: I’d like to thank Mignon Engel and Egon Elbre for providing icons that can be used to symbolize the different badges. You can switch between the different style sheets in your browser’s View menu (unless you’ve got Safari, which doesn’t support that feature as far as I can tell).

Copyright: Some folks have asked about the license on the icons, the text, these blog entries. Since this is work I do as part of my job for the FSFE, it is copyrighted by my employer — the Free Software Foundation Europe (an independent sister organization representing Free Software in Europe). Most of the materials produced by the FSFE are released under a liberal license, for instance allowing unlimited verbatim copies as long as the copyright notice is preserved (otherwise it wouldn’t be verbatim, right?). However, this material hasn’t been licensed that way yet, so I’d have to answer that right now, it’s “All Rights Reserved.”

Next Steps: Refine the meaning of the badges. Add a relicensing badge. Add another dozen licenses (for instance there’s no Affero versions here yet). Clean up the text. Turn it into a nice booklet. Publish. …? Profit!