[U-Boot-Users] GPL 2 "or later" concern

[U-Boot-Users] GPL 2 "or later" concern

[Andy Green]

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

[U-Boot-Users] GPL 2 "or later" concern

[Alex Zeffertt]

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

[U-Boot-Users] GPL 2 "or later" concern

[Andy Green]

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

[U-Boot-Users] GPL 2 "or later" concern

[Alex Zeffertt]

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

[U-Boot-Users] GPL 2 "or later" concern

[Jerry Van Baren]

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).

[U-Boot-Users] GPL 2 "or later" concern

[Andy Green]

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

[U-Boot-Users] GPL 2 "or later" concern

[Jerry Van Baren]

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

[U-Boot-Users] GPL 2 "or later" concern

[Andy Green]

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.

>    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.

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