Hacker Newsnew | comments | show | ask | jobs | submitlogin

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.

FWIW, I collected a lot of links to various anti-CLA materials in my anti-Harmony blog post: http://ebb.org/bkuhn/blog/2011/07/07/harmony-harmful.html

-----


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).

-----




Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: