Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html
[ This is a version of an essay
that I originally
published on Conservancy’s blog ].
For nearly a decade, a battle has raged between two distinct camps
regarding something called Contributor Licensing Agreements
(CLAs).
I’ve
previously written a long treatise on the issue. This article below is
a summary on the basics of why
CLA‘s aren’t
necessary.
In the most general sense, a
CLA is a formal
legal contract between a contributor to a
FLOSS
project and the “project”
itself0.
Ostensibly, this agreement seeks to assure the project, and/or its governing
legal entity, has the appropriate permissions to incorporate contributed
patches, changes, and/or improvements to the software and then distribute the
resulting larger work.
In practice, most CLAs in use today are deleterious overkill for that
purpose. CLAs simply shift legal blame for any patent infringement,
copyright infringement, or other bad acts from the project (or its
legal entity) back onto its contributors. Meanwhile, since vetting
every contribution for copyright and/or patent infringement is time-consuming
and expensive, no existing organization actually does that work; it’s
unfeasible to do so effectively. Thus, no one knows (in the general case) if
the contributors’ assurances in the CLA are valid. Indeed, since it’s so
difficult to determine if a given work of software infringes a patent, it’s
highly likely that any contributor submitting a patent-infringing patch did
so inadvertently and without any knowledge that the patent even existed
— even regarding patents controlled by their own
company1.
The undeniable benefit to CLAs relates to contributions from for-profit
companies who likely do hold patents that read on the software. It’s
useful to receive from such companies (whenever possible) a patent license
for any patents exercised in making, using or selling the FLOSS containing
that company’s contributions. I agree that such an assurance is nice to
have, and I might consider supporting CLAs if there was no other cost
associated with using them. However, maintenance of CLA-assent records
requires massive administrative overhead.
More disastrously, CLAs require the first interaction between a FLOSS
project and a new contributor to involve a complex legal negotiation and a
formal legal agreement. CLAs twist the empowering, community-oriented,
enjoyable experience of FLOSS contribution into an annoying exercise in
pointless bureaucracy, which (if handled properly) requires a
business-like, grating haggle between necessarily adverse parties. And,
that’s the best possible outcome. Admittedly, few contributors actually
bother to negotiate about the CLA. CLAs frankly rely on our “Don’t
Read & Click ‘Agree’” culture — thereby
tricking contributors into bearing legal risk. FLOSS project leaders
shouldn’t rely on “gotcha” fine print like car salespeople.
Thus, I encourage those considering a CLA to look past the “nice
assurances we’d like to have — all things being equal” and focus
on the “what legal assurances our FLOSS project actually needs to
assure its thrives”. I’ve spent years doing that
analysis; I’ve concluded quite simply: in this regard, all a project and its
legal home actually need is a clear statement and/or assent from the
contributor that they offer the contribution under the project’s known FLOSS
license. Long ago, the now famous Open Source lawyer Richard
Fontana dubbed
this legal policy with the name “inbound=outbound”. It’s a
powerful concept that shows clearly the redundancy of CLAs.
Most importantly, “inbound=outbound” makes a strong and
correct statement about the FLOSS license the project chooses. FLOSS
licenses must contain all the legal terms that are necessary for a
project to thrive. If the project is unwilling to accept (inbound)
contribution of code under the terms of the license it chose, that’s a
clear indication that the project’s (outbound) license has serious
deficiencies that require immediate remedy. This is precisely why I urge
projects to select a copyleft license with a strong patent clause, such as
the GPLv3. With a
license like that, CLAs are unnecessary.
Meanwhile, the issue of requesting the contributors’ assent to the
projects’ license is orthogonal to the issue of CLAs. I do encourage use
of clear systems (either formal or informal) for that purpose. One popular
option is called the Developer Certificate of Origin
(DCO).
Originally designed for the Linux project and published by
the OSDL
under the CC-By-SA license, the DCO is a mechanism to assure
contributors have confirmed their right to license their contribution under
the project’s license. Typically, developers indicate their agreement to
the DCO with a specially-formed tag in their
DVCS commit log.
Conservancy‘s Evergreen,
phpMyAdmin,
and Samba
projects all use modified versions of the DCO.
Conservancy’s Selenium
project uses a license assent mechanism somewhat closer to a formal
CLA. In this method, the contributors must complete a special online form
wherein they formally assent to the license of the project. The project keeps
careful records of all assents separately from the code repository itself.
This mechanism is a bit heavy-weight, but ultimately simply formally
implements the same inbound=outbound concept.
However, most projects use the same time-honored and
successful mechanism used throughout the 35 year history of the Free
Software community. Simply, they publish clearly in their developer
documentation and/or other key places (such as mailing list subscription
notices) that submissions using the normal means to contribute to the
project — such as patches to the mailing list or pull and merge
requests — indicate the contributors’ assent for inclusion of that
software in the canonical version under the project’s license.
Ultimately, CLAs are much ado about nothing. Lawyers are trained to
zealously represent their clients, and as such they often seek to an
outcome that maximizes leverage of clients’ legal rights, but they
typically ignore the other important benefits that are outside of their
profession. The most ardent supporters of CLAs have yet to experience
first-hand the arduous daily work required to manage a queue of incoming
FLOSS contributions. Those of us who have done the latter easily see that
avoiding additional barriers to entry is paramount. While a beautifully
crafted CLA — jam-packed with legalese that artfully shifts all the
blame off to the contributors — may make some corporate attorneys
smile, but I’ve never seen such bring anything but a frown and a sigh from
FLOSS developers.
0Only rarely does an
unincorporated, unaffiliated project request CLAs. Typically, CLAs name a
corporate entity — a non-profit charity (like Conservancy), a trade
association (like OpenStack Foundation), or a for-profit company, as its
ultimate beneficiary. On rare occasions, the beneficiary of a CLA is a
single individual developer.
1I’ve yet to meet any FLOSS
developer who has read their own employer’s entire patent portfolio.
