GnuTLS, copyright assignment, and GNU project governance

This article brought to you by LWN subscribers Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

Copyright assignment is a topic that brings out strong passions in the free software community, especially when the assignee is a corporate entity. Assignment to a nonprofit entity such as the Free Software Foundation (FSF) may eliminate some of the problems that can occur when assigning copyright to a company. However, recent events in the GnuTLS project are a reminder that copyright assignment can have a number of downsides even when assigning to a nonprofit chartered with the goal of protecting free software.

The problem with (corporate) copyright assignment

Copyright assignment tends to evoke polarized opinions in the free software community. On the one hand, various companies have promoted copyright assignment agreements as being in the best interests of free software—Canonical is perhaps the most prominent example in recent times. On the other hand, the community at large seems more skeptical of the value of these agreements; Michael Meeks is among those who put the counterarguments well. Project Harmony, an attempt to create a standardized set of copyright licensing agreements, has met with a chilly reception from various quarters of the community, and (so far) seems to have gained little traction in the free software world.

A blog post by Richard Stallman on the FSF web site highlights the most significant of the risks of assigning copyright when contributing code to a commercially owned free software project. One of the powers conferred by a copyright assignment agreement is control of the choice of license of the software: as the copyright owner, the assignee (alone) has the power to change the license of the project. Commonly, corporate copyright assignment agreements place no restriction on the choice of license that the assignee may in the future choose, thus putting a great deal of power in the hands of the assignee. As Richard notes:

[The company] could release purely proprietary modified or extended versions including your code. It could even include your code only in proprietary versions. Your contribution of code could turn out to be, in effect, a donation to proprietary software.

On the other hand, the Free Software Foundation requires copyright assignment for many of the projects hosted under the GNU umbrella. This is a choice of the project creators when making the project a GNU project. The main reason given for this is that being the sole copyright holder puts the FSF in the best position to enforce copyright in the event of a GPL violation. Of course, being the sole copyright owner also gives the FSF the ability to change the license on a GNU project. However, the motivations of a company and the FSF differ substantially: whereas a company is ultimately motivated by profit (and its motivations can change with shifting financial circumstances and changes of company ownership), the FSF is a non-profit charity chartered to further the interests of free software. Thus, its copyright assignment agreement includes an explicit promise that any future distribution of the work will be under some form of free software license.

GnuTLS and the FSF

GnuTLS is "a secure communications library implementing the SSL, TLS and DTLS protocols". The project was founded in 2000, under the GNU umbrella, by Nikos Mavrogiannopoulos. Over the life of the project, the other major contributor has been Simon Josefsson.

That there was a problem in the project became unmistakable on December 10, when Nikos posted the following note (entitled "gnutls is moving") to the gnutls-devel mailing list:

I'd like to announce that the development of gnutls is moving outside the infrastructure of the GNU project. I no longer consider GnuTLS a GNU project and future contributions are not required to be under the copyright of FSF. The reason is a major disagreement with the FSF's decisions and practices. We note however, that we _do_ support the ideas behind the FSF.

This elicited a rather blunt response (entitled "GNUTLS is not going anywhere") from Richard Stallman:

Nikos, when you volunteered to maintain GNUTLS, the GNU Project entrusted its development to you. Your contributions so far are appreciated. However, the project GNUTLS does not belong to you. If you want to stop doing this job, you can. If you want to develop a fork of GNUTLS under another name, you can, since it is free software. But you cannot take GNUTLS out of the GNU Project. You cannot designate a non-GNU program as a replacement for a GNU package. We will continue the development of GNUTLS.

Richard's response raises a number of interesting issues. The matter of ownership of the project name is perhaps the simplest, and was acknowledged by Nikos:

I pretty much regret transferring all rights to FSF, but it seems there is nothing I can do to change that. If I receive a formal request from FSF I'll change the name of gnutls and continue from there.

In the days since then, however, the name hasn't changed and there does not seem to have been a formal (public) request to do so. One possible reason for this might be found in a response to Richard's mail from Werner Koch (maintainer and primary author of GnuPG and libgcrypt, both of which are GNU projects):

Nikos started the development of GNUTLS under the GNU label on my suggestion. He is the principal author of GNUTLS and gave away his legal rights on that work without any compensation or help. The success of GNUTLS is not due to the GNU project but due to Nikos' and Simon's work […] Claiming that the FSF has any moral rights on the name of that software is absurd.

Indeed, of the somewhat more than 11,000 commits in the GnuTLS Git repository, all but around 400 are by either Nikos or Simon. Simon has not spoken up in the current mail thread, but he remains an active contributor to the project.

Thus, while the FSF might have some legal claim on the project name based on common law trademarks, such a claim is, morally speaking, less clear. Furthermore, there are existing projects, such as gnuplot and Gnutella that riff on the "GNU" name without being official GNU projects; indeed, Gnutella does this despite an FSF request that the name should be changed. Also noteworthy in this context is the fact that the gnutls.org domain is registered to Nikos.

Having worked within the framework of the GNU project for 12 years, Nikos's reasons for wanting to move out of the project must have been important ones. In response to a question from Eli Zaretskii about his reasons, Nikos said:

The main issue is that I'm tired of pretending that I'm participating to a project I am only allowed to contribute code (and not even express a different opinion).

Nikos then went on to outline three criticisms of the FSF and GNU projects. The first of these related to copyright assignment:

(a) I felt particularly frustrated when FSF (when gnutls started around 2000) was insisting the transfer of the copyright to it, even though I had decided to transfer the copyright to FSFE (this is a very old issue but it had great influence on me as I realized that the transfer of rights was not simply for protection against copyright violations).



As Richard confirmed, assignment of copyrights for all GNU projects (that employ assignment) is solely to the US-based FSF, rather to one of the regional sister organizations (located in Europe, India, and South America). One can easily imagine a number of reasons for this state of affairs. Given the FSF's desire to have a single copyright holder, it makes sense to assign all copyrights in an individual GNU project to a single entity, and for administrative and legal reasons it is probably simpler to assign copyrights for all projects to the same entity.

However, one can also imagine that when the primary developers of a project reside outside the US—both Nikos and Simon are in Europe—the requirement to assign to the US-based FSF, rather than FSF Europe, is irksome. In addition, the FSF Europe tends to have a quieter, less confrontational style of working than its US counterpart, which may also have been a factor in Nikos desire to assign copyright to the European organization.

The other theme that came out in Nikos's criticisms was the problem of feeling figuratively distanced from the parent project:

(b) The feeling of participation in the GNU project is very low, as even expressing a different opinion in the internal mailing lists is hard if not impossible.

(c) There is no process for decision making or transparency in GNU. The only existing process I saw is "Stallman said so"…

The lack of openness was a theme echoed by Werner in reply to Eli's question:

I can't speak for Nikos, but there are pretty obvious reasons knowable to all GNU maintainers. I don't know whether you, as GDB maintainer, are subscribed and follow gnu-prog-discuss@gnu.org. We had a long discussion a year ago about the way the GNU project is managed and first of all about all of the secrecy involved there. The occasion was a request to have at least an open archive of the g-p-d list, so that non-GNU hackers would be able to learn about architectural discussions pertaining to the GNU project.

The content of the discussion that Werner refers to is, of course, unavailable, so it is difficult to gain further insight into why discussions on the gnu-prog-discuss mailing list need to be secret.

Clearly, at least a few GNU project maintainers are quite unhappy with the current governance of the umbrella project. And when a maintainer of twelve years' standing wants out of the GNU project, that suggests that there are some serious governance problems.

Of course, this is hardly the first time that governance issues have caused significant division in GNU projects. The GCC project is one of the most notable cases, providing an example both in the late 1990s, with the egcs fork of the GCC compiler (where the fork ultimately supplanted the original GCC project inside the GNU project), and more recently when questions on plugin licensing led the FSF to pressure the GCC project to delay the GCC 4.4 release, to the disgruntlement of many GCC hackers.

The problems of assigning copyright to a nonprofit

The events in the GnuTLS project reveal a number of the problems of copyright assignment that remain even when assigning to a nonprofit such as the FSF.

The first of these problems has already been shown above: who owns the project? The GnuTLS project was initiated in good faith by Nikos as a GNU project. Over the lifetime of the project, the vast majority of the code contributed to the project has been written by two individuals, both of whom (presumably) now want to leave the GNU project. If the project had been independently developed, then clearly Nikos and Simon would be considered to own the project code and name. However, in assigning copyright to the FSF, they have given up the rights of owners.

The mailing list thread also revealed another loss that developers suffer when signing a copyright assignment agreement. As noted above, the ability of the FSF—as the sole copyright holder—to sue license violators is touted as one of the major advantages of copyright assignment. However, what if, for one reason or another, the FSF chooses not to exercise its rights? Juho Vähä-Herttua raised this point in the mail thread:

As a side note, I find Werner's accusations, as written on his blog, of FSF not defending its rights in case of GnuPG copyright violations very serious. When a copyright holder transfers their rights to FSF they also transfer their rights to defend against copyright violations.

The blog post that Juho refers to questions a number assumptions around FSF copyright assignment. In the post, Werner states:

My experience with GnuPG and Libgcrypt seems to show that the FSF does not care too much about [copyright violations]. For example, at least two companies in Germany sold crypto mail gateways with OpenPGP support provided by GnuPG; they did not release the source code or tell the customers about their rights. The FSF didn't act upon my requests to stop them violating their (assigned) copyright on GnuPG.

Once a developer assigns copyright, they are at the mercy of the assignee to enforce the copyright. In this particular case, one can speculate that the failure to pursue the violation was likely a shortage of human resources. As Richard noted, "We have staff for GPL enforcement, […] but there are so many violations that they can't take action on all."

But that very response throws into question the wisdom of assigning a large number of copyrights to a resource-starved central organization. A more distributed approach to dealing with copyright violations would seem more sensible. And indeed, organizations such as gpl-violations.org and the Software Freedom Conservancy have shown that the GPL violations can be successfully fought without being the sole copyright holder in a work of code. By now, the argument that copyright assignment is necessary to successfully enforce free software licenses is rather weak.

Werner outlines a few other problems with FSF copyright assignment. One of these is the seemingly arbitrary nature of copyright assignment across GNU projects. He points out that there are two cryptographic libraries that are part of the GNU project, one of which (libgcrypt) requires copyright assignment while the other (Nettle) does not. The seeming arbitrariness in this example was further emphasized by the fact that GnuTLS (which, as we already saw, requires copyright assignment) switched from using libgcrypt to using Nettle.

The rationale that copyright assignment is necessary to allow relicensing also strikes Werner as dubious. He considers the two likely scenarios for relicensing GPLed software. One of these is relicensing to a later version of the GPL. This scenario is in most cases already covered by the default "or later" language that is usually applied to software licensed under the GPL. Although there are projects that deliberately exclude the "or later" clause when applying the GPL—most notably the Linux kernel—it's likely that few or no GNU projects exclude that clause. Projects that exclude the "or later" language of the GPL are likely also to avoid using copyright assignment.

The other likely scenario for relicensing a GPL project is to relax the license constraints—for example, switching from GPL to LGPL, so as to allow interoperability with software that is not under a GPL-compatible license. Such relicensing can be performed even when the project lacks a copyright assignment (as was recently done for portions of the VLC code base). However, this requires a formidable effort to obtain permissions from all contributors. But, Werner points out, the FSF has in practice rarely been interested in relaxing licensing constraints in this way.

In summary, using copyright assignment as a tool to allow relicensing seems to serve little practical use for the FSF, and comes at the cost of removing the contributor's freedom to relicense their code.

Werner's blog post highlighted one more problem with copyright assignment—a problem that occurs with assignment both to companies and to nonprofits. The requirement to sign a copyright assignment agreement imposes a barrier on participation. Some individuals and companies simply won't bother with doing the paperwork. Others may have no problem contributing code under a free software license, but they (or their lawyers) balk at giving away all rights in the code. In general, those contributors just silently fail to appear. By chance, a discussion on copyright assignment is currently taking place in the Gentoo project, where Greg Kroah-Hartman, a long-standing contributor to the project, commented on this point:

On a personal note, if any copyright assignment was in place, I would never have been able to become a Gentoo developer, and if it were to be put into place, I do not think that I would be allowed to continue to be one. I'm sure lots of other current developers are in this same situation, so please keep that in mind when reviewing this process.

To illustrate his point, Werner related his recent experience with the libgcrypt project. Concluding that copyright assignment served little practical use, he relaxed that requirement for libgcrypt: starting in April of this year, he permitted contributions accompanied by an emailed kernel-style developer certificate of origin. The result was a noticeable increase in patches sent in to the project.

Concluding remarks

The risks of assigning copyright to corporate entities have in the past been well publicized. Assigning copyright to a nonprofit eliminates the most egregious of those risks, but carries its own burdens and risks, which have not necessarily been so well publicized. One of those burdens is the necessity of buying into an associated governance model, one that may or may not work well for project developers. The FSF governance model is, it seems, not working well for a number of GNU projects. Developers should consider (in advance) the questions of project ownership that are bound to arise if the governance model does not work for them and they want to separate from the governing project.

In addition, the costs of assigning copyright to a nonprofit should be balanced against the (supposed) benefits. The assertion that assigning copyright to a single entity improves the chances of successful prosecution of a copyright violations looks dubious when one considers that the assignee may not be well enough resourced to prosecute every violation. To that should be added the facts that assignment means that the assigner loses the ability to themselves prosecute copyright violations and that copyright violations have been successfully prosecuted even when there is no single copyright holder. Finally, the value of copyright assignment as a tool that permits the FSF to relicense code seems rather limited in practice. In summary, the arguments for copyright assignment start to look decidedly weak, even when the assignee is a nonprofit such as the FSF, and it is hard to find any justification for the FSF maintaining this requirement.

(Thanks to Carlos Alberto Lopez Perez for the heads-up.)

