mirror of
https://we.phorge.it/source/phorge.git
synced 2024-11-10 08:52:39 +01:00
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
This commit is contained in:
parent
f3e6a57794
commit
eb62a98e0f
1 changed files with 169 additions and 0 deletions
169
src/docs/contributor/cla.diviner
Normal file
169
src/docs/contributor/cla.diviner
Normal file
|
@ -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.
|
Loading…
Reference in a new issue