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

[Niall Douglas]

On 27 Sep 2006 at 20:06, simo wrote:

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

Of course I know that! It's obvious to any normal, rational, sane 
human being!

However, the GPL is not an ordinary document. It's a LEGAL document. 
Legal documents are rules for lawyers to work around, and if there is 
ANY ambiguity then it's a BAD legal document.

To a judge - and let us remember that most judges are old, very 
technologically unaware and rather pedantic - to them, the difference 
between a program, its DLL's and the shell which runs it is virtually 
none. As an example, you try explaining why a program signed 
differently functions IDENTICALLY to an old person. They will surely 
say "but no, when you run it it shows different text on the screen. 
This is a difference".

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

Which is the entire point of the legal profession!

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

So you're telling me that a network connection does not package up 
chunks of data into packets and unpack them on the receiving end?

I see no difference from a split RAR file commonly used on binary 
newsgroups. It's just a TCP/IP stack does the reassembly for you.

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

Of course you do! Otherwise anyone could listen in to your data 
stream! Just because it's generated randomly during Diffie-Hellman 
negotation does not make it unspecial!

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

Lawyers exist to FUD. Do you really want to dispute this?

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

That's not necessary. It's easiest just to drop the key disclosure 
requirement altogether. Far better actually to require that signing 
binaries can be bypassed by asking the user. For example, if I 
replace the flash image on a tivo box, I'd be okay with it flashing a 
light to say it's an unsafe image and then you have to press an extra 
button to make it go.

We're talking less than half a percent of tivo users here. Pressing 
an extra button every time they turn it on isn't the end of the world 
for power users.

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

Trusted computing doesn't necessarily deny choice. Much like nuclear 
weapons don't necessarily mean nuclear war. It may have use we can't 
see yet. I personally don't want a knee-jerk reaction.

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

Ah, but in some ways I see the point of the GPL dying. In the long 
run, we are better off without the GPL at all. I'm just not sure when 
the GPL will outlive its usefulness.

Cheers,
Niall