Problems with the GPL as I see them (was: Re: Kernel developers' position on GPLv3)

Niall Douglas s_fsfeurope3 at nedprod.com
Wed Sep 27 18:13:36 UTC 2006


On 26 Sep 2006 at 22:54, Bjoern Schiessle wrote:

> > They then go on to say that in their opinion, you can't write any wording 
> > which wouldn't have unintended consequences and therefore you should drop 
> > the attempt. That's going too far IMHO, but I do WHOLEHEARTEDLY agree that 
> > the wording is FAR, FAR too vague. 
> 
> > For example, as far as I understood  revision 2, it COULD be
> > incompatible with BSD licensing,
> 
> The BSD Licence allows you to do everything you want with the software
> even to use it with a licence which allows you nothing, so how could it be
> incompatible with the GPLv3?

It's more the other way round. In section 5.[2] it says:

b) You must license the entire work, as a whole, under this License 
to anyone who comes into possession of a copy. This License must 
apply, unmodified except as permitted by section 7 below, to the 
whole of the work, and all its parts, regardless of how they are 
packaged. This License gives no permission to license the work in any 
other way, but it does not invalidate such permission if you have 
separately received it.

Now that SHOULD read "You must license the entire work, as a whole, 
under THE TERMS OF this License to anyone who comes into possession 
of a copy". Otherwise it may be interpreted that any libraries under 
a FreeBSD license must be relicensed as GPL v3 if any GPL v3 code 
uses them.

It should be noted that v2 of the GPL uses precisely this clearer 
phrasing. Or perhaps a clarification that this does not need to apply 
to parts with a different license which doesn't require anything the 
GPL v3 does not permit (eg; no source release).

> > COULD be incompatible with authentication signing keys (ie; this
> > binary was made by me),
> 
> I can't see how you can read this assumption out of draft 2 of GPLv3?
> 
> Draf2 of GPLv3 says:
> "The Corresponding Source also includes any encryption or authorization
> keys necessary to install and/or execute modified versions from source
> code in the recommended or principal context of use, such that they can
> implement all the same functionality in the same range of
> circumstances."
> 
> If you sign a program so that i know that the program comes from you i
> can "install and/or execute modified versions from source
> code in the recommended or principal context of use, such that they can
> implement all the same functionality in the same range of
> circumstances." So you don't have to give me your signing key.

Ah but that doesn't permit "all the same functionality" now does it! 
It means that if you were to run a signing authenticator, you'd get 
different functionality.

We all know what it means, it's just it's ambiguous. Under a tight 
interpretation, it means you must disclose signing keys.

> > COULD be incompatible with permitting GPL v3 binaries to be
> > transferred over a SSL connection etc.
> 
> If you transfer something over SSL from person A to person B than person
> B will be able to execute and/or modify the code as permitted by the
> GPL. So i don't see how it could be prohibited by GPLv3.

Section 6.[3]:

The Corresponding Source conveyed in accord with this section must be 
in a format that is publicly documented, with an implementation 
available to the public in source code form, and must require no 
special password or key for unpacking, reading or copying.

One could interpret a SSL connection as a form of encrypted 
container. Therefore, transferring a file over it DOES require a 
special password or key for unpacking/copying. Of course, SSL 
connections generate a random once-off key per connection to which 
the user normally has no access.

Again, we know what is intended. The problem is, how precisely do you 
disambiguate an encrypted zip file from a SSL connection which copies 
it between computers? At a binary level there isn't really much 
difference between what is being copied and that which copies it. 
Again, we simply need clarification here.

> > And you know what happens next if the FSF doesn't stop? Yep, the kernel 
> > developer's own 'enhancement' of GPL v2.
> 
> I don't think so. I seems like the kernel hackers are quite happy with
> their licence (GPLv2) and remember, they would need the approval from all
> contributors to change the licence.

>From what I understand, they're content but not happy. Improvements 
would be useful. Most kernel developers don't like tivoisation 
either, it's just seeing how to stop it is hard and if you can 
instead ensure that code improvements are recontributed back to the 
community (which I think generally are), it's not a bad compromise.

Also, ultimately, there could be actually useful implementations of 
trusted computing. Hard to see them currently, but why rule them out 
entirely before we know for sure. Better wait another five years and 
then decide. In the meantime, software patents are far more of a 
problem.

On 27 Sep 2006 at 8:19, Stefano Maffulli wrote:

> your statements are extremely important and deserve attention because
> GPLv3 cannot afford leaving ambiguity or generate incompatibility with
> what you say below.

See above.

> > For example, as far as I understood revision 2, it COULD be
> > incompatible with BSD licensing, COULD be incompatible with
> > authentication signing keys (ie; this binary was made by 
> > me), COULD be incompatible with permitting GPL v3 binaries to be 
> > transferred over a SSL connection 
> 
> Can you please point out the precise wordings that in your opinion could
> lead to such incompatibilities?  I couldn't see these problems (although
> I found others and submitted comments). Did you submit your comments?

No. I was waiting for draft 3 to see if they'd get fixed on their 
own. I'm not a fan of the GPL, everyone knows that, so I was doubting 
they'd take much notice.

Cheers,
Niall






More information about the Discussion mailing list