
Don’t sign a CLA - chmaynard
https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html
======
Legogris
It's a great point to be aware of, but the title and the tone implies that you
as a contributor should be a FOSS maximalist.

As they say, not all open source is FOSS. And some people are OK with that.
Let them contribute, as long as they are aware of the implications.

When I discover bugs in open-source projects during my day job (which is on a
closed-source project), I will be much happier having those fixes merged
upstream than having to maintain our own private fork.

> Free and open source software licenses grant explicit freedoms to three
> groups: the maintainers, the users, and the contributors.

This is not the case of all open source licenses. And that is fine. Don't
assume all my work has to be part of your crusade. I will save that for the
parts of my life where it makes sense - I am all-for the FOSS movement but
there is no need to go full Stallman and say that everything but GPL is evil.
If I believed that, I wouldn't be working on a closed-source project in the
first place and then this piece would be fully relevant.

A much better title would be "Why I don't sign CLAs" or "The dangers of
signing CLAs".

~~~
rqs
> the title and the tone implies that you as a contributor should be a FOSS
> maximalist.

But what if somebody was changed the license from BSD to proprietary after
you've contributed to the project? Would you still be happy about it then?

I think the idea was: I have my code contributed under BSD, so you cannot re-
license my code without clearance from me.

~~~
jerf
To have contributed under BSD _means_ that you have contributed under a
license that permits relicensing. To contribute under the "BSD license but
secretly I'm not going to let you relicense" means that you have not in fact
contributed under the BSD license in the first place, but your secret license.

If you want to contribute under your secret license, what it means is that you
don't want to spend any time in the first place contributed to the BSD-
licensed project. Make your changes and use them, but don't contribute them
back. The BSD license permits this fully, including your ability to distribute
and sell the resulting software, subject to the advertising clause as
appropriate. So it's not like there's anything onerous about this idea.

~~~
dec0dedab0de
_" BSD license but secretly I'm not going to let you relicense" means that you
have not in fact contributed under the BSD license in the first place, but
your secret license._

I understand what you're saying, but even if you do release BSD software along
with code under a different license, you are still bound by the (very minimal)
requirements of the BSD license.

------
mcherm
I think it depends entirely on the purpose of the CLA. Different licenses say
different things. Some merely assert that the signer is contributing under the
license under which the project is distributed. (Although you may consider it
obvious, I am not aware of any existing case law in the US that asserts that
submitting a patch necessarily comes with a grant of license to the copyright.
And I can guarantee that there isn't case law in every jurisdiction around the
world.) Other CLA purposes that seem reasonable to me include a guarantee that
IF the contributor has a patent on the submitted code then a license to use
that patent is granted to all users of the software.

Even if the CLA does contain text granting some organization which manages the
code the right to re-distribute under some other license, I may well be
comfortable with that. Sometimes projects choose to move to a new license (GPL
v3 wouldn't exist without this). Sometimes a company chooses to offer
commercial licenses in addition to free ones. My willingness to contribute
under these conditions comes down to the degree to which I trust the
organization (realizing that the organization may change, but that almost no
human endeavor can be achieved without some level of trust).

On the other hand, if YOU wish to refuse to sign CLAs, you are certainly
welcome to do that. But do not be surprised if some organizations reject your
offers to contribute patches.

~~~
zamalek
Some even protect the contributors:

> [1]: You may provide support for free, for a fee, or not at all. Unless
> required by applicable law or agreed to in writing, You provide Your
> Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> KIND, either express or implied, including, without limitation, any
> warranties or conditions of TITLE, NON- INFRINGEMENT, MERCHANTABILITY, or
> FITNESS FOR A PARTICULAR PURPOSE.

[1] Khan Academy CLA:
[https://docs.google.com/forms/d/e/1FAIpQLSdyXYrc8ogVoA46J9KX...](https://docs.google.com/forms/d/e/1FAIpQLSdyXYrc8ogVoA46J9KXyIj5nKlZzNkOnQG-4A1R7X_BWGTShQ/viewform)

------
kemitchell
A blog post of mine arguing for CLAs:

[https://writing.kemitchell.com/2018/01/06/CLAs-Are-Not-a-
Sha...](https://writing.kemitchell.com/2018/01/06/CLAs-Are-Not-a-Sham.html)

My post responds to a different blog post. Some of the arguments here are
different.

Here, I can't help pointing out two minor vocabulary issues.

A "Contributor License Agreement" does _not_ usually transfer ownership of
copyright. We call documents that do "copyright assignments", and they require
special formalities. There are some strange hybrids, like CLAs that assign
joint ownership of copyright, but they're the exception. Most CLAs that I see
are merely additional license grants from contributor to project steward or
BDFL.

"Relicense" gets misused and misunderstood all the time. It's very rare to see
anyone try to change license terms for code already released under an open
source license, and distributed to others. There are legal questions about
whether this is possible or practical. And as I recall, Redis Labs didn't try
to do that, but only changed the terms that will apply to _new_ work on select
Redis add-ons, going forward. In other words, they changed the terms they'll
use for _future_ work.

We sometimes say "relicensing" when we mean "dual licensing" or "offering the
same code on different terms", rather than changing the one-and-only set of
terms that apply to software. The former describes what companies do when they
steward a project under a common open source license, often GPL or AGPL, but
also sign business deals that include traditional, proprietary-style license
terms. Often, such licenses omit requirements to preserve copyright notices
from developers, and also copyleft requirements. At the same time, business-
to-business licenses are often more restrictive in other ways, like limiting
to internal business use, prohibiting reselling, seat-limiting, and so on.

CLAs often give corporate stewards the more permissive licenses they need to
sign those kinds of terms with customers. In that sense, CLAs make possible
the business model that supports the company stewarding the project.

------
orthecreedence
Hi, I run an open source project and it has a CLA. I chose a fairly permissive
one (contributors retain ownership/copyright), however it does allow
relicensing. One of the main reasons I chose to do this is:

1\. I have a put a lot of time into the project. More than anybody. Years of
work. At some point, I'd like to be able to make money off of it, and
relicensing will give me that option (enterprise installations and all that).

2\. iOS. The GPL, from a lot of what I've read, is incompatible with the Apple
store. If you want to release a GPL-licensed app on iOS, you need to be able
to relicense it. Please prove me wrong here, but I think this is a big deal.

Here's my take. If I ever want to make the project completely closed, the last
GPLed version is still available and able to be forked or continued. I can't
erase the project from the face of the earth, which is kind of what the author
seems to be suggesting.

Secondly, if I was starting a project that blossomed with the help of hundreds
of contributors, I'd be much more likely to not want a CLA. That said, this is
_my_ project. Sure, anyone can fork it and do what they want with it, but I am
the one creating it. And at some point, I want that to pay off. My choice of
GPL is not to protect contributors, it's to protect the users. The CLA lets me
have a restrictive license while giving me the freedom to relicense as needed.

If that keeps you from contributing, no hard feelings. But having a CLA lets
me navigate a lot of issues that would otherwise keep me up at night (or make
me not want to maintain the project at all).

~~~
kemitchell
re iOS store, have a look at: [https://github.com/signalapp/libsignal-
protocol-c#license](https://github.com/signalapp/libsignal-protocol-c#license)

If you need legal advice for your specific project and situation, speak to a
lawyer.

------
monocasa
Pieter Hintjens makes a similar argument in Social Architecture, describing
ZeroMQ's community guidelines:

> All patches are owned by their authors. There SHALL NOT be any copyright
> assignment process.

> Here we come to the key reason people trust their investments in ZeroMQ:
> it's logistically impossible to buy the copyrights to create a closed source
> competitor to ZeroMQ. iMatix can't do this either. And the more people that
> send patches, the harder it becomes. ZeroMQ isn't just free and open today--
> this specific rule means it will remain so forever. Note that it's not the
> case in all MPLv2/GPL projects, many of which still ask for copyright
> transfer back to the maintainers.

~~~
Legogris
Correct me if I'm wrong, but my understanding is that copyright transfer is
not even legally applicable in many jurisdictions.

~~~
monocasa
As far as I understand, not as such, but you can transfer all rights to
another. That's how copyright from employee to employer works in Germany
AFAIK. So practically it ends up being the same in nearly all cases.

~~~
guitarbill
Pretty much. Pedantically speaking, you can't transfer all rights.
Urheberrecht always stays with the author. But Urheberrecht isn't copyright.
(Over)simplified, it codifies who owns the copyright of a work initially, and
that owner can transfer the copyright.

------
jpablo
Wait, Free Software Foundation requires a CLA itself!

[https://www.gnu.org/licenses/why-
assign.en.html](https://www.gnu.org/licenses/why-assign.en.html)

~~~
sevensor
They do, and I believe it's because it gives them a better platform from which
to pursue GPL violation claims. I think that's basically sensible and an
exception to OP's general statement -- if you're contributing to an FSF
project, you need to understand that what you're doing is political as well as
technical. You're giving FSF more ammunition with which to enforce copyleft.
FSF is an exception to the concern that the asignee of your copyright is going
to do a proprietary relicensing.

~~~
scrollaway
In other words, "do as I say, not as I do".

~~~
sevensor
That's an odd conclusion to draw from my post. Are you under the impression
that OP represents the FSF? He does not. Neither do I. My point is that the
general rule that one should be wary of CLAs because they can be used to take
away your software freedoms probably doesn't apply to the FSF. A different
consideration applies to the FSF -- if you don't like their political goals,
don't support them by contributing to their projects.

------
rlpb
"What the CLA is actually used for is to give the project maintainers the
ability to relicense your work under a more restrictive software license, up
to and including making it entirely closed source."

This goes both ways. It also gives the project maintainers the ability to
relicense your work under a less restrictive licence, up to and including
making it even more open (eg. from GPL to MIT).

Note that what you contribute will be open source forever regardless of a CLA:
as soon as it is released (the open source version your patch is based on, and
your open source contribution), the open source -ness cannot be revoked by
anyone. A "community fork" from the most recent open source release is always
possible, as has been seen multiple times with multiple projects, including
those with CLAs.

What the author is really saying is that by signing a CLA you're revoking your
claim to what the project maintainers do with the project _in the future_,
after they have worked on it some more.

There is, after all, a huge asymmetry here. In a project managed by a major
sponsor requiring a CLA, your contribution is probably tiny compared to the
work done by project sponsors. In this case, it doesn't seem unreasonable to
me for the sponsors to be wanting not to encumber their project with the
removal of their ability to take _future work_ on their project closed source
(because they were originally the sole copyright holders), just for the sake
of a tiny contribution.

Do those tiny contributions add up? I can only think of a few projects when
they do, and that's where the ecosystem consists of multiple corporate
sponsors (Linux and Postgres come to mind). In most cases where there is a
CLA, there is a single corporate sponsor who employs full time developers, and
no other developers are contributing full time so the majority of ongoing work
is done by the single sponsor. If you want to argue that the CLA is enforcing
this condition, then go ahead and fork the project to prove me wrong!

If you're contributing a major component, then sure, you might want to think
about it, though even then you're going to get somebody else to maintain that
component for you indefinitely if you contribute it.

If you're contributing a minor bugfix, then you're probably hurting yourself
(by making yourself maintain that fix forever, or forcing yourself to maintain
an entire fork) more than achieving out of principle.

------
hyperpape
An interesting contrast among FOSS maximalists is that the FSF requires a CLA
for a subset of its projects: [https://www.gnu.org/licenses/why-
assign.html](https://www.gnu.org/licenses/why-assign.html)

~~~
Sir_Cmpwn
I think the FSF gets a pass here, given that the GPL has explicit protections
against the negative behaviors warned about in the article.

~~~
akerl_
Wouldn't your article then more accurately be "Don't sign a CLA without
reading it and making sure you agree with what it says", which reduces pretty
cleanly to "Don't sign things unless you've read them and agree with them"?

Your overall point seems to be one I agree with, which is "CLAs can be (and
often are) used to enable maintainers to make decisions that contributors
wouldn't want to be made, and contributors should thus be careful in what they
agree to", but in making it an imperative headline it's lost the nuance.

~~~
Sir_Cmpwn
Well, I could make a CLA which asks you to remember to drink your Ovaltine,
which would be pretty harmless. But the average CLA is far from harmless, so
it deserves special mention to call out these CLAs as harmful.

Some CLAs are worse than others, though, and as people send me examples of
supposedly benine CLAs I've been writing up addendums to add to the bottom of
the article. There is indeed some nuance here, which I hope to address in that
manner.

------
jedbrown
> What about the Apache Foundation CLA? This CLA is one of the better ones,
> because it doesn’t transfer copyright over your work to the Apache
> Foundation. I have no beef with clauses 1 and 3-8. However, term 2 is too
> broad and I would not sign this CLA.

Term 2 of the CLA just defines inbound=outbound for Term 2 of the License
([https://www.apache.org/licenses/LICENSE-2.0](https://www.apache.org/licenses/LICENSE-2.0)).

The Apache CLA is pretty benign (for projects that are distributed under the
Apache license; sometimes it is used for projects distributed under different
licenses and then it gets murky), but the overhead to contributors and
maintainers is significant and it is less precise than a Developer's
Certificate of Origin. The "Inbound=Outbound Is All You Need" section of this
post is on-point. [http://ebb.org/bkuhn/blog/2011/07/07/harmony-
harmful.html](http://ebb.org/bkuhn/blog/2011/07/07/harmony-harmful.html)

------
codetrotter
> Open source is a commitment to your community. Once you make it, you cannot
> take it back. You don’t get the benefits associated with being an open
> source project if you have an exit hatch. You may argue that it’s your right
> to do what you want with your project, but making it open source is
> explicitly waiving that right.

I open source things I write, and I love open source but I think this stance
is disingenuous.

Yes you _should_ maintain your project in the future so that you don’t leave
your users hanging to dry, but sometimes life happens and you can’t continue
your open source project in its current form.

With a CLA, the creators of a project that would otherwise be unable to
continue the project due to lack of funds can develop a proprietary version
that they can earn money from licensing to people. And hopefully they will
continue to maintain an open source version that receives bug fixes and some
features while certain other features are only developed for the proprietary
version.

Demanding that those who make open source software do so under strict
conditions will only serve to deter people from making open source software in
the first place, IMO.

Certainly it can be frustrating to be a user of a software and have them close
the source, but what would the alternative be? Probably that it just died, so
for you the outcome would be the same.

Open source is great. It saves time and money by letting people and companies
make use of the work done by others to save themselves from having to
duplicate the effort. But it is never going to be the case that we can
_demand_ that someone else continues maintaining a product for us for free.

When a product goes closed source, from your point of view it should not be
much different from had it shut down completely. The last open source version
of the product is still available so if someone was goinging to step up and
maintain it into the future they still can, and if they weren’t going to, well
then it makes no big difference what the original authors decide to do anyway.

Personally the main reason I don’t use CLAs for my projects is that I am using
a very permissive license for most of my projects already, the ISC license,
and I don’t foresee any situation where I would want to switch to another
license for my projects.

------
Timshel
If you see it from the other side, I completely understand why anyone with a
project might not want a random contributor to become an equal.

It opens the door for fun things like :
[https://lwn.net/Articles/694890/](https://lwn.net/Articles/694890/)

------
lacker
Not all CLAs are designed to let the project relicense itself. In particular,
some CLAs are there to make the contributors promise that they are not
submitting patent-encumbered code which they intend to later assert some
rights on. Those CLAs seem like they are fixing up a fundamental unclearness
in how patents are licensed in open source software.

------
kodablah
> used their CLA to pull along any external contributions for the ride. As
> thanks for the generous time

Am I the only one that doesn't over-value their own contributions? So many
copy-left proponents always bemoan giving your work away. While that may hold
some water on some large efforts, in general, who cares if you give away bits
of your work? Who cares if you sign it away? Don't get hung up on your
personal pride like your contribution is the greatest thing ever, feel free to
share and share alike even on projects with caveats to your sharing, even if
that means you are guilted by the forced-freedom side of the community. Or
don't...but no need to pretend like others are bad for doing so.

------
jpfr
I do not agree with the sentiment that all CLA are evil.

Yes, CLA that transfer all ownership to the project are bad. But many __CLA
are in place to protect the project from bad actors __. For example companies
suing the project because an employee has submitted code that he wasn 't
allowed to make public.

I use a CLA in an open source project. But it does not transfer ownership. It
just states that the contributor is allowed to make the contributions and
accepts the license.

[https://gist.github.com/Pro/7d90e84b0765e7aa9068667e3418ef52](https://gist.github.com/Pro/7d90e84b0765e7aa9068667e3418ef52)

------
btilly
As a counterpoint, read [https://www.gnu.org/licenses/why-
assign.en.html](https://www.gnu.org/licenses/why-assign.en.html) where the GNU
project explains why they require copyright assignments.

And their stated issues are not trivial. I have personally run into a few
cases where people thought that they owned their work, but actually it was
owned by their employer. I don't have to look very far - it happened to me
personally when I lived in New York. (Not entirely coincidentally, I now live
in California where it is much easier to retain ownership of any side project
that I might happen to do.)

Yes, it is handing them extra power that is abusable. However it is also power
that they may have legitimate reasons to want. As with all legal agreements,
the real question is what you are afraid of.

~~~
JdeBP
Or read
[https://news.ycombinator.com/item?id=18149011](https://news.ycombinator.com/item?id=18149011)
here where it is argued out that a copyright assignment is not the same thing
as a contributor licence agreement.

~~~
btilly
No, a copyright assignment is not the same thing as a contributor license
agreement. Copyright assignment is in all respects that this article cares
about even worse.

Therefore the fact that one of the most extreme software freedom organizations
out there argues for copyright assignments is very telling.

------
kradroy
My father told me long ago: "After you've done the work the only thing you
should sign is a check you're about to deposit."

~~~
JdeBP
Your father's advice does not scale. Not all legal systems work the same way,
and in some having the _payee_ sign one is an indorsement by the payee that
makes it payable to third parties (which will be whoever the bearer happens to
be for a simple signature, an _indorsement in blank_ ). Whereas having the
payee _not_ sign checks, and having checks crossed as "A/C payee", are
considered the better practices.

Or, to echo Drew DeVault somewhat: _Don 't sign cheques_ made out to you as
the payee.

* [http://www.legislation.gov.uk/ukpga/1992/32/section/1](http://www.legislation.gov.uk/ukpga/1992/32/section/1)

* [http://www.legislation.gov.uk/ukpga/Vict/45-46/61/section/34](http://www.legislation.gov.uk/ukpga/Vict/45-46/61/section/34)

* [http://www.legislation.gov.uk/ukpga/Vict/45-46/61/part/II/cr...](http://www.legislation.gov.uk/ukpga/Vict/45-46/61/part/II/crossheading/negotiation-of-bills)

------
gant
This goes both ways. Don't remember specifics, but contributors trying to
"revoke" their license to destroy a FOSS project is about as common as a
company trying to use your contributions in a only non-free version.

------
RobertSmith
CLA intimidates people to contribute. It discourages contributions

~~~
radarsat1
Why would people contribute to a project they don't agree to the license of?
Isn't it good to discourage contributions from people who don't agree in the
first place, avoiding future conflict?

~~~
toast0
As someone who works at a fairly enlightened big company, it's not too hard to
get approval to contribute to an open source project (lawyers confirm the
license is ok, and that the project doesn't touch any things that are
currently sensitive to touch publicly) and it usually only takes a couple
business days, getting approval to agree to a CLA is a fairly big additional
delay, especially when they want it signed by the company rather than the
individual.

------
tristor
I'm not entirely sure I understand why so many people are against CLAs. I've
been active in the open source community since 1996, and am currently employed
at a company which is 100% based upon service around open source software,
which includes our stewardship of several projects which have significantly
advanced the community cause. My employer requires a CLA. It is not written in
esoteric legalese, but is rather simple to understand before you sign it. It
is designed to protect both you, as the contributor, and my employer.

A CLA is a good thing when it's written well, is not overly onerous, and is
being used to further contributions. Here is some basic reasons why a company
like my employer may want contributors to sign a CLA:

1\. It prevents your heirs from terminating your copyright grants in the
future if you pass away or any number of other weird quirks of US copyright
law that could potentially result in legal fuckery that you do not intend. 2\.
It prevents enforcement of patents surrounding code you have contributed
against my employer. 3\. It indemnifies you as the contributor against
expectations of support, guarantee, or warranty for your contribution. 4\. It
commits my employer to maintenance of your contribution once its accepted as
long as it is needed in the code-base. 5\. It protects my employer from
getting in trouble for contributions where the contributor did not have legal
license to offer the contribution, because you are asserting that you have
such license before offering that contribution.

Yes, it allows for re-licensing, but in practice what this means is that some
or all of the code may be dual-licensed at some point in the future to assist
in integration with other open source software projects.

To assert you should never sign a CLA seems short-sighted and unreasonable. I
can't speak for every project, but my employer has been a good steward of
software in the community and the community itself since the day it was
founded and has committed to continuing to do so.

While I can certainly understand that you may not wish to sign a CLA with an
organization you do not trust, I don't think refusal to sign should be a
default position. Instead, like any contract, you should read before you sign
and not enter into agreements with entities you do not trust. Simple as that.

------
vorpalhex
I won't contribute to any open source project with a CLA - which has been a
shame for a few open source projects. I caught a serious security
vulnerability in one project including them openly posting admin secrets - and
privately contacted and let them know, appropriately - only to get back a
response of "Can you sign our CLA and help us fix this?".

I politely told them I don't do CLAs. I checked a few weeks later and the
passwords were still posted.

------
jcadam
I'm sitting on a few custom forks of open source tools (in which I've either
fixed a bug or added a feature I needed) which I've more or less kept to
myself because the process to contribute back to those projects is just enough
of a PITA (due to CLAs and the like) that I can't overcome my apathy/laziness
enough to spend the time/effort required to submit my changes and get them
accepted.

Ah well.

~~~
nraynaud
I feel you, red tape to report a bug, red tape to send a patch, and then the
owner sends you to hell because they don’t owe you anything.

------
evrydayhustling
What about the maintainer's right to not have their hands tied as they evolve
a project by one person issuing a custom license on their PR? I agree with
your final suggestion of forking off (hah) if you have a problem with the
CLA... But it's unwarranted to say a maintainer protecting himself from a huge
additional coordination burden is a kick in anyone else's groin.

------
trulyrandom
I've always been under the impression that CLA's are meant to ensure that
contributors can not retract their contributions once they've made them. I'd
be fine with signing such an agreement. Relicensing other people's work, on
the other hand, does seem like a dramatic overreach indeed.

------
evmar
Even if you don't sign a CLA, can't someone take an Apache/BSD/MIT-licensed
work and make a closed source form of it? The license effectively just
requires them to mention where the code came from. Whether you signed a CLA or
not seems pretty irrelevant.

Apache says for example: "You may add Your own copyright statement to Your
modifications and may provide additional or different license terms and
conditions for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole [...]".

I think the OP's concern only applies to GPL software, which in my experience
is pretty rare at this point.

------
sytse
I agree with the author that a CLA is one sided since contributors are at the
mercy of the organization they sign their rights over to. For the open source
code a Developer Certificate of Origin (DCO) is more appropriate. I learned
this when Debian brought it up [https://about.gitlab.com/2017/11/01/gitlab-
switches-to-dco-l...](https://about.gitlab.com/2017/11/01/gitlab-switches-to-
dco-license/)

For our proprietary source available code we do use a CLA since it is a custom
license and we want the option to make changes to it in the future.

------
DannyBee
"What the CLA is actually used for is to give the project maintainers the
ability to relicense your work under a more restrictive software license, up
to and including making it entirely closed source."

Actually, it serves two main purposes[1] :

1\. Protect the project from people who don't actually have the necessary
rights to be contributing or wish to retract contributions later.

This is the most common case, and it happens all the time (though essentially
all of it is resolved privately due to CLA's).

The law is full of interesting dragons. As a random example: Most open source
is also too young, but in ~10-15 years, you will start to see copyright right
terminations in the US
([https://www.law.cornell.edu/uscode/text/17/203](https://www.law.cornell.edu/uscode/text/17/203))
for projects that have no CLA's.

It's inevitable. (as is having to deal with the rights of people who are dead,
which already happens)

Projects often need to do _something_ to protect themselves over time
(regardless of whether it's a CLA or copyright assignment or ...)

2\. Protect the projects from patents in #1 when the license does not do so.

(this is also resolved privately)

It also resolves an issue that only has popped up recently, copyright trolling
by folks like Patrick McHardy.

Relicensing is a _very_ secondary concern, and mostly comes into play over
time because the project screws up or grows larger than it expected.

The boogeyman of "corporation takes away my rights" is a nice boogeyman, but
the infinitely more common case is "project screws up because they didn't
think about licensing when they started". The number of "corporate
relicensings" is vastly dwarfed by non-corporate ones.

One of the more interesting things to me is that the largest mass relicensing
i'm aware of was the FSF force-relicensing projects to GPLv3 (sometimes quite
against majority-contributor wishes), with no comment or discussion or
allowance for dissent. So it wasn't a corporation doing it for whatever, it
was a foundation doing it for ideological reasons.

The fact the article tries to make it seem like it's happening all the time is
disingenuous at best, and honestly only serves to make the argument weaker
(because it's unsupported by data).

I'd also point out a CLA or equivalent is also necessary to move a project
from gpl-v2 only to gpl-v3 (IE not "restrictive software licenses") if the
project later chose. Otherwise it is stuck in limbo forever.

The answer you usually get from anti-CLA folks is "they shouldn't do that in
the first place" which is nice but doesn't actually fit with the fact that
most people basically don't pay any attention to license choices in a
meaningful way when they start projects. Or make mistakes. You know, one of
the reasons we have version control in the first place - so we can change
things we got wrong over time.

Even if you could cause them to not make mistakes, or never change viewpoints,
you'd still have millions of legacy projects to deal with.

All this article tells me is that the person hasn't run a large enough open
source project to have to deal with these in a meaningful way. That's okay.
But i've never found someone who did who has not run into the issues above and
eventually moved to CLA's or an equivalent.

I've also spent a lot of time in my life fixing smaller projects that never
had one, and then became larger, and then had to clean up the mess. It usually
costs foundations/etc a lot of money and time to track down contributors or
pull code.

I'd actually love to live in a world where CLA's aren't necessary (and
copyright was sane). But pretending we do won't get us there.

[1] bradley kuhn wrote a much better article than this one (no offense to the
author here!), though i disagree with bradley's view :P -
[https://sfconservancy.org/blog/2014/jun/09/do-not-need-
cla/](https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/)

~~~
juliusmusseau
Wow, regarding #1 - am I understanding this correctly? Linus's widow or
children can revoke his GPL license of his kernel contributions after he dies
unless he covers this scenario explicitly in his will?

Edited to add: Seems there's a 5-year window from year 35-40 after the initial
license or grant where the license or grant can be terminated, either by the
original author or their heirs, but honestly I have no idea if I'm reading
this correctly. This whole statutory terminations thing goes way over my head.
I cannot parse this document: [https://akbllp.com/introduction-and-copyright-
overview/statu...](https://akbllp.com/introduction-and-copyright-
overview/statutory-termination-of-transfers-recapturing-copyrights/statutory-
termination-of-transfers-recapturing-copyrights-post-1977/)

------
2ion
In my spare time / hobby projects, I'm ready to don my FOSS advocate hat, but
as a businessman and employee, I'm practically ignoring all issues with the
lack of F in OSS. Many thanks to those who can afford to live by their ideals
even when it comes to earning a living, though, and much respect for being
willing to deal with this kind of stuff all the time.

------
pron
It's not so much signing away your rights as getting something in exchange for
something. As you say, you can always fork the project, but very often large
projects (that tend to be the ones with CLAs) are also used by companies that
rely on them. What you get in exchange for the CLA is your code (written to
scratch your itch) becoming part of the mainline, and saving you the trouble
of merging with every update. If scratching your own itch is the goal, and if
your contribution is small relative to the total project (and it often is for
projects with CLAs), then granting the project leaders a joint ownership over
copyright is a very small price to pay in exchange for having the leaders take
your contribution into the mainline. If, on the other hand, your goal is to
shape the project, this usually entails a large number of significant
contributions, and if you do that, becoming a part of the leadership or
getting a part of the project ownership can be negotiated.

------
quest88
I don't mind contributing to paid software.

I would rather be able to fix a bug or provide a feature to software my
company paid for rather than hoping they'll fix/implement it sometime soon, or
building some hack around it, if it makes my life easier.

------
hodgesrm
This seems to be an argument against non-viral licenses than CLAs:

> We’ve seen this happen before. Consider the Redis Labs debacle, where they
> adopted the nonfree1 Anti-Commons Clause2, and used their CLA to pull along
> any external contributions for the ride. As thanks for the generous time
> invested by their community into their software, they yank it out from
> underneath it and repurpose it to make money with an obscenely nonfree
> product.

People can already repurpose software with permissive licenses such as MIT,
BSD, or Apache 2.0. That's actually the point of those licenses, isn't it?

------
carapace
An obscure but interesting point, by DJB:

> In the United States, once you own a copy of a program, you can back it up,
> compile it, run it, and even modify it as necessary, without permission from
> the copyright holder.

...

> Once you've legally downloaded a program, you can compile it. You can run
> it. You can modify it. You can distribute your patches for other people to
> use. ... As long as you're not distributing the software, you have nothing
> to worry about.

[https://cr.yp.to/softwarelaw.html](https://cr.yp.to/softwarelaw.html)

------
kemitchell
I recently blogged about an alternative to contributor license agreements
without any single foundation or BDFL, that cover relicensing of past code to
respond to license issues:

[https://writing.kemitchell.com/2018/09/30/Contributor-
Counci...](https://writing.kemitchell.com/2018/09/30/Contributor-
Councils.html)

I think the fundamental legal mechanism of cross-licensing is correct, but the
quorum-vote-like solicitation mechanism needs more thought and feedback.

------
vsl
The point is somewhat ruined by getting major facts about licensing and Redis
wrong:

1\. It was about proprietary addons, not community version at all. 2\. The
license of Redis would allow such relicensing of externally contributed code
without CLA. Read the damn BSD license, that permissiveness is its whole
point.

20 years ago, OSS developers understood their licenses. These days, it seems
common that people slam a random license on their code or contribute somewhere
with absolutely no functional understanding of the legal aspects.

------
nikisweeting
I hate both CLAs and DCOs. CMV: it's an unnecessary barrier to contributing
for new users that provides no additional guarantees over GPG signing.

------
tlrobinson
The reality is some companies simply wouldn't contribute open source projects
if they didn't have the flexibility afforded by requiring contributors sign a
CLA. Maybe you would consider that preferable, but I don't. They have a right
to require a CLA, just as I have a right to not contribute if I don't want to
sign a CLA.

------
simplecomplex
Has any CLA ever been used in court and held up? What are real world examples
of CLA’s being enforced in court?

------
madisp
But can't you take any MIT or Apache (or similarly permissively licensed)
project closed source anyway?

~~~
floatboth
You can make the next version proprietary or whatever, but you obviously can't
retroactively revoke the license from released code :)

------
natch
“I never signed anything though... I just clicked submit on an agreement and
there might have been a checkbox checked, or not.”

The article should make it more clear that the same warning also should apply
to digital signatures and agreements in their various forms.

------
_jal
Good general advice. I can't say I have a categoric aversion, but the onus is
on upstream to honestly and clearly explain the specific circumstances and
reasoning for why the license by itself is insufficient for their special
needs.

------
lucb1e
TL;DR: Some (all?) CLAs allow the maintainers to change the license of the
code that you contributed, even if that is a proprietary license. The article
mentions exactly one example of where a maintainer did that and does not point
out what clauses to look for, how many CLAs actually do this, etc.

------
IAmLiterallyAB
Have we forgotten the Linux Code of Conduct controversy? Contributors
threatened to remove their code from the kernel. A CLA would completely
prevent that.

~~~
JoshTriplett
> Contributors threatened to remove their code from the kernel.

No. Random fringe anonymous emails from non-contributors claimed (incorrectly)
that developers could do so.

See
[https://sfconservancy.org/news/2018/sep/26/GPLv2-irrevocabil...](https://sfconservancy.org/news/2018/sep/26/GPLv2-irrevocability/)
and [https://copyleft.org/guide/comprehensive-gpl-
guidech8.html#x...](https://copyleft.org/guide/comprehensive-gpl-
guidech8.html#x11-540007.4) for details (incorporating actual legal analysis).

------
linkmotif
> A CLA is a kick in the groin to a contributor’s good-faith contribution to
> the project.

I wouldn’t invest in a company that conducts business “on good faith.” That’s
well and good in the domain of interpersonal interaction, but is irresponsible
behavior from a company, which must do all it can to safeguard its assets and
revenues.

And I don’t think I’m being soulless here. A company like Facebook is
entrusted with and responsible for many people’s very livelihoods. As a
corporation it must not behave casually. There’s no “in good faith” when you
have millions of employees and investors.

~~~
vorpalhex
"Good faith" and by extension "bad faith" are quasi-legal terms. To do
business in good faith is to act by the letter and spirit of terms without an
intention of attempting to defraud.

As I understand it, someone who acts in Good faith usually has more leniency
then someone who acts in bad faith. For instance, I had a friend who upon
leaving an apartment building was charged several hundred dollars for
maintenance having to replace lightbulbs - she disputed the debt, but the
apartment complex attempted to charge her interest on it during the dispute.
Because the apartment complex acted in bad faith, not only was the debt
canceled, but the apartment complex had to pay out additional damages to her.

A business should act on good faith. That doesn't mean not having legal
agreements or being naive, it means following the letter and spirit of laws.
You might be able to technically trick someone into letting you steal their
open source contributions and sell them, but that would be bad faith.

Wikipedia explains it this way: "In contract law, the implied covenant of good
faith and fair dealing is a general presumption that the parties to a contract
will deal with each other honestly, fairly, and in good faith, so as to not
destroy the right of the other party or parties to receive the benefits of the
contract. It is implied in every contract in order to reinforce the express
covenants or promises of the contract. A lawsuit (or a cause of action) based
upon the breach of the covenant may arise when one party to the contract
attempts to claim the benefit of a technical excuse for breaching the
contract, or when he or she uses specific contractual terms in isolation in
order to refuse to perform his or her contractual obligations, despite the
general circumstances and understandings between the parties. When a court or
triar or fact interprets a contract, there is always an "implied covenant of
good faith and fair dealing" in every written agreement.[1]" \-
[https://en.wikipedia.org/wiki/Good_faith_(law)](https://en.wikipedia.org/wiki/Good_faith_\(law\))

~~~
linkmotif
I see. Thank you.

So the question is, are they acting in bad faith if they attempt to use a CLA
to subvert the open source license?

~~~
guitarbill
I think the point is to assume good faith on the contributer's side, i.e. that
they will follow in the letter and spirit of the OS license, so a CLA is
unnecessary. Conversely, by putting a CLA in place, the subtext is "I think
you're probably a scumbag (=person acting in bad faith) and don't trust the OS
licenses used for billions of lines of code, so I'm going to hit you with a
CLA preemptively".

As an interesting bit of context, the European legal system skews more towards
the spirit of the law, allowing for shorter legal documents/contracts. Whereas
the US legal system skews towards the letter of the law, meaning contracts end
up being several hundred pages, littered by garbage like "including but not
limited to", and things like that.

~~~
linkmotif
Thank you for the additional context.

