• 1
I think there is a significant argument to be made on behalf of the agreement. GPL essentially mandates that all code derived from it must also be GPL. Further copyright law seems to mandate (in the case of complex code bases) that all contributors must agree to change the license of a work. This can come together in a nasty way when an organization which has done 99% of the work wishes to make changes to it and the other 1% don't agree.

The works will always be GPL (by definition), it feels to me Canonical is acting to ensure that it has the same freedoms other projects have to change to a license of their choosing. Contributors who do not agree with this need only not contribute. Having read Planet Ubuntu it is becoming increasingly apparent that a non-trivial number of contributors are working on Unity. It seems to me that people are willing to work with copyright assignment.

As an open source developer myself who has always licensed GPL, I see no reason not to release my code to Canonical. It is GPL, it will always exist in some GPL form. This seems better to me than the codebase being MIT licensed and requiring all contributions being MIT (which they could have done and would likely have caused less trouble). At least this way I am sure my (metaphorical) code will always exist in some GPL form.

Actually, by assigning copyright to Canonical (or any other single entity), you're making it feasible for them to change the license to something other than GPL.

Under the normal situation where copyright is held by individual contributors, a change of license is almost impossible to achieve (for better or worse). But when all those individuals give away those rights, there's nothing stopping the organisation that holds them from taking everything proprietary.

Sure, the existing code remains open, but the infrastructure and organisation for developing it instantly disappears. You can fork the last available version, but getting such a fork going can be a real challenge.

Correct, at least the original submission will always be GPL. I guess I just am curious if the community would be so against this if the license were MIT/X11? I can't think of anything Canonical couldn't do with an MIT project that can do with the current setup. The only difference here is other companies cant pilfer the code for proprietary projects except for Canonical, which seems fair to me since they are paying for the vast majority of the development.

By using a contributory license agreement, they ensure they will end up having to pay for pretty much all of the development which is a self fulfilling prophecy. Besides, other organizations like Red Hat fund a lot of projects, many of which they have started without forcing contributors to sign over their copyright. So just because you pay for some of the development does not give you the right to come up with such draconian license agreements

This still does not answer my basic question. What is the difference between this and an MIT license situation?

You answered it yourself. MIT license is permissive to *everyone*. Copyright assignment involves tilting the level playing field in favor of the commercial entity having power to relicense however they want but noone else has it and therefore such a power grab is considered problematic and equivalent to free labor and unpaid contract work for Canonical.

Assignment copyright to a company is not a good idea

Assignment copyright to a company is not something I'd like to do when I'm contributing to a free software project, even when this company seems to be free software friendly. It makes me feel like an worker without wage. It binds the project to the company fate.

Re: Assignment copyright to a company is not a good idea

Exactly. There are two philosophies at play here: free sharing and proprietary ownership. Canonical wants to have it both ways: others share freely, but then it gets total ownership. Sort of trying to have its cake and eat it too.

translators working inside of the landscape translation process for Unity and other Canonical built software programs aren't required to sign a copyright agreement. They are required to license their translations as BSD, but are not required to sign an assignment agreement. It seems a bit nonsensical to require copyright assignment for the underlying text but not the translations of that text into different langauges.


oops s/landscape/launchpad/

Joint assignment

Personally, I have much less of a problem with an agreement like the one Sun switched to for OpenOffice.org: a *joint* copyright assignment. It gave Sun a full independent copyright interest in your changes, but still ensured that you retained all rights to your changes. So, Sun could do whatever it wanted with the changes, and so could you.

I wish that the GNU project would do something like that as well.

Re: Joint assignment

Join assignments sound good on paper... but in practise they can been a nightmare in terms of enforcement. Because once you have joint assignment any enforcement action would have to first verify that the other joint assignees have not entered into a licensing agreement with the party you feel are abusing your rights. There is a lot of case history with regard to join copyright assignment in terms of inheritance of copyright for musical works when siblings are given join copyright ownership to an original work.

Aggregate ownership of a larger work where multiple individual pieces are owned by clearly defined entities are actually less problematic in this regard than any joint ownership arrangement.


Not all copyright assignment is created equal

The H Online has a comprehensive article Once bitten, twice shy (http://www.h-online.com/open/features/Copyright-assignment-Once-bitten-twice-shy-1049631.html).

It also includes links to some other good coverage of problems with copyright assignment:

  • Dave Neary - Copyright assignment and other barriers to entry (http://blogs.gnome.org/bolsh/2009/04/08/copyright-assignment-and-other-barriers-to-entry/)

  • Michael Meeks - Some thoughts on Copyright Assignment (http://people.gnome.org/~michael/blog/copyright-assignment.html)

  • Jonathan Corbet (LWN) - Community contributions and copyright assignment (http://lwn.net/Articles/359013/)

  • Bradley Kuhn - Not All Copyright Assignment is Created Equal (http://ebb.org/bkuhn/blog/2010/02/01/copyright-not-all-equal.html)

Bradley Kuhn's article is particularly insightful IMO. It points out that, like all the other corporations, Canonical deflects criticism of a copyright assignment policy by pointing to the FSF's copyright assignment policy.

But, as he wrote in a later article Canonical finally on record (http://ebb.org/bkuhn/blog/2010/10/17/shuttleworth-admits-it.html):

I've often asked Canonical employees[…] to explain[…] why, having received a contributor's copyright assignment, Canonical, Ltd. refuses to promise to keep the software copylefted and never proprietarize it (FSF, for example, has always done the latter in assignments). When I ask these questions of Canonical, Ltd. employees, they invariably artfully change the subject.

Thanks to Laura for the insight from another person attempting to work with the free software held by Canonical and seeing problems with their policy.

Don't let any corporation or other organisation try to distract with the “well FSF do it too!” response. The FSF has software freedom as its core charter, and in addition it makes very explicit promises about what will be done with works contributed under the copyright assignment.

Don't accept a copyright assignment to any organisation without ensuring the copyright holder can't unilaterally redistribute the work under non-free terms (http://www.fsf.org/blogs/rms/assigning-copyright). To my knowledge, the FSF's copyright assignment is the only one which does ensure that, so all the others need to stop pointing at the FSF until they do the same.

  • 1

Log in