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

[simo]

On Wed, 2006-09-27 at 19:13 +0100, Niall Douglas wrote:
> On 26 Sep 2006 at 22:54, Bjoern Schiessle wrote:
> > 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.

You are confusing "different functionality" (of the GPLed program) with
different output (of the signing authenticator).
They are 2 different things, the GPLv3 draft obviously can only refer to
the functionality of the GPLv3 program it covers.

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

No, only under a broad and tendentious interpretation.

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

This is complete nonsense.

1st there is no way you can interpret an SSL connection as a container,
as it is a mean. You never keep your file on your disk as a network
trace of an SSL connection.

2nd you don't need a *special* password to unpack/read/copy the source
code. The SSL layer is transparent and accessible to anyone.

3rd SSL is also publicly documented with an implementation available in
source code form, so even if some silly person could conceive and
convince someone that SSL is a container you have no problems under this
license.

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

There is a big difference between the two, there is no need to clarify
further. If you really want to be silly you can go down and require to
include a whole dictionary with the license, to be sure each word
meaning is really really really clear.

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

I can't conceive any good use of trust computing that requires something
like the tivoization. You need proof that something is what it it is,
that doesn't mean preventing the user to run something else.
If it is compulsory it's not ok, if the user can choose than it is ok.
The GPLv3 draft does not restrict programs where the final user has
choice.

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

Why not waiting till GPLv4 is out then?
If you see problems and want them fixed at least please file a bug :-)

Simo.