From eb62a98e0fc7e657409474fb42ff0c7a4b071fb9 Mon Sep 17 00:00:00 2001 From: epriestley Date: Fri, 27 Nov 2015 11:28:57 -0800 Subject: [PATCH] Document the CLA in more detail Summary: Provide a long-form description of why we require a CLA and the distinction between the individual and corporate CLAs. See Q219 and Q97. Test Plan: Reading. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D14578 --- src/docs/contributor/cla.diviner | 169 +++++++++++++++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 src/docs/contributor/cla.diviner diff --git a/src/docs/contributor/cla.diviner b/src/docs/contributor/cla.diviner new file mode 100644 index 0000000000..fde2e7cf6e --- /dev/null +++ b/src/docs/contributor/cla.diviner @@ -0,0 +1,169 @@ +@title Understanding the Phacility CLA +@group detail + +Describes the Contributor License Agreement (CLA). + +Overview +======== + +IMPORTANT: This document is not legal advice. + +Phacility requires contributors to sign a Contributor License Agreement +(often abbreviated "CLA") before we can accept contributions into the upstream. +This document explains what this document means and why we require it. + +This requirement is not unusual, and many large open source projects require a +similar CLA, including Python, Go, jQuery, and Apache Software Foundation +projects. + +You can read more about CLAs and find more examples of companies and projects +which require them on Wikipedia's +[[ https://en.wikipedia.org/wiki/Contributor_License_Agreement | CLA ]] page. + +Our CLA is substantially similar to the CLA required by Apache, the +"Apache Individual Contributor License Agreement V2.0". Many projects which +require a CLA use this CLA or a similar one. + + +Why We Require a CLA +==================== + +While many projects require a CLA, others do not. This project requires a CLA +primarily because: + + - it gives us certain rights, particularly the ability to relicense the work + later; + - it makes the terms of your contribution clear, protecting us from liability + related to copyright and patent disputes. + +**More Rights**: We consider the cost of maintaining changes to greatly +outweigh the cost of writing them in the first place. When we accept work +into the upstream, we are agreeing to bear that maintenance cost. + +This cost is not worthwhile to us unless the changes come with no strings +attached. Among other concerns, we would be unable to redistribute Phabricator +under a different license in the future without the additional rights the CLA +gives us. + +For a concrete example of the problems this causes, Bootstrap switched from +GPLv2 to MIT in 2012-2013. You can see the issue tracking the process and read +about what they had to go through to do this here: + +https://github.com/twbs/bootstrap/issues/2054 + +This took almost 18 months and required a huge amount of effort. We are not +willing to encumber the project with that kind of potential cost in order to +accept contributions. + +The rights you give us by signing the CLA allow us to release the software +under a different license later without asking you for permission, including a +license you may not agree with. + +They do not allow us to //undo// the existing release under the Apache license, +but allow us to make an //additional// release under a different license, or +release under multiple licenses (if we do, users may choose which license or +licesnes they wish to use the software under). It would also allow us to +discontinue updating the release under the Apache license. + +While we do not currently plan to relicense Phabricator, we do not want to +give up the ability to do so: we may want or need to in the future. + +The most likely scenario which would lead to us changing the license is if a +new version of the Apache license is released. Open source software licenses +are still largely untested in the US legal system, and they may face challenges +in the future which could require adapting them to a changing legal +environment. If this occurs, we would want to be able to update to a newer +version of the license which accounted for these changes. + +It is also possible that we may want to change open source licenses (for +example, to MIT) or adopt dual-licensing (for example, both Apache and MIT). We +might want to do this so that our license is compatible with the licenses used +by other software we want to be distributed alongside. + +Although we currently believe it is unlikely, it is also possible we may want +to relicense Phabricator under a closed, proprietary, or literally evil license. +By signing the CLA, you are giving us the power to do this without requiring +you to consent. If you are not comfortable with this, do not sign the CLA and +do not contribute to Phabricator. + +**Limitation of Liability**: The second benefit the CLA provides is that it +makes the terms of your contribition explicitly clear upfront, and it puts us +in a much stronger legal position if a contributor later claims there is +ambiguity about ownership of their work. We can point at the document they +signed as proof that they consented to our use and understood the terms of +their contribution. + +//SCO v. IBM// was a lawsuit filed in 2003 alleging (roughly) that IBM had +improperly contributed code owned by SCO to Linux. The details of this and the +subsequent cases are very complex and the situation is not a direct parallel to +anything we are likely to face, but SCO claimed billions of dollars in damages +and the litigation has now been ongoing for more than a decade. + +We want to avoid situations like this in the future by making the terms of +contibution explicit upfront. + +Generally, we believe the terms of the CLA are fair and reasonable for +contributors, and that the primary way contributors benefit from contributing +to Phabricator is that we publish and maintain their changes so they do not +have to fork the software. + +If you have strong ideological reasons for contributing to open source, you may +not be comfortable with the terms of the CLA (for example, it may be important +to you that your changes are never available under a license which you haven't +explicitly approved). This is fine and we can understand why contributors may +hold this viewpoint, but we can not accept your changes into the upstream. + + +Corporate vs Individual CLAs +============================ + +We offer two CLAs: + + - {L28} + - {L30} + +These are both substantially similar to the equivalent Apache CLAs. + +If you own the work you are contributing, sign the individual CLA. If your +employer owns the work you are contributing, have them sign the corporate CLA. + +**If you are employed, there is a substantial possibility that your employer +owns your work.** If they do, you do not have the right to contribute it to us +or assign the rights that we require, and can not contribute under the +individual CLA. Work with your employer to contribute under the corporate CLA +instead. + +Particularly, this clause in the individual CLA is the important one: + +> 4. You represent that you are legally entitled to grant the above license. If +> your employer(s) has rights to intellectual property that you create that +> includes your Contributions, you represent that you have received permission +> to make Contributions on behalf of that employer, that your employer has +> waived such rights for your Contributions to Phacility, or that your employer +> has executed a separate Corporate CLA with Phacility. + +Ownership of your work varies based on where you live, how you are employed, +and your agreements with your employer. However, at least in the US, it is +likely that your employer owns your work unless you have anticipated conflicts +and specifically avoided them. This generally makes sense: if you are paid by +your employer for your work, they own the product of your work and you receive +salary and benefits in fair exchange for that work. + +Your employer may have an ownership claim on your work even if you perform it +on your own time, if you use their equipment (like a company laptop or phone), +resources, facilities, or trade secrets, or signed something like an "Invention +Assignment Agreement" when you were hired. Such agreements are common. The +details of the strength of their claim will vary based on your situation and +local law. + +If you are unsure, you should speak with your employer or a lawyer. If you +contribute code you do not own under the individual CLA, you are exposing +yourself to liability. You may also be exposing us to liablity, but we'll have +the CLA on our side to show that we were unwilling pawns in your malicious +scheme to defraud your employer. + +The good news is that most employers are happy to contribute to open source +projects. Incentives are generally well aligned: they get features they want, +and it reflects well on them. In the past, potential contributors who have +approached their employers about a corporate CLA have generally had little +difficulty getting approval.