Archive for September, 2006

Rights and Wrongs of Hacking Source Licenses at Distribution Time

Thursday, September 21st, 2006

The highly interesting busybox license change process rumbles on. For me at least, it is the first time that I saw anyone really try to grapple with the implications of the upcoming GPL version 3 on projects that licensed some or all of their sources under GPL V2 “or later” terms.

As I described in my previous post, until now nobody seems to have thought through the ramifications of allowing a distributor to specify the license version he chooses to distribute under, or how he should specify what he has done in a non-conflicting way.

There must be a surefire way to use and distribute a GPL 2 “or later” package under GPL 2 rules. For example, so that a recipient cannot try to apply the GPL 3 “give me your crypto keys” rules when the distributor honestly and correctly wants to play only under GPL2 rules. But as I described in the previous post, merely noting that you distribute the sources under specifically GPL2 rules leaves the package you pass on in conflict with itself. The source files in the package are still annotated to allow “modification” under the terms of the GPL 2 “or later”.

What I proposed on the busybox list here and explained more clearly here was that a very strong way to make it clear how you are distributing would be to modify the GPL terms shown in the source files, ie, to show that you are distributing under GPL2 only as allowed to by the license, removing the “or later” part from the originally GPL2 “or later” sources. This has the advantage that the distribution method is consistently shown throughout the sources, and the action is ‘sticky’, ie, if you were given those sources under GPL2 only then they remain GPL2 only through further distribution.

While the maintainer seemed to like the idea, there was a cognet objection from Glenn L McGrath, who says

GPLv2 clause 9 states "If the Program specifies a version number of
this License which applies to it and "any later version", you have the
option of following the terms and conditions either of that version or
of any later version published by the Free Software Foundation."

I dont see where it implies the right of licensees to remove the "or
later" statement. For all i know removing the "or later" clause may be
adding a further restriction to the license which isnt allowed according
to clause 6.

In addition to that concern, Clause 1 of GPL2 also seems to not like the idea as I noted in a reply

''1.  You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty;  keep intact all the
notices that refer to this License  and to the absence of any
warranty; and give any other recipients of the Program a copy of this
License along with the Program.''

Well something will have to give. What is needed is some definitive recipe to tell people who wish to distribute GPL2 “or later” projects under specifically GPL2 terms, as the license grants them the right to do so, such that unfair – unfair because they in good faith chose to play under GPL2 rules – GPL3 demands cannot be applied to such distributors.

Bruce Perens and the current busybox maintainer ended their argument for now by agreeing to both consult with the Software Freedom Law Center, a place that has found its moment to leap forward with advice I should think. So hopefully instead of IANAL there will shortly be an opinion from someone who IAL and who has a grasp of the confusing niceities of the text for a change.

GPL2 “or later” distributor sends mixed signals when distributing as GPL2

Tuesday, September 19th, 2006

A couple of people have pointed out something that is important about the GPL2 “or later” license: the distributor chooses the license version they distribute under. (Actually the busybox maintainer Rob Landley pointed it out last week too). The actual language used on sources licensed as GPL2 “or later” looks like this:

* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.

Note that this text uses “you” and “your” to apply equally to everyone who gets distributed to and who is distributing.

In the “distributor chooses” reading of this text:

* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.

a new class of information is generated about the distribution action which I did not see expressed anywhere so far, that is a sort of distribution action license versioning metadata. For example if Nokia have a GPL 2 “or later” package on a secure (crypto-locked) phone platform, in the “distributor chooses license version” reading when distributing they can specify “Nokia gives you this specifically under the GPL2, so no keys”. If the guy then distributes the package on, he can choose the terms afresh, but since he has no keys for the Nokia platform that has no impact on Nokia.

The distributor cannot make a GPL V2 “or later” distribution action stick when he gives it out under, say, GPL V3. If he says, here, have this GPL V2 “or later” package under GPL V3 only terms, the recipient need only redistribute it to himself or through a friend to have it validly on GPL V2 terms again. So it seems this distribution action license choice is only useful for one thing, getting the distributor out of distribution conditions found in later license versions, it seems it can’t be used as a forced upgrade off older license versions.

Simply by stressing ‘modify’ rather than ‘distribute’ from the and/or:

* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.

the text can equally be read another very different way, which is that the distributed-to person is granted the right to modify the sources “under the terms of” the GPL version he chooses. Someone who makes this reading of the text can believe they had a right to apply for example GPL v3 duties on their distributor, and ask them for the keys needed to allow installation as specified by the current GPL3 draft[1]. Folks can argue the distributor saying (where? when subsequently challenged?) that he distributed on the terms of GPL v2 beats out this reading, but it’s not that clear to me because it was also the distributor himself that gave the recipient the license telling him he had the right to modify and distribute according to the terms in GPL V2 “or later”; if modification and installation according to GPL V3 needs the distributor’s keys the GPL V3 gives a way to demand it of the distributor. There are at the least mixed signals coming from the distributor in this case it seems to me.

These proposed considerations only apply to GPL V2 “or later” licenses, stuff like Linux which is GPL2-only seem to have no risk that GPL V3 provisions might be claimed as duties for the distributor.

[1] http://gplv3.fsf.org/gpl-draft-2006-07-27.html

”1. Source Code … The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code…”

I’ll make you free if I have to lock you up!

Monday, September 18th, 2006

Interesting goings-on over on the Busybox list. Busybox is a single app that masquerades as a large set of common unix tools like ls, a shell and so on. The maintainer is planning to, well, sort of migrate the project to being GPL v2-only. It’s a bit complex because there are a variety of copyright notices floating around in there at the moment. He discussed it on the list for some time and although there are some people that want to have GPL2+ (meaning, GPL v2 or any later version at the user’s discretion) the proposal seemed to be gaining traction.

The issue is significant, because in the current GPL3 drafts there is language that would require any signing keys to be given up with the sources. If you plan to design a device which, for the security of the customer, would reject code, eg, updates, that were not signed by the manufacturer, then the GPL3 would appear to disallow using GPL2+ or GPL3-only licensed code with such a scheme.

Linus has already come out against this idea as one of the reasons he will be sticking with GPL v2 for Linux. But of course Linux is just one part of the puzzle, and Linux is fairly unusual in having changed the default language of the GPL v2 license from “version 2 or later” to fix it firmly with v2 only. There is a lot of code out there that may suddenly inherit this “I demand your crypto keys because I am treating your code as licensed under GPL v3″ problem simply because they left the default “v2 or later” in there.

Bruce Perens, who was in at the start of Busybox but left it many years ago, argued on the busybox mailing list against changing the license to GPL v2-only, but I think he is mistaken. I think GPL v2 “or later” licenses may turn out to be a very ugly can of worms. In any event the result was the maintainer a few hours later announced that busybox was going v2-only.

The problems over on busybox are the first sign for me of what may be a major licensing train crash brought on by the thoughtless handing over of the author’s licensing terms to Richard Stallman. Great man that he is, that is a lot of power he is channelling right now, he alone, through the FSF, can randomly dictate the licensing terms of a vast body of “GPL v2 or later” code that is currently in use. Under the banner of “increasing freedom”, he is in the position to disallow current usage of existing code that is currently used in accordance with the license. For an unlikely but illuminating example, if he decides that the GPL v4 requires the distributor to donate $10 to the FSF, then recipients who decide they will use “GPL v2 or later” code on the GPL v4 terms can force the distributor to do this. And this is on code that is currently used based on the fairly well understood GPL2 terms where there is nothing like that.

Now you may scoff at such a wild straw man argument, but I discover over the weekend there are people that believe that the GPL v2 requires you to give up any signing keys you may use on a binary created from it! In a subthread starting here, Rich Felker proposes the idea as fact and I argue against it. Later in the thread Rich insists he will take people to court if they fail to deliver such keys; I bring up Redhat’s own signing of GPL’d packages as a case where he should attack according to his principle. He deflects this by saying that since it is possible to install unsigned packages, he will not need to sue Redhat. However, yum by default will not install unsigned packages, and besides you cannot do so without the root password for the box. For many reasons, a user may not have the root password. Does Rich propose that everyone with a box with GPL v2 software on it must be given root access? There has been no reply.

Anyway, it is all getting a bit chilling this talk of negating the possibility of actions of users of free software in order to make them free. It’s starting to sound a little bit like the start of a tortured logic found in Socialist states, where the workers must build palaces “to be free”, grub around in the fields to feed people in offices “to be free”. Purely by that innocent sounding “or later” found in the default GPL2, a huge amount of power, proportional to the amount of software with “or later” in the license, has landed on one person, Richard Stallman. Was everyone really aware they had elected a Great Leader, no matter how trustworthy, and that their package was part of a mobilization force under orders from above?