[U-Boot-Users] GPL 2 "or later" concern
Hi folks -
Nice work on U-boot! We are using it with good success on an ARM9 embedded device that is just coming to production.
Late last week the busybox project maintainer decided that the next version will be licensed as "GPL v2 only", matching the Linux kernel license, this is a change from an effective "GPL v2 'or later'" license like U-boot currently has.
During the discussions about this I became aware that there may be some conflict between GPL v3 and using privately signed crypto hashes to validate GPL v2 "or later" binaries, some people at least (Linus) hold that the GPL v3 will allow recipients of the binaries to demand private signing keys. I am uncertain what the facts are, especially as GPL V3 is not done yet, but looking at it the "or later" license it allows the FSF to decide anything they like at any later date and it can cause the distributor trouble accordingly because the GPL V2 "or later" clause arguably at least signs him up for complying with $TO_BE_DETERMINED_BY_FSF_WHEN_THEY_WANT, since a recipient can at any time decide he applies V3 or Vn.
I audited the packages we use and I find more or less of an issue with three: one we use one small file from and it can be rewritten; one only has the "or later" copyright on files we are not distributing the binary for, and lastly there is U-boot, which is currently pretty solidly in the V2 "or later" camp in grep's opinion :-)
Since all U-boot users who may use signatures to verify the provenance of a package are in the same boat, I am wondering what the general opinion about this situation is, and what the feeling would be about a Linux kernel/busybox-style GPL V2-only license.
-Andy
Andy Green wrote:
Since all U-boot users who may use signatures to verify the provenance of a package are in the same boat, I am wondering what the general opinion about this situation is, and what the feeling would be about a Linux kernel/busybox-style GPL V2-only license.
Hi Andy,
I am curious as to what worries you about GPL v3.
Is it that you wish to build a version of u-boot that will only load a kernel that has been signed with your private key?
If so, then your customers will not be free to modify their kernel even though they may access its source.
This seems to go against the spirit of the GPL. However, I can also see that for some products linux will only be used if it can be shown to be tamper proof.
Alex
Alex Zeffertt wrote:
Andy Green wrote:
Since all U-boot users who may use signatures to verify the provenance of a package are in the same boat, I am wondering what the general opinion about this situation is, and what the feeling would be about a Linux kernel/busybox-style GPL V2-only license.
I am curious as to what worries you about GPL v3.
Is it that you wish to build a version of u-boot that will only load a kernel that has been signed with your private key?
If so, then your customers will not be free to modify their kernel even though they may access its source.
This seems to go against the spirit of the GPL. However, I can also see that for some products linux will only be used if it can be shown to be tamper proof.
Hi Alex -
My main concern is in fact updates, currently we package our updates, including U-boot in RPMs and I intend to sign them, and check the signature before allowing install. In this embedded device the user does not have root access. We use RPM so we can completely and easily fulfill the requirement for sources that match any binaries we ship by capturing them into SRPMs.
It seems to me possible for a GPL 2 "or later" user to argue that he should have the signing keys on the basis that he is choosing to "modify" the code on the provisions of GPL 3, not GPL 2 and despite that the distributor says he gave the sources on GPL 2 rules. (Last week on another mailing list a guy was arguing that even GPL2-only code would qualify for the same treatment, but I can't see how that can be).
Because the hardware is fixed, and the special nature of what U-boot does, a workaround for me might be to never update U-boot, but obviously that is less than fully desirable. That way we ship U-boot in the flash, provide sources for it, but never distribute a signed update avoiding the proposed potential problem.
I audited the sources for all the packages we will ship, and there is only one other relatively small source file in net-tools that is GPL2 "or later", so I am considering making sure everything non-proprietary we ship is GPL2-only or more liberal.
-Andy
Andy Green wrote:
Because the hardware is fixed, and the special nature of what U-boot does, a workaround for me might be to never update U-boot, but obviously that is less than fully desirable. That way we ship U-boot in the flash, provide sources for it, but never distribute a signed update avoiding the proposed potential problem.
I know this doesn't relate to your original question about licences, but it would seem to me that distributing u-boot updates is *very* risky. One slip and every customer could be sending you back dead units in the post.
If you make sure before you sell that u-boot can boot a kernel, and upgrade the kernel (without assuming a working kernel is present) you won't need to support u-boot upgrades.
Alex
Andy Green wrote:
Hi folks -
Nice work on U-boot! We are using it with good success on an ARM9 embedded device that is just coming to production.
Late last week the busybox project maintainer decided that the next version will be licensed as "GPL v2 only", matching the Linux kernel license, this is a change from an effective "GPL v2 'or later'" license like U-boot currently has.
During the discussions about this I became aware that there may be some conflict between GPL v3 and using privately signed crypto hashes to validate GPL v2 "or later" binaries, some people at least (Linus) hold that the GPL v3 will allow recipients of the binaries to demand private signing keys. I am uncertain what the facts are, especially as GPL V3 is not done yet, but looking at it the "or later" license it allows the FSF to decide anything they like at any later date and it can cause the distributor trouble accordingly because the GPL V2 "or later" clause arguably at least signs him up for complying with $TO_BE_DETERMINED_BY_FSF_WHEN_THEY_WANT, since a recipient can at any time decide he applies V3 or Vn.
I audited the packages we use and I find more or less of an issue with three: one we use one small file from and it can be rewritten; one only has the "or later" copyright on files we are not distributing the binary for, and lastly there is U-boot, which is currently pretty solidly in the V2 "or later" camp in grep's opinion :-)
Since all U-boot users who may use signatures to verify the provenance of a package are in the same boat, I am wondering what the general opinion about this situation is, and what the feeling would be about a Linux kernel/busybox-style GPL V2-only license.
-Andy
IANAL and I don't even play one on TV. If you want a legal opinion, sorry you came to the wrong place (and didn't pay enough). IMHO. YMMV. etc.
If you have source code that is GPLv2 "or later", it is *your* option to exercise the "or later" clause on the source you hold. If the copyright holder changes the copyright to "GPLv3 only" (or goes closed source, for that matter), you will not be able to use any of the *newer* code that he may produce (that would be GPLv3 only), but he *cannot* remove your right to the source you currently hold that is licensed GPLv2 "or later." Licensing changes is one reason forks happen.
The FSF cannot force you to exercise the "or later" clause. They merely wrote the GPLv2 and GPLv3(beta X) licenses that have been used to license a particular piece of software, but they are not the ones that are licensing the software to you (if they are, see the previous paragraph). (Note that I do not mean to minimize here the debt of gratitude that we owe RMS and the FSF for GPLvN. The GPL licenses have been a tremendously remarkable and enduring work.)
Downstream recipients cannot force *you* to exercise the "or later" clause and force you to GPLv3. It is their option to convert the source that they hold to GPLv3, but that change flows downstream, not upstream.
gvb P.S. I deduce you don't care, but a big part of the consternation over Linus' GPLv2 _only_ stand is because it is impossible to convert the linux kernel to GPLv3 (you would have to get all copyright holders, starting with Linus, to convert their copyrights to GPLv2 "or later" or GPLv3 only). As a side effect of this, GPLv3 _only_ code will *not* be able to be linked with linux kernel code because GPLv3 puts more restrictions on the code than GPLv2, making it *incompatible* with GPLv2. Only GPLv2 or GPLv2 "or later" code will be legal in the kernel (and GPLv2 "or later" is frowned on and probably isn't accepted per the stated philosophies of Linus).
Jerry Van Baren wrote:
If you have source code that is GPLv2 "or later", it is *your* option to exercise the "or later" clause on the source you hold. If the copyright
...
Downstream recipients cannot force *you* to exercise the "or later" clause and force you to GPLv3. It is their option to convert the source that they hold to GPLv3, but that change flows downstream, not upstream.
Well until the GPL V3 comes out, the "or later" protocol is completely untested, since this is the first chance to use it. Here is a hypothetical scenario a few months from now: that a recipient is told by the distributor that he may use the given software under V3 terms if he likes (this is the "or later" language in the license). The recipient says, "cool, I will modify the software you gave me under V3 terms then". Then the recipient points to section 1 of GPL V3
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...''
and he says "well then, can I have your signing keys so I can install my version?" The distributor smiles and says, "oh no, I gave you that package under GPL v2 terms you see, there is no requirement on me to do that". The recipient says, "I don't know about that, nothing in writing about it is there? But what is in writing, on the license you gave me, it says I can 'modify' the code under GPL V2 'or later'. So I want to do that under V3 terms like I said, and you offered in writing. So your keys please!"
I don't know if that would fly or not, but distribution of signed GPL V2 "or later" code means the signing keys are hostage to the outcome of such an attempt, whereas GPL V2-only code is safe from it.
P.S. I deduce you don't care, but a big part of the consternation over Linus' GPLv2 _only_ stand is because it is impossible to convert the linux kernel to GPLv3 (you would have to get all copyright holders, starting with Linus, to convert their copyrights to GPLv2 "or later" or GPLv3 only). As a side effect of this, GPLv3 _only_ code will *not* be able to be linked with linux kernel code because GPLv3 puts more restrictions on the code than GPLv2, making it *incompatible* with GPLv2. Only GPLv2 or GPLv2 "or later" code will be legal in the kernel (and GPLv2 "or later" is frowned on and probably isn't accepted per the stated philosophies of Linus).
Well I would say that I do care about it, but that Linus' stance makes a lot of sense to me. An interesting consideration is that the FSF has a monopoly on creating GPL versions, and that if your project uses the "or later" language, it can mean you can see your project being distributed or modified under terms that you didn't want or ask for, depending on what the FSF (ie, RMS) decide to place in the next version which is out of your control. (Admittedly the old rules are still allowed too, so that should put a limit on how crazy it can get.) But only the FSF can generate a new version of the GPL which can be applied as an option to all existing GPL V2 "or later" projects by magic.
-Andy
Andy Green wrote:
Jerry Van Baren wrote:
If you have source code that is GPLv2 "or later", it is *your* option to exercise the "or later" clause on the source you hold. If the copyright
...
Downstream recipients cannot force *you* to exercise the "or later" clause and force you to GPLv3. It is their option to convert the source that they hold to GPLv3, but that change flows downstream, not upstream.
Well until the GPL V3 comes out, the "or later" protocol is completely untested, since this is the first chance to use it. Here is a hypothetical scenario a few months from now: that a recipient is told by the distributor that he may use the given software under V3 terms if he likes (this is the "or later" language in the license). The recipient says, "cool, I will modify the software you gave me under V3 terms then". Then the recipient points to section 1 of GPL V3
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...''
and he says "well then, can I have your signing keys so I can install my version?" The distributor smiles and says, "oh no, I gave you that package under GPL v2 terms you see, there is no requirement on me to do that". The recipient says, "I don't know about that, nothing in writing about it is there? But what is in writing, on the license you gave me, it says I can 'modify' the code under GPL V2 'or later'. So I want to do that under V3 terms like I said, and you offered in writing. So your keys please!"
I don't know if that would fly or not, but distribution of signed GPL V2 "or later" code means the signing keys are hostage to the outcome of such an attempt, whereas GPL V2-only code is safe from it.
The distributor smiles and says "Sorry, you cannot take _my_ source code to GPLv3 since it is licensed GPLv2 _only_. You can take the source code that licensed GPLv2 "or later" to GPLv3, BUT THAT IS NOT A LICENSE BETWEEN YOU AND ME. Oh, and by the way, if you do that, you will not be able to use _my_ GPLv2 only code with it." (See GPLv2 Section 6, GPLv3 Section 2, and GPLv3 Section 10).
Lets say Dan Malek writes a whizzbang bootloader program named PPCBoot and licenses it GPLv2 "or later".
This gives you a license to use the said source code and add your "special sauce," as long as you abide by the rules of GPLv2 ("or later", but you choose to abide by GPLv2 only). You are free to license your "special sauce" GPLv2 _only_ because that is also compatible with Dan's code.
Say you sell your widget to Joe Schmuk. GPLv2 obligates you to provide both Dan's PPCBoot source code plus your "special sauce" source code to Joe. The critical item here is that you are *not* sublicensing Dan's source - Joe's only license to Dan's source is via GPLv2 "or later" directly with Dan, not via you (GPLv2 Section 6, quoted below). The way I read this, Joe force you abide by any GPLv3 licensing based on his license with Dan (PPCBoot) because you are not party to that licensing agreement. In particular, if he takes his PPCBoot code, which he has licensed from Dan directly (per GPLv2 Section 6) and takes it GPLv3, that is between him and Dan, you and not involved in any way and he cannot force you to convert _your_ copy of PPCBoot to GPLv3 because your copy is separately licensed between _you_ and Dan.
---------------------------------------------------------------- 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. ----------------------------------------------------------------
In GPLv3, this is more explicit: ---------------------------------------------------------------- 2. Basic Permissions.
[snip] Propagation of covered works other than conveying is permitted without limitation. Sublicensing is not allowed; section 10 makes it unnecessary. Conveying is permitted under the conditions stated below. ---------------------------------------------------------------- FWIIW, GPLv3 Section 10 is the equivalent of GPLv2 Section 6, quoted previously, but is not a direct copy.
Joe's only license to your "special sauce" is your GPLv2 _only_ license, and that license is with you (Dan isn't involved). Joe can do what he likes with Dan's license and you are not involved in that licensing. To argue that you are involved since you conveyed the source would be to argue that Dell is party to the Microsoft EULA of every PC they sell since they were the distributor of that software.
FWIIW, the way I read GPLv2 and GPLv3, if Joe converts the source he licensed from Dan (PPCBoot) to GPLv3 (which he is free to do), he will no longer be able to use your "special sauce" code with it because the GPLv3 licensed code is no longer compatible with your GPLv2 "special sauce". The result is Joe's conversion of Dan's license to GPLv3 only "hurts" him in that it increases the limitations on what he can now do with his copy of Dan's code.
P.S. I deduce you don't care, but a big part of the consternation over Linus' GPLv2 _only_ stand is because it is impossible to convert the linux kernel to GPLv3 (you would have to get all copyright holders, starting with Linus, to convert their copyrights to GPLv2 "or later" or GPLv3 only). As a side effect of this, GPLv3 _only_ code will *not* be able to be linked with linux kernel code because GPLv3 puts more restrictions on the code than GPLv2, making it *incompatible* with GPLv2. Only GPLv2 or GPLv2 "or later" code will be legal in the kernel (and GPLv2 "or later" is frowned on and probably isn't accepted per the stated philosophies of Linus).
Well I would say that I do care about it, but that Linus' stance makes a lot of sense to me. An interesting consideration is that the FSF has a monopoly on creating GPL versions, and that if your project uses the "or later" language, it can mean you can see your project being distributed or modified under terms that you didn't want or ask for, depending on what the FSF (ie, RMS) decide to place in the next version which is out of your control. (Admittedly the old rules are still allowed too, so that should put a limit on how crazy it can get.) But only the FSF can generate a new version of the GPL which can be applied as an option to all existing GPL V2 "or later" projects by magic.
-Andy
gvb
Jerry Van Baren wrote:
I don't know if that would fly or not, but distribution of signed GPL V2 "or later" code means the signing keys are hostage to the outcome of such an attempt, whereas GPL V2-only code is safe from it.
The distributor smiles and says "Sorry, you cannot take _my_ source code to GPLv3 since it is licensed GPLv2 _only_. You can take the source
But as a practical matter, unless the distributor meddled with the license text on the files, the files that the recipient got from this distributor do not agree with what he now verbally claims. The written licenses given out by the distributor continues to say
* 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.
I do accept there can be something to this business of the distributor specifying the license version under which he distributes, but I don't understand how that beats out the license sitting on the files. I have also never seen a written specification by the distributor of the basis on which he distributed (I guess because the "or later" protocol has never been exercised yet). What will he do, add it as a disclaimer to the license file? Despite the other files sit there conflicting with it?
The recipient can at least form something capable of being argued by pointing at what he was given and asking the distributor what he is talking about, since when he looks at the files he sees an invitation to "...modify it under the terms of... version 2... or... later", and to repeat that he demands his rights described there to modify under GPL V3 and so needs the signing keys.
I'm not trying to prove that such a demand for keys from the recipient of GPL V2 "or later" code is correct, just to propose there may be some kind of non-crazy argument that can happen about whether the distributor of a signed GPL V2 "or later" binary can keep his keys private when the GPL V3 comes. If that is the case (I don't know that it is, I just propose the scenario and wait for it to be destroyed), then it would suggest that the security of keys used to sign GPL V2 "or later" code is at potential risk, and that if you deploy such keys then GPL V2 "only" (and currently LGPL V2 "or later" as found on eg, uClibc, since LGPL 3 does not have the key clause) is a lower risk bet to sign. And this is why I ask what is the situation with U-boot and a GPL2-only license. I guess if any contributor would never agree to GPL2-only they can say and I can stop wondering :-)
This gives you a license to use the said source code and add your "special sauce," as long as you abide by the rules of GPLv2 ("or later",
In my scenario there is no special sauce, it can be the intact tarball from the upstream author that was just compiled and signed.
- Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
When I look at this the key phrase is ''the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to *these* terms and conditions''. When the sources are marked up with the GPL V2 "or later" language, "*these* terms and conditions" that the recipient is licensed with say GPL V2 "or later". The files you get given say it explicitly in hard ASCII. I don't see how pointing at section 6 helps to kill the proposed scenario, rather it helps it along.
-Andy
participants (3)
-
Alex Zeffertt -
Andy Green -
Jerry Van Baren