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

Andy Green andy at warmcat.com
Wed Sep 20 00:00:23 CEST 2006


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




More information about the U-Boot mailing list