Coming up with a Copyright Assignment Strategy


One of the deep ironies of the free software world, which is predicated on freedom, is that it effectively requires people to become experts in copyright, an intellectual monopoly that is concerned with restricting freedom. That's because the GNU GPL, and licences that have followed its lead, all use copyright to achieve their aims. At times, though, that clever legal hack can come back to bite you, and nowhere more painfully than in the field of copyright assignment.

The problem is this. Copyright in code belongs to the person who wrote that code. This creates a difficulty when code is contributed by multiple programmers to a free software project. If the original coders retain the copyright for their contribution, the program becomes a kind of patchwork quilt of rights.

That's exactly the situation for Linux, currently made available under the GNU GPLv2, and why it is extremely unlikely that it will ever be re-licensed under GNU GPLv3: there are simply too many people involved – some of whom may be hard to find or even dead – to hope that everyone's agreement can be obtained to relicense the code.

This issue is partly why the FSF requires all those who contribute code to FSF projects to assign the copyright for that code. Here's what it says on the subject:

Under US copyright law, which is the law under which most free software programs have historically been first published, there are very substantial procedural advantages to registration of copyright. And despite the broad right of distribution conveyed by the GPL, enforcement of copyright is generally not possible for distributors: only the copyright holder or someone having assignment of the copyright can enforce the license. If there are multiple authors of a copyrighted work, successful enforcement depends on having the cooperation of all authors.

In order to make sure that all of our copyrights can meet the recordkeeping and other requirements of registration, and in order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment, and, where appropriate, a disclaimer of any work-for-hire ownership claims by the programmer's employer. That way we can be sure that all the code in FSF projects is free code, whose freedom we can most effectively protect, and therefore on which other developers can completely rely.

The FSF is not the only one that requires such assignments. Most of the major open source companies also demand it. In part, it's for the same reasons that the FSF needs it: it's just messy if you don't. But mostly it's because it gives open source companies the ability to offer the code under different, possibly non-free licences. And that dual licensing, of course, is probably currently the most popular way to generate revenue from GPL'd code.

Until recently, that's seemed a reasonable approach. But people are beginning to realise there are some big downsides to this kind of copyright assignment. For example, it introduces an asymmetry in the relationship between the company holding the copyright and all other parties. While the latter can take the code and offer it commercially, say, they can't offer it under a non-free licence. This means that they cannot compete on completely equal terms with the copyright holder, which has a unique advantage in this respect. That seems to go against the spirit of free software, which is that everyone is equal, and has the same rights and privileges.

Just why that can be problematic has become evident with Oracle's bid to buy Sun, and hence MySQL. Because Sun owns the copyright to all the code, Oracle would acquire that copyright with the company. That would then give Oracle asymmetric rights over the code that are potentially worrying given that it could exploit them to the detriment of the MySQL community, and to the advantage of its own closed-source offerings. Because of that asymmetry, it would be hard for the open source community to do anything about it: forking the MySQL code would be possible, but offering non-free licences would not, which would probably limit the popularity of any such alternative.

The rather unedifying spectacle of people arguing the pros and cons of the Oracle acquisition have focused many people's attention on copyright assignment for perhaps the first time This makes Michael Meeks' recently-published essay on the subject extremely timely and valuable.

It begins with a very detailed run-down on historical situations where copyright assignment has been an issue for free software, including XEmacs vs. Emacs, KDE, GNOME, Ximian and Then there is a look at the respective benefits and risks of adopting different forms of copyright assignment. There are lots of insightful comments about the (many) disadvantages of assigning copyright to a commercial entity, and the analysis culminates with this rather damning comment:

The combination of these risks, pragmatically appears to lead to a self-stultifying community. Companies that demand assignment, typically attract very few external contributions; so for example we hear that "it is a fact that MySQL was almost fully developed by employees of MySQL Ab and later Sun's MySQL division". Similar patterns appear to hold for other projects. This in turn can become a self-reinforcing argument: no-one else is contributing, so why should we open up ? When no-one else is contributing because the project is insufficiently open, that is a sad attitude.

I am not aware of a single project that mandates copyright assignment to a corporation that has a diverse, and thriving developer community. If there was even one, the business model of "communitising" a code-base, then firing all your developers, sitting back, and collecting an effort-free rent might become attractive. In contrast I am aware of many diverse and thriving communities that have eclectic ownership, and also some less thriving ones that are dominated by single entities.

Meeks offers some examples of such “diverse and thriving communities”:

Of course, there are a number of entities run by foundations that aggregate copyright that appear to do remarkably well despite that. Common examples are the Eclipse and Apache foundations. These appear to neutralize some of the worst problems of copyright assignment by several approaches: first by eschewing an asymmetric licensing model ie. all users get the same license - a liberal (non-copy-left) one. Secondly, they provide strong, stable, governance structures, that include the major players, and that avoid the possibility of disruptive change. Finally in the case of Apache they actively work to exclude politics from the technical sphere of the project; decisions are based as purely as possible on technical merit.

Personally, I think assigning copyright to such independent foundations is the way forward. Assigning it to a company has too many downsides, and not enough benefits for anyone other than that company. And even the latter suffers in the long term through the lack of community involvement. And without that engagement, the code is open source only in name: it enjoys none of the really important benefits that opening and sharing code can bring.

That's not to say that creating such foundations is unproblematic: funding them sustainably is one major issue. Governance is another: the last thing we want is to replace an autocratic corporate ownership of copyrights with a similarly inscrutable control by some unaccountable body.

Meeks' analysis offers no easy solutions, but does make plain the disadvantages of the current model of copyright assignment, and the need to come up with something better. I urge everyone who cares about the evolution of free software, particularly in a commercial context, to ponder the issues it raises.

Follow me @glynmoody on Twitter or

"Recommended For You"

Cisco, Free Software Foundation settle lawsuit Open source GPL licence upgrade set for Friday