# CLA, CAA, CA etc. etc. – let’s get it right **URL:** \ **Category:** 🔮 Meta\ **Created:** [June 14, 2016, 9:30pm UTC](https://help.nextcloud.com/t/cla-caa-ca-etc-etc-let-s-get-it-right/588 "2016-06-14T21:30:53Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![hook](https://help.nextcloud.com/user_avatar/help.nextcloud.com/hook/32/59_2.png) [@hook](https://help.nextcloud.com/u/hook)\ **Post date:** [June 14, 2016, 9:30pm UTC](https://help.nextcloud.com/t/cla-caa-ca-etc-etc-let-s-get-it-right/588/1 "2016-06-14T21:30:53Z")
I realise that there is a certain latent distrust in assigning copyright to an entity, but let’s please call a duck a duck both on the forums as well as in the PR. Here’s a handy overview of the relevant abbreviations: CA = Contributor Agreement CLA = Contributor Licence Agreement CAA = Copyright Assignment Agreement Where CA is a superset of CLA and CAA as well as some alternative methods like the [DCO](http://developercertificate.org/)¹. A _CAA_ is an agreement where the contributor/author transfers/assigns his (full) copyright to the another person (or entity). A _CLA_ is an agreement where the contributors/authors grants another person (or entity) a license – i.e. some of his rights, but retains authorship (and other rights). CLAs can be very diverse, but roughly we distinguish between exclusive and non-exclusive CLAs: - An _exclusive CLA_ can be very similar to a CAA in that you grant (more or less limited) rights to just one person exclusively – i.e. grants an exclusive license. - A _non-exclusive CLA_, on the other hand, is a licence agreement where you grant (more or less limited) rights to a person, but reserve the right to also grant them to others – i.e. grants a non-exclusive license (some well known ones are e.g. GPL, MIT, BSD, Apache, MPL). To make it more concrete: What [ownCloud has in place is a CAA](https://owncloud.org/contribute/agreement/) (with an implicit exclusive CLA fall-back for jurisdictions where full-on transfer of copyright is not possible) – authors _assign/transfer their rights_ to ownCloud, Inc. What Nextcloud has in place (or seemingly [plans to through the C4](https://help.nextcloud.com/t/should-we-adopt-c4/113)) is so called _Inbound ≡ Outbound licensing_, which simply means that the community agrees that it will only accept contributions under the very same (inbound) license as the project’s (outbound) license. This by definition is a CLA. So, please, let’s avoid confusion and properly call ownCloud’s agreement a _CAA_ and Nextcloud’s situation an (as of yet not entirely documented) _non-exclusive Inbound ≡ Outbound CLA_. * * * 1: Developers’ Certificate of Origin is arguably also just a CLA. I am amongs those that argue so as well. ---
**Author:** ![PhilD](https://help.nextcloud.com/user_avatar/help.nextcloud.com/phild/32/192_2.png) [@PhilD](https://help.nextcloud.com/u/PhilD)\ **Post date:** [June 15, 2016, 2:58am UTC](https://help.nextcloud.com/t/cla-caa-ca-etc-etc-let-s-get-it-right/588/2 "2016-06-15T02:58:40Z")
I have been surprised that it would be possible (practical) to function without something that would come under the category of CLA. Any open-source project, when it receives an offered contribution from some person (or company/legal entity…) needs to be reasonably sure that: 1. The offered contribution either really is the work of the person offering it, or that the person offering it has the suitable permission from wherever they got it. 2. That the offered contribution is being offered either completely free (of any encumbrance ever) or in inbound terms that match or are compatible with the outbound license that the project wishes to use. 3. That the offered contribution cannot be “taken back” in the future, or the person attempt to assert some sort of patent or copyright in the future that would force the project to engineer-out that person’s past contributions. (This is really wrapped up in point 2, I am just making it explicit here.) In summary, the project needs to stay as “reasonably certain as is reasonable” that it can offer its code-base under its chosen outbound license in perpetuity without being “brought unstuck” by some contributor. What am I missing here? Surely contributors need to certify something, somewhere about their contribution? ---
**Author:** ![BobJonkman](https://help.nextcloud.com/user_avatar/help.nextcloud.com/bobjonkman/32/90_2.png) [@BobJonkman](https://help.nextcloud.com/u/BobJonkman)\ **Post date:** [June 17, 2016, 7:14pm UTC](https://help.nextcloud.com/t/cla-caa-ca-etc-etc-let-s-get-it-right/588/3 "2016-06-17T19:14:42Z")
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thank you. Those definitions make sense, and provide clarity (for me, anyway). - –Bob. ---
**Author:** ![Bugsbane](https://help.nextcloud.com/user_avatar/help.nextcloud.com/bugsbane/32/172_2.png) [@Bugsbane](https://help.nextcloud.com/u/Bugsbane)\ **Post date:** [July 9, 2016, 8:13am UTC](https://help.nextcloud.com/t/cla-caa-ca-etc-etc-let-s-get-it-right/588/4 "2016-07-09T08:13:24Z")
Yes, I’m curious, too. On the one hand I’ve had files accepted into the codebase without being asked to sign anything, which is nice as a contributor… but at the same time, I’ve never actually stated what license my files are under and presumably if the Nextcloud project ever has to relicense them (say an amazing, perfect fit new FOSS license is one day created) then I would imagine that they’re going to have to contact every single contributor ever… Personally, I’m not against CLA’s. I’m just against the evil ones that set up a massive disymmetry of power between the project asset owners and contributors. I’m perfectly fine with signing something though that states that my assets may be relicensed to another OSI/FSF approved free software license at a later time, based on something like a vote by the majority of contributors.