@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.)
hq.recaptime.dev/wiki/Phorge
phorge
phabricator
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
+169
+169
src/docs/contributor/cla.diviner
+169
src/docs/contributor/cla.diviner
···
1
+
@title Understanding the Phacility CLA
2
+
@group detail
3
+
4
+
Describes the Contributor License Agreement (CLA).
5
+
6
+
Overview
7
+
========
8
+
9
+
IMPORTANT: This document is not legal advice.
10
+
11
+
Phacility requires contributors to sign a Contributor License Agreement
12
+
(often abbreviated "CLA") before we can accept contributions into the upstream.
13
+
This document explains what this document means and why we require it.
14
+
15
+
This requirement is not unusual, and many large open source projects require a
16
+
similar CLA, including Python, Go, jQuery, and Apache Software Foundation
17
+
projects.
18
+
19
+
You can read more about CLAs and find more examples of companies and projects
20
+
which require them on Wikipedia's
21
+
[[ https://en.wikipedia.org/wiki/Contributor_License_Agreement | CLA ]] page.
22
+
23
+
Our CLA is substantially similar to the CLA required by Apache, the
24
+
"Apache Individual Contributor License Agreement V2.0". Many projects which
25
+
require a CLA use this CLA or a similar one.
26
+
27
+
28
+
Why We Require a CLA
29
+
====================
30
+
31
+
While many projects require a CLA, others do not. This project requires a CLA
32
+
primarily because:
33
+
34
+
- it gives us certain rights, particularly the ability to relicense the work
35
+
later;
36
+
- it makes the terms of your contribution clear, protecting us from liability
37
+
related to copyright and patent disputes.
38
+
39
+
**More Rights**: We consider the cost of maintaining changes to greatly
40
+
outweigh the cost of writing them in the first place. When we accept work
41
+
into the upstream, we are agreeing to bear that maintenance cost.
42
+
43
+
This cost is not worthwhile to us unless the changes come with no strings
44
+
attached. Among other concerns, we would be unable to redistribute Phabricator
45
+
under a different license in the future without the additional rights the CLA
46
+
gives us.
47
+
48
+
For a concrete example of the problems this causes, Bootstrap switched from
49
+
GPLv2 to MIT in 2012-2013. You can see the issue tracking the process and read
50
+
about what they had to go through to do this here:
51
+
52
+
https://github.com/twbs/bootstrap/issues/2054
53
+
54
+
This took almost 18 months and required a huge amount of effort. We are not
55
+
willing to encumber the project with that kind of potential cost in order to
56
+
accept contributions.
57
+
58
+
The rights you give us by signing the CLA allow us to release the software
59
+
under a different license later without asking you for permission, including a
60
+
license you may not agree with.
61
+
62
+
They do not allow us to //undo// the existing release under the Apache license,
63
+
but allow us to make an //additional// release under a different license, or
64
+
release under multiple licenses (if we do, users may choose which license or
65
+
licesnes they wish to use the software under). It would also allow us to
66
+
discontinue updating the release under the Apache license.
67
+
68
+
While we do not currently plan to relicense Phabricator, we do not want to
69
+
give up the ability to do so: we may want or need to in the future.
70
+
71
+
The most likely scenario which would lead to us changing the license is if a
72
+
new version of the Apache license is released. Open source software licenses
73
+
are still largely untested in the US legal system, and they may face challenges
74
+
in the future which could require adapting them to a changing legal
75
+
environment. If this occurs, we would want to be able to update to a newer
76
+
version of the license which accounted for these changes.
77
+
78
+
It is also possible that we may want to change open source licenses (for
79
+
example, to MIT) or adopt dual-licensing (for example, both Apache and MIT). We
80
+
might want to do this so that our license is compatible with the licenses used
81
+
by other software we want to be distributed alongside.
82
+
83
+
Although we currently believe it is unlikely, it is also possible we may want
84
+
to relicense Phabricator under a closed, proprietary, or literally evil license.
85
+
By signing the CLA, you are giving us the power to do this without requiring
86
+
you to consent. If you are not comfortable with this, do not sign the CLA and
87
+
do not contribute to Phabricator.
88
+
89
+
**Limitation of Liability**: The second benefit the CLA provides is that it
90
+
makes the terms of your contribition explicitly clear upfront, and it puts us
91
+
in a much stronger legal position if a contributor later claims there is
92
+
ambiguity about ownership of their work. We can point at the document they
93
+
signed as proof that they consented to our use and understood the terms of
94
+
their contribution.
95
+
96
+
//SCO v. IBM// was a lawsuit filed in 2003 alleging (roughly) that IBM had
97
+
improperly contributed code owned by SCO to Linux. The details of this and the
98
+
subsequent cases are very complex and the situation is not a direct parallel to
99
+
anything we are likely to face, but SCO claimed billions of dollars in damages
100
+
and the litigation has now been ongoing for more than a decade.
101
+
102
+
We want to avoid situations like this in the future by making the terms of
103
+
contibution explicit upfront.
104
+
105
+
Generally, we believe the terms of the CLA are fair and reasonable for
106
+
contributors, and that the primary way contributors benefit from contributing
107
+
to Phabricator is that we publish and maintain their changes so they do not
108
+
have to fork the software.
109
+
110
+
If you have strong ideological reasons for contributing to open source, you may
111
+
not be comfortable with the terms of the CLA (for example, it may be important
112
+
to you that your changes are never available under a license which you haven't
113
+
explicitly approved). This is fine and we can understand why contributors may
114
+
hold this viewpoint, but we can not accept your changes into the upstream.
115
+
116
+
117
+
Corporate vs Individual CLAs
118
+
============================
119
+
120
+
We offer two CLAs:
121
+
122
+
- {L28}
123
+
- {L30}
124
+
125
+
These are both substantially similar to the equivalent Apache CLAs.
126
+
127
+
If you own the work you are contributing, sign the individual CLA. If your
128
+
employer owns the work you are contributing, have them sign the corporate CLA.
129
+
130
+
**If you are employed, there is a substantial possibility that your employer
131
+
owns your work.** If they do, you do not have the right to contribute it to us
132
+
or assign the rights that we require, and can not contribute under the
133
+
individual CLA. Work with your employer to contribute under the corporate CLA
134
+
instead.
135
+
136
+
Particularly, this clause in the individual CLA is the important one:
137
+
138
+
> 4. You represent that you are legally entitled to grant the above license. If
139
+
> your employer(s) has rights to intellectual property that you create that
140
+
> includes your Contributions, you represent that you have received permission
141
+
> to make Contributions on behalf of that employer, that your employer has
142
+
> waived such rights for your Contributions to Phacility, or that your employer
143
+
> has executed a separate Corporate CLA with Phacility.
144
+
145
+
Ownership of your work varies based on where you live, how you are employed,
146
+
and your agreements with your employer. However, at least in the US, it is
147
+
likely that your employer owns your work unless you have anticipated conflicts
148
+
and specifically avoided them. This generally makes sense: if you are paid by
149
+
your employer for your work, they own the product of your work and you receive
150
+
salary and benefits in fair exchange for that work.
151
+
152
+
Your employer may have an ownership claim on your work even if you perform it
153
+
on your own time, if you use their equipment (like a company laptop or phone),
154
+
resources, facilities, or trade secrets, or signed something like an "Invention
155
+
Assignment Agreement" when you were hired. Such agreements are common. The
156
+
details of the strength of their claim will vary based on your situation and
157
+
local law.
158
+
159
+
If you are unsure, you should speak with your employer or a lawyer. If you
160
+
contribute code you do not own under the individual CLA, you are exposing
161
+
yourself to liability. You may also be exposing us to liablity, but we'll have
162
+
the CLA on our side to show that we were unwilling pawns in your malicious
163
+
scheme to defraud your employer.
164
+
165
+
The good news is that most employers are happy to contribute to open source
166
+
projects. Incentives are generally well aligned: they get features they want,
167
+
and it reflects well on them. In the past, potential contributors who have
168
+
approached their employers about a corporate CLA have generally had little
169
+
difficulty getting approval.