Community contributions and copyright assignment

Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

Over the course of the last month or so, your editor has been to six conferences on three continents. When engaged in that kind of travel, it is, of course, obligatory to determine which country has the best beer; normally, substantial amounts of research are required. It's also normal to hear what's on one's co-researchers' minds while carrying out this task. This time around, your editor heard grumbles from a surprising number of people, all about the same topic: copyright assignment policies.

In particular, developers are concerned and unhappy about the copyright assignment policy that Canonical has chosen for all of its projects. This agreement [PDF] is a relatively simple read; it fits on a single page. It applies to a long list of projects, including Bazaar, Launchpad, Quickly, Upstart, and Notify-osd; contributions to any of those projects must be made under the terms of this agreement.

So what do contributors agree to? The core term is this:

I hereby assign to Canonical with full title guarantee all copyright now or in the future subsisting in any part of the world in any Assigned Contributions.

So Canonical gets outright ownership of the code. In return, Canonical gives the original author rights to do almost anything with that code.

Assigning copyright to Canonical could well be an obstacle for potential contributors, but there are a couple of other terms which make things worse. One of them is this:

Canonical will ordinarily make the Assigned Contributions available to the public under a "Free Software Licence", according to the definition of that term published by the Free Software Foundation from time to time. Canonical may also, in its discretion, make the Assigned Contributions available to the public under other license terms.

There are many free software developers who might balk at giving their code away to somebody who "ordinarily" will make it available under a free license. And the final sentence is even worse; "other license terms" is, of course, euphemistic language for "proprietary terms."

Finally, there is the patent pledge:

I will not assert or enforce any patent against (a) Canonical (b) anyone who received the Software and/or the Assigned Contributions from Canonical or (c) anyone who received the Software and/or the Assigned Contributions under a Free Software Licence, where that patent is infringed by any of them exercising copyright rights in the Software and/or the Assigned Contributions

This language is likely to be just fine for many developers who have no intention of asserting patents against anybody anyway. But it's worth noting that (1) the patent grant is broad, including anything which might be added to the program (by others) in the future, and (2) there is no "self defense" exception allowing patents to be used to fight off litigation initiated by others. So, to a patent holder, this language is going to look like a unilateral disarmament pledge with unknown (and unknowable) scope. For many companies - even those which are opposed to software patents in general - that requirement may well be enough, on its own, to break the deal.

Contributor agreements abound, of course, though their terms vary widely. One might compare Canonical's agreement with the Free Software Foundation's language, which reads:

The Foundation promises that all distribution of the Work, or of any work "based on the Work", that takes place under the control of the Foundation or its assignees, shall be on terms that explicitly and perpetually permit anyone possessing a copy of the work to which the terms apply, and possessing accurate notice of these terms, to redistribute copies of the work to anyone on the same terms. These terms shall not restrict which members of the public copies may be distributed to. These terms shall not require a member of the public to pay any royalty to the Foundation or to anyone else for any permitted use of the work they apply to, or to communicate with the Foundation or its agents in any way either when redistribution is performed or on any other occasion.

Not all developers are big fans of the FSF, but most of them trust it to live up to those particular terms. The FSF agreement makes no mention of patents at all (though GPLv3 is certainly not silent on the subject).

What about other projects? The Apache Software Foundation has an agreement by which the ASF is granted a license (which it promises not to use "in a way that is contrary to the public benefit or inconsistent with its nonprofit status") but the author retains ownership of all code. Sun's contributor agreement [PDF], which now covers MySQL too, gives Sun the right to do anything with the code, but shares joint ownership with the author. An extreme example is the SugarCRM agreement, which appears to transfer not just the author's copyrights, but his or her patents (the actual patents, not a license) as well.

Agreements like Sun's and SugarCRM's are common when dealing with corporate-owned projects; they clearly prioritize control and the ability to take things proprietary over the creation of an independent development community. More community-oriented projects, instead, tend to take a different approach to contributor agreements. Canonical is being criticized in a way that SugarCRM is not, despite the fact that Canonical's agreement appears to be the friendlier of the two. A plausible reason for that difference is that Canonical presents itself as a community-oriented organization, but it is pushing a more corporate-style contributor agreement.

Canonical's policy is especially likely to worry other Linux distributors. They are often happy to contribute to a project controlled by a different distributor, but they do not normally do so under terms which allow the recipient to take the code proprietary. Licenses like the GPL ensure fair dealing between companies; contributor agreements which allow "other license terms" remove any assurance of fair dealing. It is not surprising that some people are uninterested in contributing code under such terms.

The real sticking point, at the moment, appears to be Upstart. Other distributors either have adopted it or are considering doing so; it does appear to be a substantial improvement over the old SYSV init scheme. In the course of adopting Upstart, these distributors are certain to fix problems and make improvements to suit their needs. But they are rather less certain to contribute those changes back under Canonical's terms. In his wanderings, your editor has heard developers talk about possibly forking Upstart. Another developer claimed to be working on a completely new alternative system for system initialization which would take lessons from Upstart, but which would be an independent development. Neither of these outcomes seems optimal.

Your editor sent in a query asking what prevents Canonical from adopting more contributor-friendly terms, but got no answer over the course of a couple of days. Groups requiring copyright assignment often claim that it's necessary for them to be able to take action against copyright infringers. But the projects which have had the most success in that area - the Linux kernel and Busybox, for example - have no copyright assignment policy. The other thing that copyright assignment allows, of course, is a relicensing of the code. The FSF has made use of this privilege to move its projects to GPLv3; companies like MySQL have, instead, used it to ship code under proprietary terms. One might assume that Canonical has no such intent, but the fact that Canonical has explicitly reserved the right to do so is unlikely to make people comfortable.

When developers contribute code to a project, they tend to get intangible rewards in return. So asking them to hand over ownership of the code as well might seem to be pushing things a little too far. Even so, many developers are willing to contribute under such terms. But there are limits, and allowing a competitor to take code proprietary may well be beyond those limits - as are overly-broad patent grants for contributors who are concerned about such things. Companies which demand such rights may find that their community projects are not as successful as they would like.

