Please consider adding info@fsf.org to your address book, which will
ensure that our messages reach you and not your spam box.

Read and share online:
https://www.fsf.org/blogs/licensing/FSF-copyright-handling

Dear Ruben Safir,

Part of the Free Software Foundation (FSF's) core mission is to
advance policies that will promote the progress of free software and
freedom. Because copyright handling has been a topic of concern
lately, we are taking this opportunity to explain the four purposes
behind FSF copyright handling, as well as examine the impact of
potential alternatives.

For some GNU packages, the ones that are FSF-copyrighted, we ask
contributors for two kinds of legal papers: copyright assignments, and
employer copyright disclaimers. We drew up these policies working with
lawyers in the 1980s, and they make possible our steady and continuing
enforcement of the GNU General Public License (GPL).

These papers serve four different but related legal purposes, all of
which help ensure that the GNU Project's goals of freedom for the
community are met.

One purpose is to give explicit permission to include the material in
that GNU package. That is the most basic need.

The second purpose is to empower the FSF to go to court and say, "That
company is infringing our copyright when it tramples the freedom of
users, denying them the freedom that our license gives them." The
assignment does this by transferring the copyright to the FSF. (This
form of support for GNU is one of the original purposes for founding
the FSF.)

A third purpose is to make it possible to add additional permission to
specific pieces of code. For example, to take code released under GNU
GPL version-3-or-later and release it under GNU Lesser GPL
version-3-or-later.

Sometimes the individual author (or authors) of the code assign it.
Sometimes a company assigns copyright on its employees' writings. The
result is the same: The FSF gets the copyright.

There is an alternative to copyright assignment: instead of assigning
the copyright, the author can disclaim copyright on that material.
That means the material is effectively in the public domain. This
achieves the first and third of those purposes described above, but
not the second. It could weaken our copyright claim if it happened for
a large part of the program, but it's no problem if this occurs only
for a small part of the program.

Another alternative is to give the FSF an unlimited perpetual
nonexclusive license for the material. This is different from
disclaiming copyright in that the author continues to hold the
copyright, but, in practical terms, they are effectively equivalent:
Both achieve the first and third purpose but not the second.

We have preferences about these alternatives, which depend on the
situation, but we are flexible when possible.

The fourth purpose is to protect the community from the danger of
employers' surprise claims. What happens if J. R. Hacker contributes
some code, and we use it, all with good will and believing that to be
valid; but then Hacker's employer says, "That code belongs to us!
Hacker wrote it while on the job, working for us, so it's a 'work made
for hire.' You never had the right to distribute it, and we're going
to sue all of you. Or maybe only some selected victims if that seems
advantageous."

The way we prevent this is by asking Hacker to get an employer
copyright disclaimer before contributing material. That way, Hacker's
employer will either sign, saying, "Ok, Hacker, you can contribute
your changes to that program," or refuse to sign, which warns Hacker
not to write contributions to that program while employed by that
employer. (We hope the employees of such companies find new, less
stingy employers soon.) This approach has saved us from a number of
messy situations, because some contributors asked their employers to
sign disclaimers and were refused. We could not use their code, but at
least everyone involved avoided getting in legal trouble.

The employer disclaimer also deals with the employer's patents and
interface copyrights that might cover the contributor's code.

We don't need an employer disclaimer in every case. If an individual
says, "I am an independent contractor; no employer could have a claim
on this work," that's clear cut, so we don't ask for an employer
disclaimer from the nonexistent employer.

Sometimes there is no individual contributor, in a legal sense,
because the employer assigns the copyright. Legally, that's solid.
(It's good that some people get paid to contribute to free software.)

These four purposes are related in a complex way, and not all are
applicable to every contribution. But each one is clear in concept.
One purpose is to give us permission to use the code, another the
power to defend it, a third to relicense it. The fourth purpose is to
make sure no marauding employers have an opportunity to wreak havoc.

The maintainers of some GNU packages would like to use a simple
mechanism instead of these legal papers. It is called a "Developer
Certificate of Origin" (DCO), and it makes a rough attempt at serving
the first purpose and the fourth purpose. It does not try to achieve
the second purpose, or the third one. Also, it is sloppy: the existing
DCOs don't make it clear who is the author of the code in a
contribution.

What about protecting against employer surprise claims? Instead of the
employer's signature saying, "We commit not to attack you," the DCO
gives us an employee's signature saying, "I certify that no employer
can claim rights to this code and attack you." It may do some good,
but it is hardly equivalent.

We think we can accept some amount of code from individual
contributors using DCOs instead of copyright assignments, for some
packages. To avoid weakening our protection for the whole community,
we need clear and careful DCOs, designed to make the copyright facts
clear.

Careful use of DCOs means that each contributor should sign only for
personal contributions and identify clearly what they consist of.
Thus, Contributor A would sign a DCO only for the material that A
contributes. If A would like us to include code copied from some
released free program with a suitable compatible license, maybe we
can. But a DCO from A is a non-solution as regards the legalities.
Contributor A should instead show us what code that is, and where it
comes from, so we can think about the best way to use code from there.

If A wants us to install code written by B, we don't want A to sign
claiming, "I have the right to contribute this code (which I got from
B)." If B wrote the code, we want B to contribute it, not someone else
on B's behalf. Also, concretely, we need to know which code was B's
and which was A's -- so we can register the copyright in the United
States. Even though we think of DCOs as an inferior choice, we are
thinking of developing a DCO that does the DCO job right.

A few lines of code contributed under a clear DCO are not a problem,
but as the part of a package contributed under a DCO increases, so
does the effect of the DCO's drawbacks. This goes double if a sloppy
DCO is used.

To avoid weakening our protection for the whole community against
employer surprise claims, DCOs should be accompanied by the usual
employer disclaimers. Sadly, using DCOs would make relicensing code to
move it into certain libraries a precarious and unwieldy proposition,
relying on getting agreement of the other copyright holders or
removing their code.

Accepting corporations as copyright holders of code in GPL-covered
software packages risks causing a particular problem: a corporation is
unlikely to join in a GPL enforcement action against its subsidiary,
its parent, another subsidiary of its parent, its supplier, or its
client. Thus, even projects that use DCOs should not accept them from
corporations.

As our community well knows, the power of big tech corporations is
increasing, and their influence over organizations in the free
software community is increasing too. Some of them are opposed to GPL
enforcement, which is an increasing problem. This is not the time to
weaken our legal defenses; we must keep them strong.

#

P.S. You can learn about the assignment process by reading our
Contributor's Frequently Asked Questions (FAQ)
guide

The FSF would like to thank the many community legal experts who
reviewed this article and provided valuable suggestions based on their
knowledge of these complex legal issues. Among the expert reviewers
were Deb Peckham and Carlo Piana.

Support the FSF's Licensing & Compliance Lab:

• If you are not already signed up, you can keep up to date on
  upcoming legal issues by joining the licensing & compliance mailing
  list.




• Support our work by donating to the FSF.

Sincerely,

Free Software Foundation