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