Suits and Patents: A Report from the GPLv3 Launch Conference [LWN.net]

Suits and Patents: A Report from the GPLv3 Launch Conference

Posted Jan 23, 2006 18:59 UTC (Mon) by kirkengaard (subscriber, #15022)
Parent article: Suits and Patents: A Report from the GPLv3 Launch Conference

Not having been there, it sounds like a very good summary of a very good meeting. It's nice to have this virtuality about what is going on where.

" ... but a question was also asked about the definition of "Complete Corresponding Source Code" in Section 1 where it includes "any encryption or authorization codes necessary to install and/or execute the source code". The specific concern was about whether code could be encrypted with GnuPG for sending, but I failed to understand the issue as to my mind you would be encrypting it with the recipient's key, so they would already have it."

I also see the question as mistaken; "any encryption or authorization codes necessary to install and/or execute the source code" tends more to evoke the possibility of black-box encryption schemes and non-open document or media encoding such that the open source of the program, without the encryption or authorization, is not functional. A Gatesian bargain of sorts, if you will. Opening the source with the exception of the bits that make it functional, allow it to interoperate, or authorize its use. Especially in the coming TPM era. "Sure, have the source. You can't do anything with it, but here you go.", foreclosed by this provision in GPL v3.

(Log in to post comments)

Suits and Patents: A Report from the GPLv3 Launch Conference

Posted Jan 25, 2006 13:25 UTC (Wed) by dyork (guest, #2819) [Link]

Yes, this clause was added to GPLv3 to specifically ensure that entities that modify GPL'd code can't escape the requirement to provide source code by appearing to give it to you... but then not giving you the key or password necessary to open it up. There were a couple examples given such as one where in the past someone had provided source code in an encrypted ZIP file, but then failed to provide the password. Similarly someone had done something which required an encryption key to decode it. Both of those examples would now not be allowed by GPLv3.

The person asking this question was, if I recall correctly, quite concerned about sending GnuPG-encrypted copies of his source to other developers and then needing to provide his key for them to decrypt. Unfortunately I never got a chance to ask him about his specific concern because I couldn't quite understand it. By the very nature of GnuPG, if you are encrypting something to send to someone, you are encrypting it with *their* public key. They have their *private* key to decrypt it, so you don't have to provide them with anything.

It seems to me that this provision of the GPLv3 would really only apply for symmetrical (i.e. secret-key) encryption where there is a shared-secret key or password that parties need to know or have. In public key encryption like PGP/GnuPG, the data is normally encrypted with the recipient's key.

Suits and Patents: A Report from the GPLv3 Launch Conference

Posted Jan 25, 2006 19:51 UTC (Wed) by tres (guest, #352) [Link]

Perhaps it was if person A sent it to B encrypted w/ B's public key and then C wants it. To decode it C would need B's private key.

Suits and Patents: A Report from the GPLv3 Launch Conference

Posted Jan 26, 2006 10:27 UTC (Thu) by nlee (guest, #730) [Link]

I think what this is say is that encryption is really only a transport mechanism. Thus encryption should not be use as a mechanism to 'pretend' or to be seen to have satisfied the legal responsibility under GPL to distribute the code upon request.

In this case, C could request the code from either A or B. Depending on who 'distributed' the application to him in the first place. So in B's case, they'd just re-encrypt the code and send it to C. Furthermore, its likely under GPL that B would have the 'freedom' to distribute the code however they wish. ie. send the code unencrypted, put simiply put it up on a web page.

Another example one could think of were this would work is a company putting an encrypted zip file on a website, but only providing the 'password' (key file or whatever) to clients who receive the application.

GPL3 and providing encryption keys

Posted Jan 26, 2006 22:42 UTC (Thu) by giraffedata (subscriber, #1954) [Link]

Yes, this clause was added to GPLv3 to specifically ensure that entities that modify GPL'd code can't escape the requirement to provide source code by appearing to give it to you... but then not giving you the key or password necessary to open it up. There were a couple examples given such as one where in the past someone had provided source code in an encrypted ZIP file, but then failed to provide the password. Similarly someone had done something which required an encryption key to decode it.

Giving someone the code in encrypted form is such an outrageous failure to deliver the code that I'm sure any court would find it doesn't satisfy GPLv2 either. It's like being ordered by a court to turn over your accounting records to an investigator and you give him an encrypted copy. You think you wouldn't wind up in jail?

In the press over the past few years, they have said that the encryption issue is about code that won't run without keys. E.g. you get all the source code for your Tivo, but the Tivo boot loader won't load it unless you sign it with a key you don't have.

On the public key encryption (GnuPG) thing, I can see where someone might think that GPL poses a problem. If I give you a signed object code file, derived from material I got under GPL, one might think the conditions of GPL require me to give you the key required to reproduce the exact bits I gave you, to wit my private key.