or do we GNU hackers really have the freedom we demand from others?

Free software is about sharing code and thus to help others. Why are GNU hackers supposed to help others with their code but required to reject help from others? Is this what free software is about? I doubt it.

Those questions arise due to a GNU policy of requiring copyright assignments for some of the GNU software. There are no clear rules which software needs to have these legal paper exchange, but at most of the early GNU software does (Emacs, gcc, libc, coreutils, guile).

The official position of the FSF on the requirement of copyright assignments is explained in a short article by Eben Moglen. It is commonly known that there are two main reasons why one should consider to assign the copyright to a single trustworthy entity.

The first one is about legal security or whether it is possible to go after and stop copyright violations. Well, that is the theory. My experience with GnuPG and Libgcrypt seems to shown that the FSF does not care too much about it. For example, at least two companies in Germany sold crypto mail gateways with OpenPGP support provided by GnuPG; they did not released the source code or told the customers about their rights. The FSF didn’t acted upon my requests to stop them violating their (assigned) copyright on GnuPG. This is in contrast to the FTF as run by the FSFE ¹ and the gpl-violations group. However, with the FSF holding the copyright, the latter organization has no way to go after such copyright infringements.

The second reason for copyright assignments is to be prepared for future re-licensing. This is actually the most compelling reason. With distributed copyright it would be a lot of work and still often impossible to change the license of a software — even if all contributors would agree. Exceptions like the recent VLC re-licensing are quite rare. A valid question is whether there is at all a need to change a license. Related to the GPL, I see two cases: The first case is fortunately a minor problem because only a few projects are affected by it: Upgrading from GPL version2 to version 3. Usually this is easy, because most GPL projects use the “or any later version” option. Those sticking to GPLv2only, like Linux or OpenVAS, are really troubled and would either need to search the agreement of all contributors or to rewrite the GPLv2only parts of the code.

The second case is about relaxing the conditions of the license, for example from GPL to LGPL. This might be justified for better general interoperability or to help free software projects with GPL incompatible licenses. In the case of the GNU project such a change is done quite seldom. It would technically be easy to do this due to their copyright assignment policy. However, within the GNU project it is more than hard to convince the FSF decision maker(s) that such a change benefits the GNU project. My impression is that to the FSF it is far more important to protect the GNU project than the actual freedom of helping others. Something akin to: “Let us build a high fence so we are free from proprietary software on our pasture. Why care about the lone hackers outside who don’t want to seek shelter behind our fence. After all only we are the good ones.”

Case in point: The GNU towers once declared Libgcrypt to be the standard GNU crypto library. As a core GNU project it was clear that we need to collect copyright assignments. We even started with a special copyright assignment to declare Libgcrypt as an independent project from GnuPG (which is its origin). So now we have a lot of cipher algorithms were we are sure of the code provenience — i.e. everything has been assigned or disclaimed using a lot of snailed paper. The drawback of this policy is that we had to implement all stuff by ourselves — despite that there was already a lot of highly optimized LGPLed cipher code available. We were simply not allowed to use it.

Some years later Nettle was put together as a collection of freely available algorithms and some new glue stuff. The author did not care about copyright assignments and thus was able to use better optimized code. Nevertheless, Nettle was declared a GNU project and GNUTLS (GNU’s answer to Heathrow^W OpenSSL) eventually switched to Nettle due to a 10% better performance figure in some areas. The funny thing is that GNUTLS itself requires copyright assignments.

Now why shall Libgcrypt require assignments if the GNU project does not care about such dependencies? A reason might be that Libgcrypt provides a fallback in case there will ever be a legal problem with Nettle. I consider this a purely theoretical point because basically both do the same and if suits wants to go after Nettle, I see no reason why they should not also go after Libgcrypt. Copyright is not anymore the sharpest weapon they can use; patents and trademarks are more dangerous than SCOing.

Back in April, I concluded that something needs to be done — at least for Libgcrypt. What I then did was pretty straightforward: Libgcrypt now accepts contributions after having received a simple mail (right, e-mail, no transatlantic snail mail) with a Developer’s Certificate of Origin as known from other projects. Voilà, patches with new features and performance improvements started to come in. Obviously, hackers who were afraid of the paper work or assigning their work to an organization ailing on obstinacy of age, gained interest in this GNU software and started to help out with their experience and time. I really like this outcome; let’s hope it lasts.

Sure, other GNU projects with assignment policy are not anymore able to freely copy and paste code from Libgcrypt. But well, they won’t be able to that with Nettle code either. For the sake of the greater free software community I consider this a minor disadvantage compared to Libgcrypt vegging out as a too closed GNU project.