> I'm not really sure why Canonical doesn't just GPL like everyone else and leave it at that.
Because they want to be able to have the benefits of proprietary code for themselves (being able to provide their own software under a proprietary license to other parties), without allowing anybody else that same ability.
If it were under the GPL and each contributor retained their copyright over their submission (as is the case with the Linux codebase), this wouldn't be an issue. But by having complete ownership over all the code in the codebase, Canonical is free to change the license at any time they choose.
> If it were under the GPL and each contributor retained their copyright over their submission
DISCLAIMER: I'm not a lawyer, everything I say below may be totally wrong.
As far as I know, this is exactly what happens. Canonical's Contributor License Agreements stipulates a form of joint copyright assignment where both Canonical and the author have ownership over the contribution, thereby creating two source trees: one on which Canonical has full control over, the other owned by the collective of individuals who contributed to the project (just like the Linux kernel).
Even RedHat requires you to sign a similar CLA in order to accept contributions for Fedora, 389 Directory Server (LDAP), etc. The FSF does something similar for their project, so does Node, Apache, etc. Canonical's CLA used to be nasty but since they started using the Harmony Agreements I think their terms are reasonable.
Personally, as long as they don't ask me to relinquish all and every right on my contribution and/or ask for unreasonable provisions, I'm fine with a CLA.
This is incorrect. Canonical formerly used a (non-joint) copyright assignment agreement, which was widely criticized. It later sponsored the Harmony project which was an unsuccessful effort to popularize a standardized suite of contributor agreements. When the Harmony agreements were released in 2011, Canonical began using one of the Harmony CLAs. It doesn't stipulate copyright assignment; rather, the contributor grants Canonical a broad copyright license that is similar in effect to copyright assignment except that the contributor
retains copyright ownership of the contribution. It is not dissimilar in policy to the widely-used Apache model of CLAs. I'm a strong critic of CLAs generally, particularly these types, but they ought to be described accurately. The effect of use of such CLAs by entities that will (by employment of a majority of developers, say) hold copyright over much of a relevant codebase is that you have little pieces of code that are owned by outside contributors but licensed in under
maximally broad terms which basically give the inbound entity the ability to do whatever they want with the code, short of assigning copyright in it.
> Even RedHat requires you to sign a similar CLA in order to accept contributions for Fedora, 389 Directory Server (LDAP), etc.
No (with some legacy use of Apache-style CLAs basically confined to some JBoss projects and gradually being dismantled).
I've been Red Hat's open source lawyer since 2008 so I think I can speak authoritatively on this. Red Hat does not use a similar CLA for contributions to Fedora (though at least nominally it used an Apache-style CLA prior to 2010). Since 2010 Fedora account holders agree to the Fedora Project Contributor Agreement (http://fedoraproject.org/wiki/Legal:Fedora_Project_Contribut...) which is a simple agreement that says code is licensed by default under the MIT license (and content under CC BY-SA) unless the contributor indicates otherwise. 389 basically followed the Fedora approach for reasons best understood as historical inertia (by coincidence I noticed last night there is some incorrect information
about this on the 389 website).
Red Hat starts up tons of open source projects, and most of them do not require contributor agreements. When I got to Red Hat in 2008 this was already the case, if only because of the nature of Red Hat's culture at the time. But the company was on the verge of applying a uniform (Apache-style) CLA requirement across all Red Hat-maintained projects -- much like so many companies do today. I very soon realized how problematic that would be and I think one of my big accomplishments was not only to stop that from happening but also to reverse it (the trend for that set of projects that used CLAs in the past has been to get rid of them), and to formulate a strong legal-policy basis for doing so, maybe best recorded in my two-part critique of the Harmony contributor agreement suite in 2011: http://opensource.com/law/11/7/trouble-harmony-part-1 .
So please do not use Red Hat as evidence of support for use of broad contributee-friendly contributor agreements. Red Hat has been the leading company, maybe the only company, articulating an alternative viewpoint.
[Edited to fix formatting and to tone down initial scorn slightly]
[Edited to acknowledge JBoss situation]
[Edited to note Harmony agreements unsuccessful in that few use them]
@fontana, while I think Red Hat's Fedora CLA is better than most, I still think it's problematic that its fallback is a highly lax, permissive license, rather than "license of the project". I still don't understand why Red Hat won't default to inbound=outbound for Fedora.
The 'default to MIT' idea was developed primarily by Tom Callaway. The policy for documentation is in effect inbound/outbound since CC BY-SA became the standard Fedora docs license at a certain point (replacing the horrific OPL).
I think it has to be understood in light of the historical circumstances that existed during 2008-2009: the fact that Fedora had begun using an Apache-style CLA a few years earlier, and the fact that Red Hat was, for a moment, contemplating broad use of an Apache-style CLA (until about mid-2008).
"License of the project" certainly makes sense for nearly all FLOSS projects. Certain aspects of what distros do might be a little different though. Fedora is a project but it has no true 'license' as such other than the sum total of all the licenses of the pieces of the distribution and other things associated with the project (such as infrastructure projects and wiki content). So there's no single "license of Fedora". There are some Fedora-specific projects where 'license of the project' would work and I would say for those projects the Fedora contributor agreement is of dubious value. The other scenario, and the main one originally contemplated for the Fedora CLA, was the somewhat absurd case of RPM spec files. It's not clear to me that spec files, to the extent copyrightable, should match the 'license of the project' being packaged (which is often not pin-down-able to a single license).
The thing about CLAs, I always figured that if I'm working for a company (by giving them license to close-source my contribution to a not-BSD-flavor licensed codebase), I should be getting paid.
OFC small changes or contributions to something like the FSF have to be judged differently, but thats the big picture.
Because they want to be able to have the benefits of proprietary code for themselves (being able to provide their own software under a proprietary license to other parties), without allowing anybody else that same ability.
If it were under the GPL and each contributor retained their copyright over their submission (as is the case with the Linux codebase), this wouldn't be an issue. But by having complete ownership over all the code in the codebase, Canonical is free to change the license at any time they choose.