einhverfr's Journal: Worries about BSD/GPL3 compatibility

THe recent Linux/OpenBSD flap has provided some additional fodder for some of my concerns about the GPL3 and its compatibility with other licenses. Please note that I have discussed my concerns with the various people involved and I dont think my concerns have been well answered. So I now offer them to the community.

Before I begin, I am not a lawyer, though this is intended to be a response to what I believe is a campaign of misinformation by a few attourneys with an axe to grind. Even if I was a lawyer, this would not be intended as legal advice. If the points here matter, I recommend you pay an attourney for some time to discuss them with you. Futhermore, I recommend finding an attourney who does not have a strong opinion of Free Software.

Under the GPL2, the work as a whole license had to be in line with the licenses of components, but those components did not have to share all the restrictions of the GPL v2. This way, one could use BSD-licensed files inside a GPL v2 codebase without worrying about questions of sublicensing rights and the like. This is because the work as a whole copyright and the copyrights of individual elements can be different, and the GPL2 does not require imposing its concerns on BSDL components when they are distributed separately. Hence one can always remove these components and revert them to the original licenses. In essence, although one is not generally allowed to release derivative works of BSDL code under other licenses, the restrictions placed on those works do not reach down into the original elements provided by the BSD Licensor. (i.e. Original BSD-licensed elements-- including but not limited to code-- are still governed by the BSD-license alone.)

Originally, the GPL3 had the same structure-- additional permissions for code were OK, but these could be removed when substantial modification was made (see the first discussion draft). This was changed in the second discussion draft so that one did not need to assert any copyright over the work whatsoever in order to change the terms. The question is: Can one change the licensing terms on BSDL code legally under the terms of that license? I believe there is no safe answer to that question.

The first issue is that non-exclusive copyright licenses are generally indivisible and nontransferrable as a matter of law in the US and in many other countries. This means that unless otherwise stated, the recipient of a nonexclusive license does not receive the right to sublicense the work under any terms. This has been a matter of settled law in the US since the early 20th century and no changes in law give any reason to think that has changed. (The 1976 Copyright Act has given rise to larger questions relating to exclusive licenses, however, but at least in the 9th Circuit, at the moment, these are considered to be indivisible and nontransferrable as well-- see Gardner v Nike, 2002.)

So the question becomes, do BSD-style licenses, as a rule, provide an implicit sublicensing right?

This question hinges on the intent of the license. Is it there to provide anyone the ability to do anything with the code? Or is it there to provide certain permissions to members of the general public to use the code, if they obtain it in certain ways?

In most uses of BSD-licensed code, this question of intent is only academic. The BSD Licenses do not require one to release code, so proprietary vendors do not have to give out their own code. Without the code, users don't have a way to utilize their rights under the license, so it doesn't matter.

However, in the context of the GPL, this question is very important because it affects the ability to change the license on the code without the express consent of the original author, as was the issue in the Atheros network driver dispute. If the intent is to grant these rights to the recipient of the code, as Theo de Raadt claims (and I agree with this point), then one cannot change the license merely by saying so.

Ultimately it is difficult or perhaps even dangerous to try to judge intent in such matters without having some objective measure to back one up. Different licensors could read the license differently and could express different intents. Thus I have to wonder how safe it is to assume that the intent of the license is to allow sublicensing unless the particular variant specifically states this (as does the MIT License).

However, some variants of the MIT license do not state this. In particular the X.org license and the ICU license both removed the word "sublicense" from the list of allowed activities. Furthermore they address every downstream recipient of the code in their license grants "Permission is hereby granted, free of charge, to anyone who obtains a copy of...." Therefore the intent is clearly to grant the set of rights under the license to every downstream recipient of the code irrespective of any work-as-a-whole copyright or copyright license that may be in place. This permission grant cannot be removed from the files as a whole without first creating a derivative work (adding substantial new material worthy of a copyright. Even after this, the license of the work as a whole does not restrict elements of the derivative work under this license).

Note that the above concerns generally apply at the file level. Copying a few functions into your own code may be a different matter (creating a derivative work), and an answer there would depend in part on what "any portion of" means in section 7 of the GPL v3. However, when a GPLv3 application depends on components under these licenses, and these components fall under the Corresponding Source definition, it seems to me to be entirely possible to end up with serious licensing conflicts.

In my conversations with Eben Moglen on this subject, he has suggested that a requirement for GPL3 compatibility (with section 7 permissions removal) is that the copyright owner must be willing to let the software be distributed under the exact terms of the GPL. These comments are also inline with various GPL v3 rationale documents. Given Theo de Raadt's recent comments on Kernel Trap, I do not believe that this is a safe assumption to make for BSD-licensed components and thus they may have to be evaluated on a case-by-case basis for GPL3-compatibility. On the bright side, this may give copyright owners who opt for the BSD-license more teeth when they complain about misappropriation by projects under the GPL, at least when that license is the GPL v3.