Project Harmony (and “Next Generation Contributor Agreements”) Considered Harmful

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/07/07/harmony-harmful.html

Update on 2014-06-10:While this article is about a
specific series of attempts to “unify”
CLAs and
©AAs into a
single set of documents, the issues raised below cover the gamut of
problems that are encountered in many CLAs and ©AAs in common use
today in
FLOSS
projects. Even though it appears that both Project Harmony and its
reincarnation Next Generation Contributor Agreements have both failed, CLAs
and ©AAs are increasing in popularity among FLOSS projects, and
developers should begin action to oppose these agreements for their
projects.

Trending
What’s Up, Home? – Zabbix the Climate Remote

Update on 2013-09-05: Project Harmony was recently
relaunched under the name the Next Generation of Contributor
Agreements. AFAICT, it’s
been publicly
identified as the same initiative, and
its
funding comes from the same person. I’ve verified that everything I say below still
applies to their current drafts available from the Contributor
Agreements project. I also emailed this comments to the leaders of
that project before it started, but they wouldn’t respond to my policy
questions.

Much advertising is designed to convince us to buy or use of
something that we don’t need. When I hear someone droning on about some
new, wonderful thing, I have to worry that these folks are actually
trying to market something to me.

Very soon, you’re likely to see a marketing blitz for this thing
called Project Harmony (which just released its 1.0 version
of document templates). Even the name itself is marketing: it’s not
actually descriptive, but is so named to market a “good
feeling” about the project before even knowing what it is. (It’s
also
got serious namespace collision,
including with a project already in
the software freedom community.)

Project Harmony markets itself as fixing something that our community
doesn’t really consider broken. Project Harmony is a set of document
templates, primarily promulgated and mostly drafted by corporate
lawyers, that entice developers to give control of their software work
over to companies.

My analysis below is primarily about how these agreements are
problematic for individual developers. An analysis of the agreements in
light of companies or organizations using them between each other may
have the same or different conclusions; I just haven’t done that
analysis in detail so I don’t know what the outcome is.

[ BTW, I’m aware that I’ve failed to provide a
TL;DR version of this article.
I tried twice to write one and ultimately decided that I can’t. Simply
put, these issues are complex, and I had to draw on a decade of software
freedom licensing, policy, and organizational knowledge to fully
articulate what’s wrong with the Project Harmony agreements. I realize that sounds
like a It was hard to write — it should be hard to read
justification, but I just don’t know how to summarize these
Gordian problems in a pithy way. I nevertheless hope developers will
take the time to read this before they sign a Project Harmony agreement,
or — indeed — any CLA or ©AA. ]

Copyright Assignment That Lacks Real Assurances

First of all, about half of Project Harmony is copyright assignment
agreements (
©AAs). Assigning copyright completely gives
the work over to someone else. Once the ©AA is signed, the work
ceases to belong to the assignor. It’s as if that work was done by the
assignee. There is admittedly some value to copyright assignment,
particularly if developers want to ensure that the
GPL or other copyleft is
enforced on their work and they don’t have time to do it themselves.
(Although developers can also designate an enforcement agent to do that on their
behalf even if they don’t assign copyright, so even that necessity is
limited.)

One must immensely trust an assignee organization. Personally, I’ve
only ever assigned some of my copyrights to one organization in my
life: the Free Software Foundation,
because FSF is the
only organization I ever encountered that is institutionally committed
to
DTRT’ing with
copyrights in a manner similar to my personal moral beliefs.

First of
all, as
I’ve written about before, FSF’s ©AA make all sorts of promises
back to the assignor. Second, FSF is institutionally committed
to the GPL and
enforcing GPL in a way
that advances FSF’s non-profit advocacy mission for software freedom.
All of this activity fits my moral principles, so I’ve been willing to
sign FSF’s ©AAs.

Yet, I’ve nevertheless met many developers who refuse to sign
FSF’s ©AAs. While many of such developers like the GPL, they don’t
necessarily agree with the FSF’s moral positions. Indeed, in many
cases, developers are completely opposed to assigning copyright to
anyone, FSF or otherwise. For
example, Linus
Torvalds, founder of Linux, has often stated on record that
he never wanted to do copyright assignments, for several reasons:
[he] think[s] they are nasty and wrong personally, and [he]’d hate all
the paperwork, and [he] thinks it would actually detract from the
development model.

Obviously, my position is not as radical as Linus’; I do think
©AAs can sometimes be appropriate. But, I also believe that
developers should never assign copyright to a company or to an
organization whose moral philosophy doesn’t fit well with their own.

FSF, for its part, spells out its moral position in its ©AA
itself. As
I’ve mentioned elsewhere, and as
Groklaw
recently covered in detail, FSF’s ©AA makes various legally
binding promises to developers who sign it. Meanwhile, Project
Harmony’s ©AAs, while they put forward a few options that look
vaguely acceptable (although they have problems of their own discussed
below), make no such promises mandatory. I have often times pointed
Harmony’s drafters
to the
terms that FSF has proposed should be mandatory in any for-profit
company’s ©AA, but Harmony’s drafters have refused to
incorporate these assurances as a required part of Harmony’s
agreements. (Note that such assurances would still be required for
the CLA options as well; see below for details why.)

Regarding ©AAs, I’d like to note finally that FSF
does not require ©AAs for all
GNU packages.
This confusion is so common that I’d like to draw attention to it, even
thought it’s only a tangential point in this context. FSF’s ©AA is
only mandatory, to my knowledge, on those
GNU packages where either (a)
FSF employees developed the first versions or (b) the original
developers themselves asked to assign copyright to FSF, upon
their project joining GNU. In all other cases, FSF assignment is
optional. Some GNU projects, such
as GNOME, have their
own positions regarding ©AAs that differ radically from FSF’s.
I seriously doubt that companies who adopt Project Harmony’s agreement
will ever be as flexible on copyright assignment as FSF, nor will any of
the possible Project Harmony options be acceptable to GNOME’s existing
policy.

Giving Away Rights to Give Companies Warm Fuzzies?

Project Harmony, however, claims that the important part isn’t its
©AA, but its Contributor License Agreement
(CLA). To
briefly consider the history of Free Software CLAs, note that
the Apache CLA was
likely the first CLA used in the Free Software community. Apache
Software Foundation has always been heavily influenced by IBM and other
companies, and such companies have generally sought the “warm
fuzzies” of getting every contributor to formally assent to a
complex legal document that asserts various assurances about the code
and gives certain powers to the company.

The main point of a CLA (and a somewhat valid one) is to ensure that
the developers have verified their right to contribute the code under
the specified copyright license. Both the Apache CLA and Project
Harmony’s CLA go to great length and verbosity to require developers
to agree that they know the contribution is theirs. In fact, if a
developer signs one of these CLA’s, the developer makes a formal
contract with the entity (usually a for-profit
company) that the developer knows for sure that the contribution is
licensed under the specified license. The developer then takes on all
liability if that fact is in any way incorrect or in dispute!

Of course, shifting away all liability about the origins of the code is
a great big “warm fuzzy” for the company’s lawyers. Those
lawyers know that they can now easily sue an individual
developer for breach of contract if the developer was wrong
about the code. If the company redistributes some developer’s code and
ends up in an infringement suit where the company has to pay millions of
dollars, they can easily come back and sue the
developer0. The company would argue in
court that the developer breached the CLA. If this possible outcome
doesn’t immediately worry you as an individual developer
signing a Project Harmony CLA for your
FLOSS contribution, it should.

“Choice of Law” & Contractual Arrangement Muddies Copyright Claims

Apache’s CLA
doesn’t have a choice of law clause, which is preferable in my opinion.
Most lawyers just love a “choice of law” clause for
various reasons. The biggest reason is that it means the rules that
apply to the agreement are the ones with which the lawyers are most
familiar, and the jurisdiction for disputes will be the local
jurisdiction of the company, not of the developer. In addition, lawyers
often pick particular jurisdictions that are very favorable to their
client and not as favorable to the other signers.

Unfortunately, all of Project Harmony’s drafts include a
“choice of law” clause1. I expect that the drafters will
argue in response that the jurisdiction is a configuration variable.
However, the problem is that the company decides the binding of
that variable, which almost always won’t be the binding that an
individual developer prefers. The term will likely be
non-negotiable at that point, even though it was configurable in the
template.

Not only that, but imagine a much more likely scenario about the CLA:
the company fails to use the outbound license they promised. For
example, suppose they promised the developers it’d be
AGPL‘d forever
(although, no such option actually exists in Project Harmony, as
described below!), but then the company releases proprietarized
versions. The developers who signed the CLA are still copyright
holders, so they can enforce under copyright law, which, by itself,
would allow the developers to enforce under the laws in whatever jurisdiction suits
them (assuming the infringement is happening in that jurisdiction, of
course).

However, by signing a CLA with a “choice of law” clause,
the developers agreed to whatever jurisdiction is stated in that CLA.
The CLA has now turned what would otherwise be a mundane copyright
enforcement action operating purely under the developer’s local copyright law into a contract
dispute between the developers and the company under the chosen
jurisdiction’s laws. Obviously that agreement might include AGPL and/or GPL by reference,
but the claim of copyright infringement due to violation of GPL is now
muddied by the CLA contract that the developers signed, wherein the
developers granted some rights and permission beyond GPL to the
company.

Even worse, if the developer does bring action in a their own
jurisdiction, their own jurisdiction is forced to interpret the laws of
another place. This leads to highly variable and confusing results.

Problems for Individual Copyright Enforcement Against Third-Parties

Furthermore, even though individual developers still hold the
copyrights, the Project Harmony CLAs grant many transferable rights and
permissions to the CLA recipient (again, usually a company).
Even if the reasons for requiring that were noble, it
introduces a bundle of extra permissions that can be passed along to
other entities.

Suddenly, what was once a simple copyright enforcement action for a
developer discovering a copyleft violation becomes a question: Did
this violating entity somehow receive special permissions from the
CLA-collecting entity? Violators will quickly become aware of this
defense. While the defense may not have merit (i.e., the CLA recipient
may not even know the violator), it introduces confusion. Most legal
proceedings involving software are already confusing enough for courts
due to the complex technology involved. Adding something like this will
just cause trouble and delays, further taxing our already minimally
funded community copyleft enforcement efforts.

Inbound=Outbound Is All You Need

Meanwhile, the whole CLA question actually is but one fundamental
consideration: Do we need this? Project Harmony’s answer is clear: its
proponents claim that there is mass confusion about CLAs and no
standardization, and therefore Project Harmony must give a standard set
of agreements that embody all the options that are typically used.

Yet, Project Harmony has purposely refused to offer the simplest and
most popular option of all, which my colleague Richard Fontana (a lawyer
at Red Hat who also opposes Project
Harmony) last year
dubbed inbound=outbound. Specifically, the default agreement
in the overwhelming majority of FLOSS projects is simply this: each
contributor agrees to license each contribution using the project’s
specified copyright license (or a license compatible with the project’s
license).

No matter what way you dice Project Harmony, the other contractual
problems described above make true inbound=outbound impossible because
the CLA recipient is never actually bound formally by the project’s
license itself. Meanwhile, even under its best configuration, Project
Harmony can’t adequately approximate inbound=outbound. Specifically,
Project Harmony attempts to limit outbound licensing with its §
2.3 (called Outbound License). However, all the copyleft
versions of this template include a clause that say: We [the CLA
recipient] agree to license the Contribution … under terms of the
… licenses which We are using on the Submission Date for the
Material. Yet, there is no way for the contributor to
reliably verify what licenses are in use privately by the entity
receiving the CLA. If the entity is already engaged in, for example, a
proprietary
relicensing business model at the Submission Date, then the
contributor grants permission for such relicensing on the new
contribution, even if the rest of § 2.3 promises copyleft. This is
not a hypothetical: there have been many cases where it was unclear
whether or not a company was engaged in proprietary relicensing, and
then later it was discovered that they had been privately doing so for
years. As written, therefore, every configuration of Project Harmony’s
§ 2.3 is useless to prevent proprietarization.

Even if that bug were fixed, the closest Project Harmony gets to
inbound=outbound is restricting the CLA version to “FSF’s list of
‘recommended copyleft licenses’”. However, this
category makes no distinction between
the AGPL and GPL,
and furthermore ultimately grants FSF power over relicensing (as FSF can
change its
list of recommended copylefts at will). If the contributors are
serious about the AGPL, then Project Harmony cannot
assure their changes stay AGPL’d. Furthermore,
contributors must trust the FSF for perpetuity, even more
than already needed in the -or-later options in the existing
FSF-authored licenses. I’m all for trusting the FSF myself in most
cases. However, because I prefer plain AGPLv3-or-later for my code,
Project Harmony is completely unable to accommodate my licensing
preferences to even approximate an AGPL version of inbound=outbound
(even if I ignored the numerous problems already discussed).

Meanwhile, the normal, mundane, and already widely used
inbound=outbound practice is simple, effective, and doesn’t mix in
complicated contract disputes and control structures with the project’s
governance. In essence, for most FLOSS projects, the copyright license
of the project serves as the Constitution of the project, and doesn’t
mix in any other complications. Project Harmony seeks to give warm
fuzzies to lawyers at the expense of offloading liability, annoyance,
and extra hoop-jumping onto developers.

Linux Hackers Ingeniously Trailblazed inbound=outbound

Almost exactly 10 years ago today, I recall distinctly attending
the USENIX
2001 Linux BoF
session. At that session, Ted Ts’o
and I had a rather lively debate; I claimed that FSF’s ©AA assured
legal certainty of the GNU codebase, but that Linux had no such
assurance. (BTW, even I was confused in those days and thought
all GNU packages required FSF’s ©AA.) Ted explained, in his usual
clear and bright manner, that such heavy-handed methods shouldn’t be
needed to give legal certainty to the GPL and that the Linux community
wanted to find an alternative.

I walked away skeptically shaking my head. I remember thinking: Ted
just doesn’t get it. But I was wrong; he did get it. In
fact, many of the core Linux developers did. Three years to the month
after that public conversation with
Ted, the
Developer’s Certificate of Origin (DCO) became the official required
way to handle the “CLA issue” for Linux and
it remains
the policy of Linux today. (See item 12 in Linux’s
Documentation/SubmittingPatches file.)

The DCO,
in fact, is the only CLA any FLOSS project ever needs! It implements
inbound=outbound in a simple and straightforward way, without giving
special powers over to any particular company or entity. Developers
keep their own copyright and they unilaterally attest to their right to
contribute and the license of the contribution. (Developers can even
sign a ©AA with some other entity, such as the FSF, if they wish.)
The DCO also gives a simple methodology (i.e.,
the Signed-off-by: tag) for developers to so attest.

I admit that I once scoffed at the (what I then considered
naïve) simplicity of the DCO when compared to FSF’s ©AA.
Yet, I’ve been since convinced that the Linux DCO clearly accomplishes
the primary job and simultaneously fits how most developers like to
work. ©AA’s have their place, particularly when the developers
find a trusted organization that aligns with their personal moral code
and will enforce copyleft for them. However, for CLAs, the Linux DCO
gets the important job done and tosses aside the pointless and
pro-corporate stuff.

Frankly, if I have to choose between making things easy for developers
and making them easy for corporate lawyers, I’m going to chose the
former every time: developers actually write the code; while, most of
the time, company’s legal departments just get in our way. The FLOSS
community needs just enough
CYA stuff to get by; the DCO
shows what’s actually necessary, as opposed to what corporate
attorneys wish they could get developers to do.

What about Relicensing?

Admittedly, Linux’s DCO does not allow for relicensing wholesale of the
code by some single entity; it’s indeed the reason a Linux switch to GPLv3
will be an arduous task of public processes to ensure permission to make
the change. However, it’s important to note that the Linux
culture believes in GPLv2-only as a moral foundation and
principle of their community. It’s not a principle I espouse; most of my
readers know
that my
preferred software license is AGPLv3-or-later. However, that’s the
point here: inbound=outbound is the way a FLOSS community
implements their morality; Project Harmony seeks to remove community
license decision-making from most projects.

Meanwhile, I’m all for the “-or-later” brand of relicensing
permission; GPL, LGPL and AGPL have left this as an option for community
choice since GPLv1 was
published in late 1980s. Projects declare
themselves GPLv2-or-later or LGPLv3-or-later, or
even (GPLv1-or-later|Artistic)
(ala Perl 5) to identify their culture and relicensing permissions.
While it would sometimes be nice to have a broad post-hoc relicensing
authority, the price for that’s expensive: abandonment of community
clarity regarding what terms define their software development
culture.

An Anti-Strong-Copyleft Bias?

Even worse, Project Harmony remains biased against some of the more
fine-grained versions of copyleft culture. For
example, Allison
Randal, who is heavily involved with Project Harmony, argued
on Linux
Outlaws Episode 204 that Most developers who contribute
under a copyleft license — they’d be happy with any copyleft
license — AGPL, GPL, LGPL. Yet there
are well
stated reasons why developers might pick GPL rather than LGPL.
Thus, giving a for-profit company (or non-profit that doesn’t
necessarily share the developers’ values) unilateral decision-making
power to relicense GPL’d works under LGPL or other weak copyleft
licenses is ludicrous.

In its 1.0 release, Project Harmony attempted to add a “strong
copyleft only” option. It doesn’t actually work, of course, for
the various reasons discussed in detail above. But even so, this
solution is just one option among many, and is not required as a default
when a project is otherwise copylefted.

Finally, it’s important to realize that
the GPLv3,
AGPLv3, and LGPLv3 already offer a “proxy option”; projects
can name someone to decide the -or-later question at a later time.
So, for those projects that use any of the set { LGPLv3-only,
AGPLv3-only, GPLv3-only, GPLv2-or-later, GPLv1-or-later, or
LGPLv2.1-or-later }, the developers already have mechanisms to
move to later versions of the license with ease — by specifying a
proxy. There is no need for a CLA to accomplish that task in the GPL
family of licenses, unless the goal is to erode stronger copylefts into
weaker copylefts.

This is No Creative Commons, But Even If It Were, Is It Worth
Emulation?

Project Harmony’s proponents love to compare the project
to Creative Commons, but the
comparison isn’t particularly apt. Furthermore, I’m not convinced the
FLOSS community should emulate the
CC license suite wholesale,
as some of the aspects of the CC structure are problematic when imported
back into FLOSS licensing.

First of
all, Larry
Lessig (who is widely considered a visionary) started the CC
licensing suite to bootstrap a Free Culture movement that modeled on the
software freedom movement (which he spent a decade studying). However,
Lessig made some moral compromises in an attempt to build a bridge to
the “some rights reserved” mentality. As such, many of the
CC licenses — notably those that include the non-commercial (NC)
or no-derivatives (ND) terms — are considered overly restrictive
of freedom and are
therefore shunned
by Free Culture activists
and
software freedom advocates alike.

Over nearly decade, such advocates have slowly begun to convince
copyright holders to avoid CC’s NC and ND options, but CC’s own
continued promulgation of those options lend them undue legitimacy.
Thus, CC and Project Harmony make the same mistake: they act amorally in
an attempt to build a structure of licenses/agreements that tries to
bridge a gulf in understanding between a
FaiF community and those
only barely dipping their toe in that community. I chose the word
amoral, as
I often do, to note a situation where important moral principles
exist, but the primary actors involved seek to remove morality from the
considerations under the guise of leaving decision-making to the
“magic of the marketplace”. Project Harmony is repeating
the mistake of the CC license suite that the Free Culture community has
spent a decade (and counting) cleaning up.

Conclusions

Please note that IANAL and
TINLA. I’m just a
community- and individual-developer- focused software freedom policy
wonk who has some grave concerns about how these Project Harmony
Agreements operate. I can’t give you a fine-grained legal analysis,
because I’m frankly only an amateur when it comes to the law, but
I am an expert in software freedom project policy. In that
vein — corporate attorney endorsements notwithstanding — my
opinion is that Project Harmony should be abandoned entirely.

In fact, the distinction between policy and legal expertise actually
shows the root of the problem with Project Harmony. It’s a system of
documents designed by a committee primarily comprised of corporate
attorneys, yet it’s offered up as if it’s a FLOSS developer consensus.
Indeed, Project Harmony itself was initiated
by Amanda
Brock, a for-profit corporate attorney for Canonical, Ltd, who is
remains involved in its
drafting. Canonical,
Ltd. later hired Mark Radcliffe (a big law firm attorney,
who has
defended
GPL violators)
to draft the alpha revisions of the document, and Radcliffe remains
involved in the process. Furthermore, the primary drafting process was
done secretly in closed meetings dominated by corporate attorneys
until the documents were almost complete; the process was not made
publicly open to the FLOSS community until April 2011. The 1.0
documents differ little from the drafts that were released in April
2011, and thus remain to this day primarily documents drafted in secrecy
by corporate attorneys who have only a passing familiarity with software
freedom culture.

Meanwhile,
I’ve asked
Project Harmony’s advocates many times who is in charge of Project
Harmony now, and no one can give me a straight answer. One is left to
wonder who decides final draft approval and what process exists to
prevent or permit text for the drafts. The process which once was in
secrecy appears to be now in chaos because it was opened up too late for
fundamental problems to be resolved.

A few developers are indeed actively involved in Project Harmony. But
Project Harmony is not something that most developers requested; it was
initiated by companies who would like to convince developers to
passively adopt overreaching CLAs and ©AAs. To me, the whole
Project Harmony process feels like a war of attrition to convince
developers to accept something that they don’t necessarily want with
minimal dissent. In short, the need for Project Harmony has not been
fully articulated to developers.

Finally, I ask, what’s really broken here? The industry has been
steadily and widely adopting GNU and Linux for years. GNU, for its
part, has FSF assignments in place for much of its earlier projects, but
the later projects
(GNOME,
in particular) have either been against both ©AA’s and CLA’s
entirely, or are mostly indifferent to them and use inbound=outbound.
Linux, for its part, uses the DCO, which does the job of handling the
urgent and important parts of a CLA without getting in developers’ way
and without otherwise forcing extra liabilities onto the developers and
handing over important licensing decisions (including copyleft weakening
ones) to a single (usually for-profit) entity.

In short, Project Harmony is a design-flawed solution looking for a
problem.

Further Reading

0Project Harmony
advocates will likely claim to their § 5, “Consequential Damage
Waiver” protects developers adequately. I note that it
explicitly leaves out, for example, statutory damages for copyright
infringement. Also, some types of damages cannot be waived (which is why
that section shouts at the reader TO THE MAXIMUM EXTENT PERMITTED BY
APPLICABLE LAW). Note my discussion of jurisdictions in the main text
of this article, and consider
the fact that the CLA recipient will obviously select a jurisdiction where
the fewest possible damages can be waived. Finally, note that the OR
US part of that § 5 is optionally available, and surely corporate
attorneys will use it, which means that if they violate the agreement,
there’s basically no way for you to get any damages from them, even if
they their promise to keep the code copylefted and fail.

1Note:
Earlier versions of this blog post conflated slightly “choice of
venue” with “choice of law”. The wording has been
cleared up to address this problem. Please comment or email me if you
believe it’s not adequately corrected.