FSF copyright handling: A basis for distribution, licensing and enforcement
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: