|
|
Subscribe / Log in / New account

CLAs vs CAAs

CLAs vs CAAs

Posted Aug 10, 2011 11:44 UTC (Wed) by tfheen (subscriber, #17598)
Parent article: Desktop Summit: Copyright assignments

I wish people would not use the word CLA when talking about copyright relicencing agreements. CLA has been in used by projects such as the Apache project for more than ten years in another meaning, namely making the licencing of code submitted explicit rather than implicit.


to post comments

CLAs vs CAAs

Posted Aug 10, 2011 12:28 UTC (Wed) by rfontana (subscriber, #52677) [Link] (3 responses)

The CLAs most commonly in use, which are typically modeled on those of the ASF, /are/ essentially equivalent to copyright assignment agreements in their main feature, providing the broadest possible outbound licensing power to the CLA inbound licensee, a point I made at my recent OSCON talk (slides at http://aleatoric.org/talks/oscon2011/).

As I noted at OSCON, there is a lot of confusion over CLAs, but part of that confusion - the perception that CLAs "are" copyright assignments - is in a way as correct as it is incorrect.

The Apache CLA does not merely "make the licensing of the code submitted explicit", though in the rather special case of ASF projects licensed under the Apache License 2.0 it is practically equivalent to that, because the outbound license is nearly as permissive as the inbound CLA.

CAA exclusivity. CLA inbound, Apache outbound.

Posted Aug 11, 2011 13:59 UTC (Thu) by sladen (guest, #27402) [Link] (2 responses)

  1. CLAs and CAAs could be considered related for the mere act of enabling distribution to happen, but I believe that there is one significant functional difference: A copyright assignment agreement is exclusive (can only be given to one entity), where-as a copyright licence agreement can be signed and the contribution offered to many projects in parallel.
  2. You last point raises an interesting question: Given the (above) stated similarity of most CLAs to the Apache CLA—are you comfortable with an organisation that requests a CLA inbound, and then distributes those contributions outbound under the Apache Licence?

CAA exclusivity. CLA inbound, Apache outbound.

Posted Aug 11, 2011 14:07 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

A copyright license is only meaningfully non-exclusive if your work isn't a derived work of the existing work. If I write a patch for upstart and sign the Canonical CLA, I can't then give that patch to someone else under another CLA - I'd be violating the GPL. This obviously isn't a problem for sufficiently permissive licenses, but then there's almost no practical point in having a CLA if the work is permissively licensed.

CAA exclusivity. CLA inbound, Apache outbound.

Posted Aug 11, 2011 16:19 UTC (Thu) by rfontana (subscriber, #52677) [Link]

On your point 1, yes, but open source/pseudo-open souce projects requiring copyright assignment invariably give the contributor a grant-back maximally broad copyright license (as to the contribution) and so the contributor is largely free to do all the things the contributor could have done with ownership, other than sue for copyright infringement on that code (as opposed to say a derivative work of that code) or engage in subsequent assignment of the original code (as opposed to subsequent modifications).

On your question: I find that unobjectionable if the original Apache CLA is used, or some equivalent variant or counterpart, though I consider the CLA an unnecessary and counterproductive layer of complexity in such a case. Especially apparent if you read it very closely, the Apache CLA doesn't really give you anything you wouldn't already have if you just used the Apache License inbound (note btw the Apache License 2.0 has an ingenious built-in inbound==outbound contributor agreement, largely overlooked). Other CLAs, including modifications of the Apache CLA, could be problematic for various reasons.


Copyright © 2024, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds