It Matters Who Owns Your Copylefted Copyrights

by Bradley M. Kuhn
on June 30, 2021

Throughout the history of Free and Open Source software (FOSS), copyright
assignment has simultaneously been controversial and accepted as the norm
in our FOSS communities. This paradox, I believe, stems entirely from some
key misunderstandings that perpetuate. This issue requires urgent
discussion, as two of the most important FOSS projects in history
(GCC
and glibc) are right now
considering substantial and swift changes to long-standing copyright
policies that date back to the 1980s. This event, and other recent events
over the last few years in the area of GPL compliance and corporate FOSS
adoption, point to long-term problems for projects. This essay works
through these nuances, and will hopefully assist FOSS contributors as they
make difficult decisions about copyright ownership for their projects. At
the end, I provide a summary list of issues to consider when creating
copyright ownership policies for FOSS.

The Default Is: You Give It Away To Your Boss

I was at one time bemused, but now am mostly aghast, at the true paradox
of common wisdom about copyright assignment for FOSS projects. I don’t believe anyone has done a
statistically valid study, but anecdotally it’s rare to find a FOSS
contributor who enjoys assigning copyright to another entity. FOSS
contributors who do assign copyright to a non-profit charity that collects
copyrights (such as the FSF or Conservancy) often complain about the
complexity and annoyance of the paperwork to get started as a contributor.
Even more commonly, contributors express disgust or annoyance at the
pressure from the project to give away something that should be rightfully
theirs.

I am sympathetic on both points, and have worked over my career to design,
implement, and improve copyright assignment processes for projects —
in hopes to address that first complaint. However, the second concern
— the preference of FOSS contributors to keep their own
copyrights, is an ironic complaint. Here’s why:

Almost no contributors to larger FOSS projects hold their own
copyrights. If they have not gone through a process to assign them to a
charity, the most likely scenario is that their employers own those
copyrights. My colleagues at Conservancy have been working on
the Contract Patch
project — which seeks to educate FOSS contributors about their
inherent right to employment agreement negotiation, and seek more favorable
terms in those employment contracts. However, over the years of our
Contract Patch work, we still find that only dozens (among the thousands of
FOSS contributors) have insisted that their company allow them to keep
their own copyrights. If you work for a company, check your employment
agreement. I’ll bet that your employer owns your copyrights for everything
you do at work — including your contributions to FOSS — unless
there’s a separate agreement that gives those copyrights to a charity like
Conservancy or FSF.

As a result, in debates about copyright ownership, discussions of what
policy contributors want regarding the fruits of their labor is sadly moot.
Without a clear, organized mitigation strategy to assure that FOSS
contributors keep their own copyrights, a project (such as GCC or glibc) that
switches from a standing “(nearly) all copyrights assigned to a
charity” model to a plain Developer Certificate of Origin (DCO) or
naked inbound=outbound contributor arrangement will, after a period of years,
mostly likely have copyrights that are primarily held by the employers of
the most prolific contributors, rather than by the contributors themselves.

The Faustian bargain that causes this default is the
“work-for-hire” doctrine in the USA (and similar arrangements
that exist around the world). When you take a job, in most places in the
world, by default, your employer owns and/or effectively controls all your
copyrights. They argue that they’re paying you handsomely for this and as
such they have every right to own it all. Perhaps that argument has merit
with regard to software that will ultimately be proprietarized, but for
copylefted software, the value proposition is different and history shows
that the arrangement leads to surprising results.

Copyleft Is Weakened When Most Copyright Holders Oppose Enforcement

Copyleft licenses are not magic pixie dust. Copyleft is not a
legislatively-mandated regulation (e.g., pollution regulations) —
which are enforced by government staff. Ultimately, an entity — most
commonly the copyright holders themselves — must proactively enforce
GPL. This entity can be an organization, an individual, a group of
individuals, a group of organizations, or a mix of all of
those. Someone must enforce the rules; so-called
“spontaneous compliance” is a myth promulgated by those who
oppose copyleft.

Yet that myth’s apparent unexamined truthiness has taken hold; many FOSS
contributors reasonably think that it does not matter who owns the
copyright of their copylefted works. If it’s GPL’d, they surmise,
surely someone out there will enforce the GPL when it’s violated.
Or, perhaps the contributors think that GPL violations on their particular
codebase are rare. Either way, most contributors avoid the effort required
to figure out who owns their copyrights and ponder whether that entity will
uphold copyleft in a reasonable way. Nevertheless, I really urge FOSS
contributors to think through this issue with care and healthy skepticism,
as they may be surprised at the outcome. What lurks in the backchannels
may well surprise you:

Once upon a time, copyleft enforcement was not considered controversial by
many otherwise-pro-FOSS companies. In recent years, companies that prefer
non-copylefted FOSS have succeeded in making even the most mundane GPL
enforcement appear as controversial and industry-destabilizing.
Many developers who contribute to GCC and glibc — even ones that work
for historically FOSS-friendly companies — will be surprised to learn
that their employers (or at least their legal departments) are opposed to
any GPL enforcement. Conservancy, as the main organization actively doing
GPL enforcement, hears this kind of pressure regularly. Our colleagues at
FSF historically told us that they hear the same. It’s rarely done
publicly — but, when public, criticisms are delivered by proxies in a
subtle, “you don’t really need copyleft to be enforced anyway, do
you?” manner. The public
arguments are usually couched in a careful “dog whistle”
style. While the message comes through loud and clear to executives,
lawyers, companies and their trade associations, it’s easily missed by
contributors — who understandably have a much more important task to
do: writing great FOSS code!

We expect that you may be surprised by this, but we can tell you that: in
private, companies that contribute to key copylefted projects are not so
subtle. They have communicated to those of us in the GPL enforcement
community on several occasions — a message delivered by many executives
over a period of many years — that they would prefer both Conservancy
and FSF to curtail, or outright end, GPL enforcement. Their view, as
communicated to us, is that GPL enforcement causes customers to think
copyleft is problematic. As one executive once said to me: “We
consider it a failure if any customer ever even asks us if they have
to worry about GPL compliance”. These companies usually say:
“well, we will always comply with the license, but we’d prefer if
anyone who is our customer (or potential customer) simply is just left alone
if they violate”. Once, an executive actually claimed to me that his
company, a huge multinational software company, would: “cease to build
any products on Linux and other GPL’d software at all if Conservancy and FSF
don’t cease their enforcement”. That statement was fortunately bluster
and bluff; the company in question is still heavily invested in copylefted
software, including Linux, GCC, and glibc, but the sentiment is a common one
that we hear privately often. And, that company has since funded work to
discredit GPL enforcement. Conservancy faces constant pressure and threats
regarding its GPL enforcement efforts, and we’re aware that FSF has faced to
similar pressure.

In parallel, these companies have also steadily worked to hold more of the
copyrights in key copylefted works — primarily by hiring the key
developers that contribute to key copylefted projects. While I oppose this
outcome, it’s undeniably a rational approach: if companies hold the
copyrights, they can decide when, how, where and most important if
copyleft licenses are ever enforced. This process is well underway for
copylefted works that don’t have any policies about copyright ownership. For
example, the “Who Contributes to Linux?” reports by LWN show
starkly over recent years: fewer contributions
coming copyrighted by
individuals,
and more
contributions copyrighted by companies. While corporate involvement is
always welcome in FOSS projects, we (as a FOSS community) have not
responded with the necessary care to question why the companies, rather
than the individual contributors, should own our
FOSS. Only
very few developers have even questioned this issue; we thank them for
their efforts, but such questions are simply not raised enough.

As such, the most important consideration in ending copyright assignment
to a charity is to consider what the employers of most of the developers
will do with those copyrights, and whether they will enforce the
copyleft in the best interest of the community. Even worse, might they
eventually sell
those copyrights to someone who will use enforcement in a manner that a
charity never would — for their own avarice rather than the good of
the community?

While the remainder of this essay addresses at length other secondary
considerations and nuances regarding copyright ownership in copyleft
projects, this point is the absolutely most important one:

Most for-profit copyright holders prefer copyleft to function
much like non-copylefted FOSS. Namely, “it’s certainly nice when
folks voluntarily release their changes, improvements and ‘scripts
used to control compilation and installation’, but if they don’t,
their failure to do so should be begrudgingly tolerated, and compliance
should never be compelled for those who refuse”.

Violations Are More Common Than You Think

During this recent upheaval in the GCC
community, I spoke at length with a GCC developer who has contributed to
the codebase regularly for decades. After I’d explained some of issues
above, the developer stated: “Well, is any of this really an issue
for GCC? When was the last time there was a GPL violation on GCC?”.
I glibly answered: “Well, I haven’t heard about one for about a week, but
I’ll surely hear about another one soon.” The developer was flummoxed
to learn that part-and-parcel to nearly every embedded Linux GPL violation
(which have been, for years, innumerable) is a companion violation on GCC.
Specifically, most system-on-chip (SoC) vendors not only have a stock Linux
build given to the OEMs,
but also include a toolchain. More often than not, a GPL violator who has
what we call an “incomplete Complete, Corresponding Source
(CCS)” violation on Linux will also have a
“no-source-or-offer” or
“incomplete CCS”
violation on GCC. The usual reason is that
part of the SDK given
to OEMs must include an appropriate binary toolchain (sometimes with
vendor-specific patches, and almost always with a complex configuration
that’s difficult to reverse engineer) so that
the SoC integrators can compile other
software for the system. This scenario is so common that we in the GPL
enforcement community coined the shorthand term “toolchain
violation” to refer to the scenario where the GCC violation
“tags along” with a Linux violation. While glibc violations of this nature are admittedly less
common than GCC, glibc violations do occur relatively often in the same
manner.

Upstream developers are mostly unaware of how bad the compliance problem
is regarding their code for one simple reason: the folks impacted most by
GPL violations are downstream users, not upstream developers. Furthermore,
correction of compliance problems usually produces code releases that
“work” for the given device on which the original violation
occurred, but rarely is that CCS

released resulting from a GPL enforcement action trivially upstreamable.
After all, this is code written, modified, and/or integrated by developers
whose plan was to “get away” with a GPL violation, so why would
they have invested the time to provide the improvements in a manner that it
was immediately digestible for upstream? My view is that users matter, and
FOSS contributors should care about their experience with the downstream
consequences of their code. I urge FOSS contributors to implement copyright
ownership schemes that have the most likely chance of enabling enforcement
actions principled parties.

The Power of Collective Action

Regarding my views on FOSS copyright assignment, I often quote the famous
gaffe of (former USA presidential candidate and senator) John Kerry,
“I voted for it before I was against it” when I’m talking about
copyright assignment. But I don’t quote it purely for self-deprecation; I
never felt the press was all that fair to Kerry, because I think policy
makers should be willing to change their positions over time as
new information comes to light, or when policies that we thought were
beneficial in theory prove problematic in practice. I once thought
universal copyright assignment for a copylefted work to a single charity
was an absolutely necessity. Then, Conservancy’s successful and continuing
work with various BusyBox copyright holders, and our collaboration with
Christoph Hellwig, showed me that there was huge value in individuals
having copyrights and making their own choices about enforcing copyleft.
Still later, I realized that individuals like Erik Andresen and Christoph
Hellwig are quite rare, as most FOSS contributors — even if
they’ve kept their own copyrights — ultimately have to take on such
political and career risk to enforce copyleft that they must often chose
not to because they could easily get blacklisted from major employers for
doing so.

The central thread here is collective action
by principled
people who will use copyleft primarily as a tool for rights of users
and for the improvement of copylefted projects. Ultimately, copyleft
functions best when leaders of a project have the agency, wherewithal,
commitment, and collective consensus to either ensure copyleft functions to
protect their users’ rights, or enable another entity to do that job for
them in a principled way that serves the public good (usually in contrast
to the interests of for-profit industry). (Note that even if that interest
is “vendor-neutral”, as that means the interests served are the
common business interests of the vendors, but not their
customers.)

These issues are complex. Every policy change, or lack of policy change,
will have many unintended consequences. An apparent “simple
move” away from mandated assignment to a centralized organization
could well be a decision to ultimately move copyright holding to for-profit
corporations and their trade associations — all of whom are unlikely
to stand up for the GPL and user rights. Beyond all else, I urge caution
and slow deliberation before any policy changes about copyright control. I
ask FOSS contributors to do the substantial and necessary homework of not
only reading and considering the points of this essay, but those points
raised by all parties. As you do, keep in mind that every party, including
me, has a policy goal in mind for copyleft. I and Conservancy are very
transparent that our policy goal is to see copyleft licenses enforced
regularly on behalf of end users who buy products on the open market that
contain copylefted code. We believe, as a policy matter, that copylefted
copyrights are best held by entities that have a bona-fide track record of
serving the public good, act in a principled and ethical manner in doing so
— the most important principles being to never prioritize financial
gain over users’ rights — and who won’t back down and give up when
faced with the inevitable anti-copyleft backlash. Others, probably
including your employer and the trade associations to which they pay
membership dues, probably disagree with this position, but you should ask
questions and listen carefully to see if you’re getting a straight answer.
After you’ve heard everyone’s position, decide for yourself who deserves to
have your copyrights: your employer, a charity, or yourself. Once you’ve
decided, you’ll have hard work ahead to change the default (which will
likely be your employer once projects drop their copyright assignment
mandate).

A Word on FSF’s GPL Enforcement

The elephant in the room that I’ve not yet mentioned is the current status
of the FSF as an organization. There is no question, given the recent mass
resignation of their management, and other rapid leadership change surprises,
that the FSF faces serious challenges in the next few years. I personally
was previously affiliated with the FSF. That affiliation ended in 2019, so I
have no real information about the internal status of the FSF since
then. What I do know is that FSF currently lacks sufficient capacity to
follow up on any GPL violations on GCC and glibc that we’ve reported for
years. That said, if I have to chose between the strict dichotomy of: (a)
copyrights held by the FSF (which has the possibility of recovery in the
future and restoration to an organization that actively enforces the GPL)
vs. (b) copyrights held by companies — many of whom are known to oppose
enforcement of the GPL, I would still pick the FSF. Remember that copyright
does not expire for a very, very long time. GCC and glibc are both codebases
that prove the half-life of well-written software is very long, and that
software stays relevant and useful for much longer than any of us usually
admit. We have to think long term about the copyright ownership of
copylefted works. While there are serious short-term and medium-term
problems at the FSF, we have to consider carefully who is the best long-term
steward of copyrights: companies or charities. Most importantly, changing 30
years of careful planning about the copyright inventory of important
codebases is certainly not a decision to be finalized in a matter of just a
few weeks or even months. Thus, most of all, I ask FOSS contributors to take
care and ample time in their deliberations on such matters.

A Summary of Recommendations and Considerations

As promised at the start of this essay, here is a laundry list of
recommendations and considerations that any copylefted project should
consider regarding how to structure its copyright ownership rules. This
list is provided as a quick reference only, and readers should keep in mind
the complexity of the topic before jumping to a conclusion about the right
policies. Not every issue below was addressed in detail in the essay above,
but if there is interest from the community, I will publish further essays
on other topics.

• Without your active work to avoid it (such as by modifying your contract or
  demanding assignment to another entity), for-profit employers will control
  your copyrights. You typically have no say into how or whether the
  license of your project is enforced if your employer holds your
  copyrights.




• Modern copyright assignments to charities such as the FSF or
  Conservancy usually take two forms: either your employer has a blanket
  copyright assignment, or you must individually assign copyright. In the
  latter case, there are typically two components: a disclaimer from
  copyright from your employer, and an assignment from you. In either
  case, you should speak at length with your employer’s legal department to
  figure out what form, if any, is in place, and what will happen to those
  systems if your project changes its copyright aggregation policies.




• FOSS contributors have safety in numbers. A strong consensus that
  your project wants to see copyleft enforced for your users can create
  leverage that mitigates risk of “blacklisting” of those
  who chose to enforce copyleft licenses. When policies like copyright
  assignment to a charity or copyright ownership only by individuals are
  set project-wide, companies historically have simply accepted it. (The
  Samba project is an excellent example of a project where the developers
  have control.) By contrast, each contributor faces a steep climb in
  negotiating their ownership of the copyrights in the absence of such
  policies.




• While assignment to a charity can be annoying and feel problematic,
  this is often the most expedient way to assure that the copyleft license
  of your project is upheld. Conservancy, for example, will accept one-off
  assignment from FOSS contributors to strategically important FOSS
  projects. Even if you (collectively) chose to not mandate assignment for
  your project, it’s valuable to assist and encourage your contributors to
  either develop together a collective individual copyright ownership plan,
  or assign to different charities, or recommend a mixture of the two.




• As an upstream developer, you’re likely going to be unaware of most
  copyleft violations on your code. If possible, work with an entity that
  has the time and resources to investigate violations for you, and empower
  that entity to act on your behalf if possible.




• Pay attention to the details of Contributor Licensing Agreements
  (CLAs). Often, these require that you give up almost as many rights as a
  copyright assignment would require you to give up
  anyway. Avoid
  asking your contributors to agree to a CLA.




• Developer Certificate of Origins (DCOs) and other inbound=outbound
  contribution regimes are very good, useful and
  recommended. However ultimately such systems are
  entirely orthogonal to who holds the copyright. DCOs and contribution
  terms are general statements that attest to your right and permission to
  make contributions under the project’s license, but are, by design,
  silent on the details. A DCO is absolutely compatible with a project
  that separately requires copyright assignment, or with a project that has
  other recommendations about how developers should handle copyright
  ownership.




• Seek and consider advice from all sources. Everyone with an opinion
  on these topics has a policy agenda. Ask what their policy agenda is
  when they advise you. Ask them their view on copyleft enforcement.
  Ask them if they’ve ever investigated copyleft violations on your
  software, and if so what they found and what their opinion is. If you’re
  considering assigning your copyrights to someone, most notably your
  employer (who, again, is likely to by default receive your copyrights)
  be sure you’ve fully understood their policy and views on these
  matters. Insist that they put their policy and views in writing for you
  for future reference. Ask for strong commitments, and be skeptical if
  you cannot receive them.

https://line4k.blog/who-should-own-foss-copyrights/

Tags:

conservancy,
GPL,
ContractPatch,
law,
licensing,
resources