| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
GPLv3: a first look
GPLv3: a first look
Posted Jan 16, 2006 21:14 UTC (Mon) by iabervon (subscriber, #722)Parent article: GPLv3: a first look
I'm a bit unclear as to the desired effect of "no permission is given to distribute covered works that illegally invade users' privacy", considering the wide variety worldwide in privacy law. I've heard claims that make it sound like this would prohibit acting on user input at all in some jurisdictions.
It would be nice to get confirmation that it is acceptable to not include a private key, provided that the corresponding public key can be replaced by the user. It would be bad if, for example, the GPLv3 prohibited Gentoo's emerge from verifying the signatures on packages when the signing keys are kept secure. Obviously, I shouldn't be able to modify the linux kernel and generate a properly signed kernel package, unless I also modify the key that the checking program uses to check the signature. For that matter, this clause could be read as prohibiting including public keys without private keys at all, which would probably be an issue for various security-related projects.
(Log in to post comments)
GPLv3: a first look
Posted Jan 16, 2006 21:20 UTC (Mon) by Ross (subscriber, #4065) [Link]
Hmm. Yes, I can see another possible problem with this. What if some software under the new GPL is found to have a bug which unintentionally allows access to private information. Also, what about dual-use technologies like desktop sharing applications or tty spying utilities? Would that software now be undistributable? That seems to have some of the problems of the DMCA: you shouldn't attribute intent to tools.
I don't know how to separate bugs from spyware, but if it doesn't do so already that distinction should be made.
GPLv3: a first look
Posted Jan 17, 2006 17:27 UTC (Tue) by gravious (subscriber, #7662) [Link]
I don't know how to separate bugs from spyware, but if it doesn't do so already that distinction should be made.I dunno either but I'm guessing intentionality. Maybe that concept could be used.
As to the draft itself - I like it! It's bold, provocative, targeted. Someone mentioned that it is a bit terse. We need terse (as in a lack of ambiguity). If the poster meant terse as in a bit dry or humour-lacking then now is the time to humanise it. May I point out as well that if there are any areas of wording in the document that are causing a lot of argument peolple should remember that a clarification of any disagreements could lead to a tightening up of the language in the final draft. We need unity on this. Roll on January 2007!
encryption for authentication
Posted Jan 17, 2006 1:35 UTC (Tue) by stevenj (subscriber, #421) [Link]
It would be bad if, for example, the GPLv3 prohibited Gentoo's emerge from verifying the signatures on packages when the signing keys are kept secure.This point was apparently raised in the Q&A session, as recorded in Simon Phipps' blog. Both Eben Moglen and RMS indicated that such usages should be permitted, but RMS said that this might need clarification in the license and that concerned parties should submit a comment.
encryption for authentication
Posted Jan 19, 2006 8:28 UTC (Thu) by hingo (subscriber, #14792) [Link]
The difference here is:a) Gentoo can be configured to also accept the same package unsigned. In this case the Gentoo signature only provides authentication, the program will be installable and run exactly the same without it. This use is ok with the license.
b) I buy a PC or gaming console, which runs Linux (and Linux is now licensed gplv3 and not v2). I also get the sources to Linux and decide to have fun and make some hacks, then install my own version of the kernel instead. I now find that the console won't accept my version but refuses to run it. The error message implies that the exeutable has not been signed by a key that is needed. GPLv3 now gives me the right to get that key from the vendor i bought the console from, sign my own executable and use it.
This is clearly what is intended, and also how I read it. Of course, if others understand it diffetently.
encryption for authentication
Posted Jan 20, 2006 5:05 UTC (Fri) by zlynx (subscriber, #2285) [Link]
I'm not sure how the GPLv3 draft applies to it exactly, but I would say your case B should not be correct. You should not be able to demand the vendor's private key to sign your executable. Instead, you should be able to demand the ability to replace their key with your own, to run your software.
Under no circumstance should vendors be required to provide their private keys. They should not be required to give you access to their gaming networks with unsigned/incorrectly signed software. A hypothetical gaming console in your example should be able to be restricted to signed software to prevent cheating in multiplayer games.
Same with a cell phone. I argue that cell phone vendors should not be required to provide network access to unsigned software. The user should be able to install their own kernels and software, but that's it. The GPL effect should not extend into services beyond the device.
encryption for authentication
Posted Jan 20, 2006 6:18 UTC (Fri) by hingo (subscriber, #14792) [Link]
"Instead, you should be able to demand the ability to replace their key with your own, to run your software."Indeed, this is one way to fulfill the v3 requirements.
"Notwithstanding this, a code need not be included in cases where use of the work normally implies the user already has it."
It could perhaps be worded more broadly, but the intent is clear: You should make your drm'd device such, that the user is in control of it, then everything is ok. Obviously, if a manufacturer is required to distribute his own secret keys, they wouldn't be very useful anymore, since then they are not secret. But this is exactly what the FSF wants (I think, what do I know). You should make your devices such that the user has control over them, or go away.
In particular, If you distribute a game under the gpl, you cannot restrict access to a gaming server like you seem to want to do. Not because the GPL has any reach onto your gaming server, but because it would be technically impossible to do so when satisfying the v3 requirements. The user must be provided with everything needed to access the same features that he can with the binary only executable, and in this case it would include either the secret key or that the gaming server is conifgured to allow such things. I think it might satisfy the spirit of v3, if perhaps not the letter, if you'd do what you say, and give access to modified game clients to the server but label them with a tag that reveals to other players they are running a modified version, and thus may be cheating. Then people could choose whether they want to play with them or not.
Note that solving the problem of cheating with drm is security by obscurity, so it's the wrong solution anyway.
As for mobile phone networks, it's the same thing. Note that you can restrict who accesses the network with SIM cards and public key cryptography. You may even have that SIM card embedded in the phone (do they still do that in the US?) and the phone can use ROM memory, so the user cannot alter that particular phone, although he could get another phone (or ROM chip and replace it, if he knows how) and install his modified thing on that. For mobile networks the issue is even clearer: You should design the protocol such that it's secure and robust, not rely on a hope that nobody will ever try to do something bad with an "unaccepted" device. If you live in a country were a certain federal government only allows closed source radio equipment for safety reasons, too bad. But the gpl doesn't support that notion either. (liberty or death...)
encryption for authentication
Posted Jan 20, 2006 7:18 UTC (Fri) by zlynx (subscriber, #2285) [Link]
Now look, I don't have anything against the GPLv2 or v3. In fact, I think they're both great. However, I have a twisty mind that looks for the loopholes in everything. That's what I'm doing in this discussion, not arguing that the GPL is bad or anything like that.
Hmm. Section 5a of the GPLv3 says the modified work has to carry notices of the changes. Seems to me that it's reasonable to *enforce* through technical means (hardware encryption chips), the notice of software changes. (off topic, but in answer to your charge of security through obscurity: yes it is. It is so obscure that it requires an electron microscope to recover off the chip. This security is more secure than using passwords for authentication, and about the same as the codes embedded in those two-phase authentication keyfobs. In other words: pretty decent security.)
As long as the software functions as normal, and normal functioning includes carrying the software revision, the GPL terms are met.
Now, if third parties beyond the entity distributing GPL software look at those software revision codes and offer or deny service, what's the solution?
Those third parties could be individual gamers refusing to play against hacked clients, or VOIP services refusing to carry calls using modified software.
It seems that arguing that everyone has to provide service to modified code leads to the ridiculous assertion that RedHat would lose their GPL distribution rights if their network firewall refused to pass TCP/IP packets created by a modified GPLv3 OS kernel.
How about if the GPL distributing entity provided game server source, or cell phone network server source? In that way, the receiving entity would have all the parts needed to use their device as intended: as a client on a game network (but not a client on the MSN game network), or as a client on a cell network (but not as a client on the Verizon cell network).
It's all in the definition of the "principle context of use."
encryption for authentication
Posted Jan 20, 2006 10:02 UTC (Fri) by hingo (subscriber, #14792) [Link]
You make good points with your twisted mind :-)I think I mostly agree with you. At least if we think about the intent and also what is reasonable, I think it is fair to say that a drm scheme (known as trusted platform module) could be used to assert what version of a software is running, as long as it is possible to install modified versions which will be correctly identified as such.
Now, if that happens, I think it is reasonable to require, that the service provider who you got the gplv3 software from, cannot deny you some services because you modified the software. I say reasonable, because this is exactly the kind of thing the license is against. Obviously the license cannot require anything from third parties nor would it be reasonable. Therefore a third party may choose not to play with me or connect my VOIP client or whatever.
This is also how I read the license, but I am painfully aware of the fact that I don't possess a twisted lawyer kind of mind which is needed to find the kind of loopholes we are looking for.
encryption for authentication
Posted Jan 20, 2006 8:20 UTC (Fri) by xoddam (subscriber, #2322) [Link]
> In particular, If you distribute a game under the gpl, you cannot> restrict access to a gaming server like you seem to want to do. Not
> because the GPL has any reach onto your gaming server, but because it
> would be technically impossible to do so when satisfying the v3
> requirements.
I think this is entirely counterfactual. There is no good reason why
someone should not set up a server which will accept connections from
only an authorised version of a client. If people want to run some
*other* client, such as a modified version of the original, against
a game server then they have the freedom to set up their own server
instead.
> The user must be provided with everything needed to access the same
> features that he can with the binary only executable, and in this
> case it would include either the secret key or that the gaming server
> is conifgured to allow such things.
I don't think features provided by a remote network service which has not
been freely licenced for use with *any* client 'to all users who receive
a copy of the Program' can possibly be considered features of the Program
itself. It's not like the users have rights over the server.
You might as well say that if a bank provides a particular certified
version of a GPLed web browser to its customers for improved security
then it has some obligation to make sure its website is also usable with
browsers (say, a bleeding-edge version of the same codebase with new and
untested features enabled) that are known to have security flaws.
encryption for authentication
Posted Jan 20, 2006 10:17 UTC (Fri) by hingo (subscriber, #14792) [Link]
As I've replied above, I don't think the vendor selling the game has that liberty, because it would clearly go against the intent of the license. If it is allowed by the license, then it is a loophole.Note that this is for the cases when you buy a game and a subscription to some gaming service is included. Now, obviously it is possible for anyone to setup a server and configure it such that only certified versions of a client are able to connect. Note that there might be more than one certified version from more than one vendors/programmers.
Come to think of it, since we are talking about a game being distributed as gplv3, you'd be free to copy that came to as many consoles/pc you want to. In that sense I think the original vendor could argue, that he complies with the gpl, just that the drm/tpm scheme is to prevent cheating. (If drm is used to prevent copying of even an unmodified version, then you are clearly in breach of v3.) So maybe you are right and I'm wrong. To be on the safe side, the vendor could provide one server which will accept any connections and a "safe server" which only let's approved versions connect. "Normal people" would play on the safe server.
As for banks, I do not think banks should be allowed to restrict their clients to use only one specific browser. It is not the right way to achieve security in that case. The GPL is about giving power and choice to the user. The bank could warn the user about a known security flaw, even make it a bit unconvienient to use such a version, but the user should be left to make the decision. Note that the bank can protect itself no matter what browser you are using, and a bank should not be overly patronising if a user wants to do stupid things.
encryption for authentication
Posted Jan 30, 2006 21:46 UTC (Mon) by jharding (guest, #1102) [Link]
> There is no good reason why someone should not set up a server which will> accept connections from only an authorised version of a client. If people
> want to run some *other* client, such as a modified version of the
> original, against a game server then they have the freedom to set up their
> own server instead.
I agree completely. The same applies for movies that are "sold" encrypted: the decryption key could be sent only to verified ("trusted") clients, so in practice, the GPLv3 draft is not even close to avoid usage of DRM systems above which a user may run GPLv3 licensed software. The user could change the keys on the hardware and run any binary and even watch encrypted movies on his modified GPLv3 licensed program... provided he has the keys required to decrypt them (e.g. movies encrypted by himself).
This seems to be a real loophole in the GPLv3 draft.
encryption for authentication
Posted Jan 20, 2006 20:12 UTC (Fri) by spitzak (subscriber, #4593) [Link]
I'm quite certain the game provider is allowed to restrict their server to only the correct copies of the GPL3 game. What they can't do is prevent you from making your *own* gaming server and modifying the game to talk to it.