Bobulate

The IFOSSLR — the International Free and Open Source Software Law Review — has published issue #3. The IFOSSLR is the only journal dedicated exclusively to Free Software legal issues. While I was the FTF-Coordinator at the FSFE it was great to see the careful legal thought put into all kinds of issues (from trademarks to license assignment to risk assessment). It’s important to have an understanding of the legal issues around Free Software (both development and deployment) that is business compatible. That’s not to say that the interpretation is adapted to suit the desires of business — no, it means that the understanding is formulated in a way that businesses understand. It’s quite important to state cause and effect or obligations and rights carefully so that businesses understand what to do and how to do it right. After all, most Free Software developers want everyone to play by the rules set out in the license.

Sometimes what’s necessary from a business standpoint isn’t what we’d like from a Free Software perspective, but there’s no basis for real complaint. The licenses say what they say (which is why you should be careful in picking a license!), and with a good understanding of what they actually mean, both developers and business using the fruits of that development can get on with what they do. See for instance this bit on the Freecom Music Pal (I have one of those too; it’s OK for listening to Country 105 but the author is right that it’s rather difficult to hack and the firmware is wretched).

The IFOSSLR is available gratis as a PDF, or you can get a printed copy via LuLu. I’d suggest the latter, because legal journals just look really impressive on paper.

As a collaborative publication, the IFOSSLR is always looking for submissions, too. See the Call for Papers for issue #4 for more information. It’s not just for lawyers — the perspective of community and developers on legal issues is really important. The practice of Free Software licensing is an interesting area because there are four (no, wait, six) parties involved: the drafter of the license, the developer using the license, the user of the software released under that license, the community (c.q. peanut gallery) of users of the license, the lawyers for each of the aforementioned parties and the courts. Getting all that to align in harmony is a big task: a task that requires communication and publication. So throw your thoughts into the fray.

Compliance engineering as a topic covers those activities that make it possible to ship a (consumer electronics) product that complies with the license(s) of the software contained in that product. That includes things like: figuring out what software actually is in the product (you’d be surprised how often vendors don’t even know); ensuring that you know what configurations and versions were chosen to put in the product; finding out what the licenses on those versions of the software are; finding out out what the obligations under those licenses are; and finally actually doing what those obligations demand. Hence, comply.

Comply or explain (to one of the organizations that look into enforcing software license obligations, like the BSA or gpl-violations.org).

The FSFE has long had a brief article on how to report and fix violations and Armijn Hemel at Loohuis Consulting has written a fairly lengthy compliance engineering guide (also some articles on LWN).

One popular license for software that tends to end up in consumer electronics products is the GPL. Either version 2 or version 3. It has some specific obligations that make compliance both important and sensitive. Those are the clauses requiring the complete corresponding source code, which means you need to know what the code is and how to provide it. It also means that for every binary release you need to provide the sources that can be used to create exactly that binary release. Not every company does that consistently.

Heck, I’ll name names: Conceptronic, a Dutch consumer electronics company, tries hard to comply. It delivers source code for the firmware shipped with the original release of devices, and it sometimes updates the available source tarballs. But not always. Dennis, the guy responsible, knows this is a problem. He tries, but time pressure and the upstream don’t always make it possible to do the right thing.

So there’s a company technically in the wrong where I’m willing to believe that they could be in the right if there was a little less effort involved, or a little better support in the compliance engineering process.

Enter, once more, Armijn and Shane, in their business guises of Loohuis Consulting and Opendawn Consulting. They work, shall we say, both sides of the fence: both in helping people improve their compliance processes and in tracking down violators later. For both sides, knowing which sources should have been supplied with a given binary release is of paramount importance.

So Shane and Armijn — supported by the Linux Foundation and Stichting NLnet — have produced a tool that helps in identifying what software has gone into a binary firmware image. It’s still in its infancy, but it can usefully detect Linux kernel versions, Busybox versions and configurations. That means it can be used — for products containing those pieces of software — to answer questions like “what sources and configuration files and scripts should be delivered with this product?” And that’s important because of the requirement in the GPL to provide (when necessary as defined by the other license obligations) the complete corresponding source code. Not just a bunch of tarballs and a “figure it out” notice; not just the upstream code, but whatever patches went into the device as well; and preferably not a whole bunch of extraneous cruft, either.

The tool makes it easier to do compliance checking from the outside, and easier and cheaper (as in Free beer) to do basic checking on the inside. It’s no replacement for a dedicated compliance engineer, but it does help a lot in answering questions about “what’s in here?” before firmware goes out the door.

I should add that the tool understands some common firmware packaging styles, so it will find and unpack and check things in a squashfs image. Upcoming features will add more filesystems, like concatenated squashfs filesystems, which will save a lot of time compared to running od -c, grepping for magic numbers, dd-ing things apart and then loopback mounting parts individually — that will become automatic.

You can find the tool (which is Free Software under the Apache license) at BinaryAnalysis.org. BA to the rescue. Man, I love it when a plan comes together.

The third edition of the FTF’s Amsterdam Legal Workshop is behind us. Two days of excellent weather (for Amsterdam in April, anyway), good food and in-depth legal wrangling on a variety of to pics. Like patents and how to work to defuse them for businesses and Free Software projects. Canonical kindly provided the nicest lawyer in Europe and a speaker who could rush 168 slides in 20 minutes, so their input is greatly appreciated as well. It was good to see friends from HP as well for the engineers-and-lawyers perspective.

Each year the event brings in new faces and new topics, and we’ve grown to the point where we have traditions and can afford a little bit of silliness amongst the serious talks and the networking and the hashing-out-of-issues-left-hanging-elsewhere. So near the end of the conference I got to hand out custard cream cakes of merit and one attendee asked me “so where’s your pink whip?” That, though, would mean spilling too much KDE over into the FSFE, which is something that’s not going to happen.

That picture over there is the group photo — at least, the one I can publish, because I haven’t cleared the publishing rights to pictures of the conference participants nor the (potentially copyrighted) images on their T-shirts. And of course, even a room full of happy lawyers should not be provoked.

Planning is getting underway for next year already — that was my big failure this year, to get started early enough, so this is overcompensating a little — and we’re aiming for the same week of April, 2011 (say the 7th and 8th). Next year Easter is much later, so the workshop and the holiday clash less. Location to be decided — if we’re ever going to break free of Amsterdam, it needs to be done now.

Today is the first day of the Amsterdam Legal Workshop — in full I suppose that’s called the Free Software Foundation Europe’s Freedom Task Force European Legal Network yearly workshop in Amsterdam. As in 2008 and 2009, we have a room full of the top lawyers and technologists in the Free Software legal field. Thanks to the organizational efforts of Shane, Karsten, Hugo and Rainer we’ve got a full two days of talks and demonstrations. As in past years, new relationships develop as we bring different parties to a neutral, private conference. We also take stock of where we are on a global scale with respect to Free Software licensing and legal issues. Glyn Moody was kind enough to open up the conference with a talk on the (singular) conversion from analogue to digital which — as is Glyn’s wont — ties together the past and future and fields of law, biology and computer science. And from there, we’ve gone off into deep legal territory which I won’t write about, but it’s an education.

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