Community contributions and copyright assignment
Please consider subscribing to LWNOver 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.Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.
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:
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:
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:
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:
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.
Posted Oct 28, 2009 17:50 UTC (Wed)
by dmarti (subscriber, #11625)
[Link]
When you transfer a copyright "with full title guarantee" are you in effect offering a warranty of non-infringement? And what does that open you up to in the event of accidental or unconscious copying? (Least attractive proposal ever: "I'm a party to a one-sided agreement with a foreign corporation...will you marry me?")
Posted Oct 28, 2009 18:00 UTC (Wed)
by jimbo (subscriber, #6689)
[Link]
I'd like to see Canonical publish a more thorough explanation of the patent policy, too.
A slightly disappointed Ubuntu fan.
Posted Oct 28, 2009 18:02 UTC (Wed)
by juliank (guest, #45896)
[Link] (3 responses)
Upstart can only be licensed under GPL-compatible terms, since it links
Posted Oct 28, 2009 18:05 UTC (Wed)
by gregkh (subscriber, #8)
[Link] (2 responses)
Posted Oct 28, 2009 18:27 UTC (Wed)
by juliank (guest, #45896)
[Link] (1 responses)
Posted Oct 28, 2009 20:51 UTC (Wed)
by ncm (guest, #165)
[Link]
Posted Oct 28, 2009 18:12 UTC (Wed)
by mcopple (subscriber, #2920)
[Link] (1 responses)
Posted Oct 28, 2009 21:23 UTC (Wed)
by jospoortvliet (guest, #33164)
[Link]
That's why I really appreciate Corbet's articles on this and similar
Posted Oct 28, 2009 18:27 UTC (Wed)
by danpb (subscriber, #4831)
[Link]
Although both MySQL and VirtualBox were already selling code under closed-source licenses before acquisition, the rapid change in ownership to Sun, and then Oracle, nicely highlights how your work can end up in the hands of unexpected players whom you might well not have given copyright assignment to had they been the original owners. So pretty much the only people I'd be happy giving copyright assignment to would be independent, non-profit foundations which are safe from corporate takeovers.
Posted Oct 28, 2009 20:02 UTC (Wed)
by AlexHudson (guest, #41828)
[Link]
"You assign all right[s ..] in all patents, inventions copyrights and related moral rights ("IP Rights") [..] to SugarCRM[. ..] SugarCRM grants to you a non-exclusive [..] license to [..] Your Contributions[..]"
So, if you hold a patent which touches some SugarCRM contribution you make, you lose the patent and any rights to use it outside those SugarCRM contributions.
I'm not going to defend software patents for one second, but that's a pretty spectacular agreement if they think people will sign up for that.
But then you can probably count community contributions to SugarCRM on the fingers of one hand (I've tried).
Posted Oct 28, 2009 21:26 UTC (Wed)
by BrucePerens (guest, #2510)
[Link]
The covenant that I am using for a project I'm working on promises to continue to release our development under an Open Source license for a period of two years, or to remove the contribution from the work. It doesn't mention commercial licenses, we have the right to issue them or not. It applies to our assigns (any company we sell the asset to).
You have to give people a reason to make the assignment, something more than "we'll put it in our maintained source tree which we might make entirely proprietary tomorrow."
Posted Oct 29, 2009 0:16 UTC (Thu)
by ewan (guest, #5533)
[Link] (6 responses)
Posted Oct 29, 2009 2:57 UTC (Thu)
by mchehab (subscriber, #41156)
[Link] (1 responses)
I suspect that the terms of the "contributors agreement" will work, in practice, as a non-GPL license, provided that all contributors to upstart sign it.
For example, imagining that a forked version is created, while the original upstart keeps under GPL, it will be possible for the forked versions to get patches from the official upstart version.
However, as Canonical developers are bound to the agreement, they cannot get the patches from the forked version back to their version without violating the agreement, since they cannot transfer the copyrights from someone else to Canonical, nor give the additional rights that the "contributor agreement" requests.
So, a GPL patch from someone that doesn't sign the agreement is incompatible with their license.
Posted Oct 29, 2009 10:46 UTC (Thu)
by intgr (subscriber, #39733)
[Link]
Posted Oct 29, 2009 14:39 UTC (Thu)
by pjones (subscriber, #31722)
[Link] (2 responses)
Posted Nov 6, 2009 0:17 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
Cheers,
Posted Nov 6, 2009 13:37 UTC (Fri)
by nix (subscriber, #2304)
[Link]
(He *had* been around in the X world forever, though, since 1989 I think.
Posted Oct 31, 2009 9:21 UTC (Sat)
by liljencrantz (guest, #28458)
[Link]
Posted Oct 29, 2009 3:02 UTC (Thu)
by frazier (guest, #3060)
[Link] (6 responses)
Posted Oct 29, 2009 13:59 UTC (Thu)
by Trou.fr (subscriber, #26289)
[Link] (1 responses)
Posted Nov 6, 2009 0:18 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
The reason Brits drink warm beer is that you can actually TASTE the stuff. Most american beer is served chilled, so it anaesthetises the mouth so you can't taste the (lack of) flavour.
Cheers,
Posted Oct 29, 2009 14:18 UTC (Thu)
by corbet (editor, #1)
[Link]
Posted Oct 29, 2009 18:53 UTC (Thu)
by JoeF (guest, #4486)
[Link] (1 responses)
Posted Oct 30, 2009 7:29 UTC (Fri)
by man_ls (guest, #15091)
[Link]
As to keg beer, in most of Andalucía they tend to serve a disgusting yellowish stuff, beware; but in the center (esp. Madrid) you will see in most bars a lot of glasses filled with the most delicious golden liquid. It tastes even better than it looks.
In short, I hope that if our editor ever comes here (or has already) he will get a fair sampling of our goods, so that we get a fair place in the competition.
Posted Nov 11, 2009 23:45 UTC (Wed)
by rstanley (guest, #49163)
[Link]
"Gassed up weasel water!" (Unknown London resident)
"American beer is like making love in a canoe! It's f%$#*&g close to water!" (Monty Python) ;^)
Fortunately, there are a large number of Micro Breweries here in the US that DO know what real Beer/Ale/Bitter/Porter/etc... are.
Determining what country produces the best beer is not only very subjective, but such an ongoing process, that the final answer may never be known! ;^)
Posted Oct 29, 2009 3:36 UTC (Thu)
by dkite (guest, #4577)
[Link] (2 responses)
Now I see that the emphasis on community instead of community being a result
I enjoy a working environment where the word 'team' is uttered in derision,
I'm pleased to see the push back here.
Derek
Posted Oct 29, 2009 18:18 UTC (Thu)
by lysse (guest, #3190)
[Link]
Are they hiring?
Posted Oct 30, 2009 5:03 UTC (Fri)
by frazier (guest, #3060)
[Link]
Posted Oct 29, 2009 6:52 UTC (Thu)
by kripkenstein (guest, #43281)
[Link] (5 responses)
1. My own code in this project is AGPL.
In other words, I am already bundling code with compatible licenses in this project, and people submitting new code under a compatible license is basically like more such code. Or, if they aren't comfortable with a permissive license like Apache or zlib, they can use the AGPL, but then I guess they need to trust me regarding other licenses I use it for.
Does this seem like a fair arrangement? Also, is any project already doing something like this (I can't seem to think of one)? I hope there isn't some fatal flaw I am missing.
Posted Oct 29, 2009 8:34 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (4 responses)
Why not just require that all contributions must be permissively licensed and skip everything else. IIUC, that's what drizzle, a fork of MySQL does and it seems they are very successful is getting community contributors compared to MySQL.
Posted Oct 29, 2009 9:09 UTC (Thu)
by kripkenstein (guest, #43281)
[Link]
Posted Oct 29, 2009 12:22 UTC (Thu)
by sandmann (subscriber, #473)
[Link] (2 responses)
Ie., have them sign something that said "you can relicense it, but you'll have to pay $x to J. Hacker".
Posted Oct 29, 2009 12:58 UTC (Thu)
by kripkenstein (guest, #43281)
[Link]
For example, if you want to relicense a few years later, and can't get ahold of all the original contributors to pay them, that would be problematic. Or if something happened to them you need to find their next of kin.
Maybe it could work in this way: If you relicense, you need to publicly advertise that fact, and the authors then have the option to contact you for $X within 1 year from the announcement.
Not sure how I feel about that approach, though. For one thing, would it be $X per contributor? Then 1,000 lines of patches are the same as 1? Or is it by lines of code? Seems troubling either way.
Posted Nov 6, 2009 0:23 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
I suspect I'd settle for "you give me the right to exempt people from the requirement to provide source, provided the binaries are unmodified".
That way, I could licence commercial companies to sell a binary-only, "proprietary" product, but they would lose the right to make proprietary changes. If they wanted to change the source, they would have to give their changes to me for me to make them freely available, in order to be able to distribute their changes.
Cheers,
Posted Oct 29, 2009 9:02 UTC (Thu)
by cate (subscriber, #1359)
[Link] (6 responses)
AFAIK (IANAL) the moral right cannot be assigned/transferred, and AFAIK using
Thus: IMO Canonical cannot distribute a non-free version of Upstream.
PS: This is probably a lot European-centric, but considering that a lot of
Posted Oct 29, 2009 9:13 UTC (Thu)
by amikins (guest, #451)
[Link] (2 responses)
Posted Oct 29, 2009 9:23 UTC (Thu)
by cate (subscriber, #1359)
[Link] (1 responses)
Posted Oct 29, 2009 10:51 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link]
Posted Oct 29, 2009 10:14 UTC (Thu)
by johill (subscriber, #25196)
[Link] (1 responses)
This is how coding/etc. for money works in Europe too -- you retain your moral rights, but your employer gets _all_ usage rights, which typically includes taking those right away from you so that while you can still claim authorship of the code, you cannot use it in any way.
Posted Oct 29, 2009 10:36 UTC (Thu)
by cate (subscriber, #1359)
[Link]
For a usual software job the usage of a work is nearly clear; but OTOH I'm
I've some more doubts with the change from free to proprietary license.
But if I'm active in free software movement (code and philosophy), if I'm
Anyway IANAL
Posted Oct 29, 2009 16:49 UTC (Thu)
by southey (guest, #9466)
[Link]
Posted Oct 29, 2009 10:45 UTC (Thu)
by addw (guest, #1771)
[Link] (1 responses)
It would be stupid of them to refuse to accept it since much of what they are working with is already under the GPL.
Posted Oct 29, 2009 23:45 UTC (Thu)
by giraffedata (guest, #1954)
[Link]
I believe the article says refuse to accept it is exactly what Canonical will do, stupid or not. And it mentions a few reasons that it might not be stupid. It would be a waste of time to send in a patch to someone who has made it clear he won't use code to which you hold the copyright.
And FSF has been rejecting code like that forever too.
Posted Oct 30, 2009 1:55 UTC (Fri)
by zooko (guest, #2589)
[Link] (1 responses)
Whenever people contribute work to my project -- Tahoe-LAFS -- I ask them (a) can we please have it under the same terms that we distribute Tahoe-LAFS under (which are Free Software and Open Source), and (b) can we please also have a license to use it however we wish including proprietary relicensing. Also I tell them that we will immediately release their contributions under our Free Software/Open Source licensing terms as soon as their contributions hit our revision control repository.
Everybody so far has said yes to (a) and all but two contributors so far have said yes to (b).
Posted Oct 30, 2009 15:25 UTC (Fri)
by dkg (subscriber, #55359)
[Link]
That is, with (a) you're asking your contributors for the right to use, modify, and redistribute their code under the same terms that you've offered them for your code. no one is going to balk at that if they're sending you patches already.
and with (b), you seem to again be asking for a *license*, not an assignment. Canonical (according to the article) is actually asking contributors to sign over the proprietorship of the code itself, along with a broad patent grant, all for the privilege of having the code included in their version of the tools.
i think that's a different deal.
Run this by your fiancee's lawyer?
Community contributions and copyright assignment
--
J
Community contributions and copyright assignment
needed, which may include proprietary ones, see http://bazaar-
vcs.org/BzrFeatures.
with udev, as far as I can tell. Most of the other projects (those using
APT, e.g. via python-apt) can also be only licensed under the GPL because
APT and python-apt are GPL-licensed.
Community contributions and copyright assignment
Community contributions and copyright assignment
whole of udev is licensed under the GPL; so this is a packaging bug. Thanks
for correcting me.
Community contributions and copyright assignment
Community contributions and copyright assignment
Community contributions and copyright assignment
issue shortly... A bit publicity, like this article, will certainly help
:D
issues - and he does it with style :D
Community contributions and copyright assignment
[OT] SugarCRM
FSF has a clear covenant back to the contributor. That's what is lacking from the other agreements.Covenant back
Community contributions and copyright assignment
Community contributions and copyright assignment
> style fork
Community contributions and copyright assignment
Community contributions and copyright assignment
Community contributions and copyright assignment
Wol
Community contributions and copyright assignment
but so did a lot of other people.
Of course Jim Gettys had been around longer but Jim's been around longer
than *anyone*, pretty much.)
Community contributions and copyright assignment
Beer?
Beer?
Beer?
Wol
Results are fuzzy, and my notes are incomplete. It seems that more research will be required...
Beer?
Beer?
As somebody who grew up in Europe, I would put Germany, Belgium, and the Czech Republic in the top three, in no particular order.
Spain is not usually associated with good beer, but we have some pretty strong brands. After I've been abroad and enjoyed multiple varieties, I always come back to my Mahou with delight (and a bit of surprise that it is still the best I've tasted). Ambar from Zaragoza is also very good -- their latest International Expo (dedicated to water) ads said "you will come for the water, you will return for the beer". San Miguel sells very well abroad and it is not bad.
Beer in Spain
Beer?
Community contributions and copyright assignment
thought it was me.
stems from seeing the contributors as a resource to be managed.
and view the process of team or community as a result of mutual respect and
enlightened self interest as opposed to a management method where fuzzy
feelings are elicited to get the benefits and delegate the blame.
Community contributions and copyright assignment
Community contributions and copyright assignment
Advice appreciated on community contributions approach
2. The project bundles some other pre-existing libraries, with compatible licenses, like zlib, Apache, etc.
3. For contributions, I let people either (a) submit it under a compatible license like Apache, in which case they hold sole copyright, or (b) submit it as AGPL, with joint copyright assignment, allowing me to relicense it.
Advice appreciated on community contributions approach
Advice appreciated on community contributions approach
Advice appreciated on community contributions approach
Advice appreciated on community contributions approach
Advice appreciated on community contributions approach
Wol
I see no problems
a software in a non-free manner could violate the author intentions about the
code. IMHO the Canonical agreement is too weak to imply proprietary license,
and a simple "This is free software" on every file (as it is in normal use)
clear the author intentions.
developers write software in Europe, it is a good deterrent to bad things.
I see no problems
actually as problematic as our editor explains. Europe's concept of 'moral
rights' does not exist in the US, and is not a dominant concept throughout
the world (although it does show up in other areas if I remember correctly).
I see no problems
developers to block proprietary changes. And fortunately this block is valid
in all the world.
I see no problems
I see no problems
I see no problems
you cannot give the *all* usages. (see the curt rules about moral rights)
pretty sure that if my employer will use my code for malware (and it was
not a scope of my code and my company), I can block it (I'm in every case
the author of the code, so my reputation could suffer).
know n to be a "purist" and I contribute to a free software (maybe Upload),
my reputation will suffer with a proprietary change in license, whenever
the Canonical agreement I signed (the program is clear marked as free
software, and there is nothing so explicit about turning in a proprietary
software). This is an extreme, but IMHO it is also valid (with some more
doubts) to usual developers.
Irrelevant argument
Just send in a patch ...
Just send in a patch ...
It would be stupid of them to refuse to accept it since much of what they are working with is already under the GPL.
Community contributions and copyright assignment
Community contributions and copyright assignment