Weekly Edition
Return to the Front pageSponsored link
Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here.
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
GPLv3: a first look
The GPL is an important license. It is the most popular of free software licenses, and it covers many important components of a Linux system. It is a codification of the FSF's view of how free software should work, and it imposes some real obligations on those who redistribute GPL-licensed software. It is a core piece of our legal source code. So a major revision of the GPL requires a great deal of thought. In your editor's opinion, the FSF has put in that thought, and has put forward a revised license which meets current challenges while remaining true to the spirit of previous versions.
Digital restrictions management
Many of the changes in GPLv3 have to do with DRM schemes. The license makes the FSF's position on DRM quite clear, and does its best to ensure that GPL-licensed code will stay as far away from DRM as possible.
To start, the license makes its intent with regard to DRM clear:
The purpose here is to help ensure that, in any future court case, all of the terms of the GPL will be interpreted with an anti-DRM bias.
An interesting clause can be found in section 3:
This provision is clearly targeted at anti-circumvention laws. If it stands up, it says users can bypass any restrictions encoded in GPL-licensed software without circumventing "technological protection measures," since no GPL-licensed program can be part of such a measure.
Another key provision can be found in the revised definition of "source code":
In other words, "trusted computing" mechanisms designed to keep people from replacing the software on their gadgets cannot be used with GPLv3-licensed software. This is a large and important change - though its effect will be somewhat limited for as long as the Linux kernel remains licensed under version 2 of the GPL.
Software patents
As expected, the new version of the GPL addresses software patents in a much more comprehensive manner. One fundamental change is that anybody who redistributes software covered by the GPLv3 is explicitly granting all patent licenses needed to use the software. This grant covers "all versions of the covered work," and would seem to override the "field of use" restrictions imposed by some patent owners.
Here's an interesting addition in v3:
It is, of course, a patent retaliation clause. If you launch a patent suit against somebody using a specific program, you cannot make any further use of that program. It's a big departure from GPLv2; the previous version of the license imposed no restrictions on individual use of the software at all. With GPLv3, the right to use the software - not just to redistribute it - can go away as a result of filing a patent suit.
There are no other patent retaliation clauses in the GPL itself; the FSF is not entirely comfortable with this concept in general. From the rationale document:
There is, however, a subsection which allows the incorporation of additional, limited patent retaliation terms. Terms which take away use of the software for filing a wider range software patent lawsuits can be added:
So the GPLv3 does not include full-scale patent retaliation, but there should be enough there to get the attention of some types of patent holders.
Additional terms
A few other types of additional restrictions are allowed in GPLv3. These include limits on trademark use or the use of contributors' names for publicity purposes. The idea here was to try to make the GPL compatible with a wider range of free software licenses.
The much-discussed "web services loophole" is also addressed by way of an optional restriction:
Beyond that, version 3, like its predecessors, explicitly disallows the imposition of additional restrictions.
Other changes
Under version 2, termination of the license was automatic if its terms were violated. In theory, one who had gone against the GPL would have to go and explicitly beg forgiveness before being able to distribute the relevant software again. Back in 2000, Richard Stallman told the KDE developers that they had to ask forgiveness in this way. Version 3 changes the terms to put the onus on copyright holders to terminate a license. Any copyright holder can do so if the terms are violated, but a violator who mends his ways need not ask forgiveness from any copyright holder who has not exercised that right.
Version 2 contains a clause saying that, if a program cannot be distributed in a way which complies with both the GPL and any other restrictions (patent licenses in particular), it cannot be distributed at all. There has been some disagreement over just how strong that restriction is. GPLv3 makes it clear that a strong interpretation is expected; this section is now titled "Liberty or Death for the Program."
The geographical restrictions clause, which allows terms disallowing the distribution of code in certain countries due to legal problems there, has been retained in GPLv3. The rationale document states, however, that the FSF knows of no actual use of that clause, and they suggest it could be removed during the comment period.
There are many other changes, mostly aimed at clarifying intent and ensuring that the license is enforceable worldwide. Again, interested parties are urged to read the license itself and the rationale document for the full story. They will then be prepared to take part in the comment and revision process, which is expected to last for about one year. If all goes well, the FSF hopes to adopt GPLv3 in January, 2007.
(Log in to post comments)
Restrictions for use
Posted Jan 16, 2006 19:13 UTC (Mon) by proski (subscriber, #104) [Link]
The "patent retaliation clause" is not as strong as it looks. GPLv3 states explicitly that it's not a contact and that it doesn't need to be accepted to use the program. Therefore, the "patent retaliation clause" would only affect the ability to use the software by those who need to accept GPL for some other reason, such as the ability to distribute modified software.I think FSF did a great job with GPLv3. They resisted the temptation to add more restrictions to the license. On the other hand, they spelled the intentions of the license very clearly and strongly.
Although nobody is required to accept GPLv3 to use the software, I think large proprietary software houses would not be tempted to use GPLv3 covered software in violation of the license. Think of a PR disaster it would be if a large company was found using non-licensed software clearly in violation of the intentions of the copyright holders! They would look like "pirates" to the general public.
Restrictions for use
Posted Jan 16, 2006 19:21 UTC (Mon) by brouhaha (subscriber, #1698) [Link]
GPLv3 states explicitly that it's not a contact and that it doesn't need to be accepted to use the program. Therefore, the "patent retaliation clause" would only affect the ability to use the software by those who need to accept GPL for some other reason, such as the ability to distribute modified software.Note, however, that downloading the software over the internet or copying from one computer to another (internal distribution) still require permission or licensing from the copyright holder, thus the patent retaliation clause may in effect impose substantial restrictions on an entity's further use of the program. It doesn't affect any use that does not involve copying the program.
Restrictions for use
Posted Jan 17, 2006 9:02 UTC (Tue) by xoddam (subscriber, #2322) [Link]
Note that copying a program from disc to DRAM and from DRAM to processorcache *is* copying, technically speaking. While some countries have
'fair use' provisions in their copyright legislation (or case law),
others do not. A case can be made that without the implicit licence to
copy given by permission to 'use' a program, running it actually is
covered by copyright law.
Thus withdrawing permission to use a program is something a copyright
holder can effectively do in some jurisdictions. Copyright law can also
compel you to *destroy* unauthorised copies.
The same applies to the copies made of a web page when you read it: An
implicit permission to make a copy is granted by the server when you ask
for a copy. Theoretically this permission to copy could be withdrawn by
the copyright holder.
Restrictions for use
Posted Jan 17, 2006 15:19 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
If you get too technical, you'll also note that merely the act of disposing of the copyrighted material involves (oh no!) generating yet another temporary copy.
Not to mention that deleting a file does not actually remove its content from the storage. You can't tell exactly when nothing will be left of the content.
Restrictions for use
Posted Jan 20, 2006 1:54 UTC (Fri) by giraffedata (subscriber, #1954) [Link]
I think it's still highly speculative that copying code from disk to memory requires a license from the copyright holder. I've heard of rulings like this, but they seem pretty ignorant and I don't think they will hold up.I compare this kind of copying to copying a book onto my retina so that I can read it (you cannot read a book in the traditional way without causing an image of each page to appear on your retina).
ISTR some distinction about copying into fixed form vs ephemeral form, and that could easily apply to a DRAM copy, and even to a disk cache copy or local filesystem copy.
GPLv3: a first look
Posted Jan 16, 2006 19:22 UTC (Mon) by bjlucier (subscriber, #5281) [Link]
Some parts of the Lisp community have sensed the need to add clauses to the LGPL to make it more Lisp friendly, see the Lisp Lesser General Public Licence. I hope that, as computer languages adopt more of the dynamic features of members of the Lisp and Smalltalk language families, the [[L]L]GPL can be adapted to allay the concerns of some members of these communities.
GPLv3: a first look
Posted Jan 19, 2006 14:06 UTC (Thu) by rwmj (subscriber, #5474) [Link]
OCaml too. See the special exception at the top of:
http://caml.inria.fr/pub/old_caml_site/ocaml/LICENSE.html
The original LGPL says something to the effect that if you use
an LGPL library within your proprietary binary, then you must
provide an object code version of the same binary which can be
relinked against a newer version of the LGPL library. (Nothing
to do with revealing the source though).
But OCaml has type-safe linking which means that object files
provided like this would be essentially useless. Any, even minor,
change to the interface to the LGPL library would mean that
linking would fail. So this clause is usually omitted from
LGPL OCaml libraries.
Rich.
LGPL derivatives
Posted Jan 20, 2006 20:01 UTC (Fri) by spitzak (subscriber, #4593) [Link]
We also applied something like this to fltk (http://www.fltk.org/COPYING.php). Even in C++, supplying object files that can be relinked with the library is enormously hard to do and probably completely useless to anybody who wants to modify the library. It would be far easier for the user to tell the original author "can you please put this useful patch for fltk into the version you are using and send me a new compilation of the program". Also some claim that this requires dynamic linking, which would completley kill the main advantage of fltk, which is that programs using it don't have to be "installed" and the executable "just works".
In our version we tried to make it clear that modifying the fltk code itself and using that in your program requires you to give out the source code for your modifications.
As I have seen this done dozens of times, now including the Lisp and OCaml versions, I would really like to see a single *official* LGPL3 which rewrites or removes these "must supply linkable object code" restrictions. It is obvious that huge numbers of library implementors want to modify the library like this, and without an official version it is leading to huge numbers of slightly different, and possibly incompatable, licenses.
GPLv3: a first look
Posted Jan 16, 2006 19:27 UTC (Mon) by cventers (subscriber, #31465) [Link]
Janurary 2007? That's a long time to wait!I will say that I'm absolutely pleased with how this first draft is
looking (at least, after having read this article and the rationale
document).
If you don't like waiting, get involved
Posted Jan 19, 2006 4:54 UTC (Thu) by bignose (subscriber, #40) [Link]
This isn't a waiting period; it's a time for involvement by interested parties. That would seem to include you, if you're alarmed by how long you must "wait".
Don't wait! You're part of this process if you choose to be.
http://gplv3.fsf.org/comments/
system library exception
Posted Jan 16, 2006 19:30 UTC (Mon) by JoeBuck (subscriber, #2330) [Link]
It appears that they are also fixing the legal problem that makes Debian/Solaris distributions illegal (because the Solaris C library has a GPL-incompatible license).Currently, the exception that allows a binary of a GPL executable for Solaris to be distributed reads: "However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."
The killer is that last clause, and it appears that GPLv3 will fix this problem.
system library exception
Posted Jan 18, 2006 1:20 UTC (Wed) by drag (subscriber, #31333) [Link]
I think the Debian/Solaris problem is something that is inherent in Debian rather then in the GPL v2 license.
After all the original GNU software was developed on and binaries distributed for Solaris operating system.
I just think this GPLv3 just spells it out more plainly.
It's like the patent thing.. As I understand it there is a implied patent distribution rights with the GPLv2.. Basicly means that if you have a software patent and you develop software that utilizes this patented concept and you then distribute the software under GPLv2 software you can't then sue the people that use it. It won't stand up in court.
GPLv3 makes this statement outright to give it more force.
system library exception
Posted Jan 19, 2006 9:38 UTC (Thu) by nix (subscriber, #2304) [Link]
SunOS, actually. GNU *long* predates Solaris.
system library exception and derived works
Posted Jan 20, 2006 3:12 UTC (Fri) by xoddam (subscriber, #2322) [Link]
> I think the Debian/Solaris problem is something that is inherent> in Debian rather then in the GPL v2 license.
You can read some of the controversy here. There is a lot of
misunderstanding:
http://www.opensolaris.org/jive/thread.jspa?threadID=2189...
The Debian/Solaris problem is partly in the interpretation of the GPLv2
definition of "complete source code". If you distribute binaries, you
must provide *source* that is sufficient to modify and regenerate those
binaries. There is an exception for system components such as compilers
and standard libraries. There's also an exception to the exception: "...
unless that component itself accompanies the executable."
So the dispute is very much down to the interpretation of the language of
version 2 of the GPL. The language in this draft of version 3 is not
quite so ambiguous.
Note that the source of the CDDL libc *is* provided, just not under GPL
terms. So in order to complain about the licence incompatibility you
also have to take a pretty strict interpretation of what is a 'derived
work'. It all hinges on whether *each* of two components distributed
together and intended to be linked at runtime constitutes a part of a
work derived from *both*. The same issue arises in the distribution of
closed kernel modules together with a GPL kernel.
GPLv3: a first look
Posted Jan 16, 2006 20:14 UTC (Mon) by Lucas (subscriber, #31413) [Link]
Wow, the first draft has just seen the light, and you already post an anlysis of it.
That's what I'm proud of paying for :)
Patent grant -- Am I reading it right?
Posted Jan 16, 2006 20:45 UTC (Mon) by Ross (subscriber, #4065) [Link]
I'm looking at the "all versions of the covered work" commetary above. If I read that correctly, when a product under GPL is distributed by a company, and that product is later modified by another party so to use some patented method or structure, the original company now (kind of retroactively) grants a license if they have a patent on that method or structure in the modified product, not just for the technologies contained in the original.
While I don't have a big problem with this (because I don't like software patents), I could see this as being a major problem for tech companies adopting the new version of the GPL because basically any of their software patents can be freely licensed if that software is modified to use that technology.
Patent grant -- Am I reading it right?
Posted Jan 16, 2006 20:49 UTC (Mon) by JoeBuck (subscriber, #2330) [Link]
I believe that you are reading it wrong. Reading it as you do would allow anyone to gain access to any patent, if the patent holder ever distributed any GPLv3 work: just modify that work to add an implementation of the patent. Only the work as it was when distributed is covered.
GPLv3: a first look
Posted Jan 16, 2006 21:14 UTC (Mon) by iabervon (subscriber, #722) [Link]
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.
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.
Misunderstanding of embedded system designers
Posted Jan 16, 2006 22:01 UTC (Mon) by karim (subscriber, #114) [Link]
Clearly the FSF once again fails to understand the realities of
embedded system designers. Many embedded engineers have no love
for DRM, but must ensure that the products they build cannot run
anything but "authorized" applications in order to protect the
copyrighted material others will allow to play on their devices.
They don't personally own such material, and neither does their
company. They just need to build a product that protects the
belongings of others.
What this version of the GPL does, in as far as I'm reading it
right, is close an entire segment of computerized products from
software licensed under it -- and for the wrong reasons.
Fighting DRM is a worthy goal, and I do encourage the FSF's
strong stance on many issues, but they are wrong on this one.
Having this sort of provision will not free the engineers I
allude to above from having to meet a certain requirement. It's
their job and they will have to carry it out. What it will do
though is:
a) require those engineers to use proprietary software, which
-- as has been demonstrated time and again -- can put the user
at risk.
b) alianate those engineers from the free software community
by making their job much harder and ensuring that they cannot
justifiably contribute to free software projects as part of
their job.
Just my 0.02$
Karim
Misunderstanding of embedded system designers
Posted Jan 16, 2006 22:31 UTC (Mon) by cyd (subscriber, #4153) [Link]
Interestingly, there is a rather permissive new clause that seems relevant for embedded systems. Under "basic permissions":Propagation of covered works is permitted without limitation provided it does not enable parties other than you to make or receive copies. Propagation which does enable them to do so is permitted, as "distribution", under the conditions of sections 4-6 below.
I believe the GPLv2 didn't have such a clause. It seems to be saying that there is no need for the source to accompany the executable if the software is distributed in a system where the user can't copy it out, like a non-flashable chip in a toaster. I wonder if this is really the intention.
Misunderstanding of embedded system designers
Posted Jan 16, 2006 23:11 UTC (Mon) by alriddoch (guest, #2249) [Link]
The clause you quote includes the wording "... to make or receive copies". I think it is clear that when you distribute software on a non-flashable chip in a toaster, the user is receiving a copy, even though they are unable to make copies from it.
I believe this clause is intended to make it clear that copying the software between multiple systems, or from a CD onto your hard drive does not count as distribution, and thus does not require you to accept the license.
Misunderstanding of embedded system designers
Posted Jan 16, 2006 22:33 UTC (Mon) by foom (subscriber, #14868) [Link]
While it may be true that such embedded systems require that the user not be able to modify thesupplied system, such a requirement is directly in conflict with the FSF's goals.
The FSF is promoting Free Software -- that is, in their words "software that respects the user's
essential freedoms". One of those essential freedoms is the ability to modify the software. Providing
the source code for a system but designing the system such that the user cannot modify the code
makes it unfree. While the GPLv2 let you get away with this, the GPLv3 closes the hole, such that it's
no longer possible to subvert free software in this way.
It does not matter whether or not you *like* DRM, if you are designing a product that uses it, you
should not expect the FSF (and others who agree with them) to help you in that task any more than
if you were creating any other proprietary product.
Misunderstanding of embedded system designers
Posted Jan 16, 2006 23:44 UTC (Mon) by karim (subscriber, #114) [Link]
The folly of all great ideals is to blindely follow clearsuccesses with short-sighted and stuborn policies, thereby
forgetting the initial goal (communism vs. the peasants'
greater good, bureaucracy vs. having structured government
services, etc.)
I understand the FSF's intent. I just think that this is
the kind of thing that hurts the FSF's goal instead of
helping it.
Karim
Misunderstanding of embedded system designers
Posted Jan 17, 2006 0:49 UTC (Tue) by cventers (subscriber, #31465) [Link]
Karim,I have to disagree. I've just finished reading Stallman's "Free
Software, Free Society" lately (it's a collection of essays and speeches
he's done throughout the year).
When I saw the new GPL license draft, I felt very much like the FSF
was adhering to the principles on which it, and the free software
movement it advances, were founded.
By contrast, I think the accusation of "short-sighted and stubborn
policies" indicates a desire that they yield in some part of their core
mission. If I look at the landscape on which we now sit, I see the FSF as
being the organization responsible for maintaining the uncompromising
idealism on which our modern software society is now based. If someone
wants to make compromises, perhaps it can be OSI? (small jab :P)
Remember that no one has any 'duty' to support business with their
free software. The FSF, in its documents, makes this clear. However, they
do concede that once they satisfy freedoms, they can work to satisfy
business as well.
Just some random thoughts.
- Chase
Misunderstanding of embedded system designers
Posted Jan 17, 2006 9:34 UTC (Tue) by nix (subscriber, #2304) [Link]
I concur. I can see very little wrong with this GPL revision: I was fearing a repeat of the GFDL fiasco, but it seems my fears were unfounded. Bravo!
(Oh, and if there's one thing nobody can describe RMS as, it's `blind'. He's shown a consistent record over the last few decades of foreseeing threats to software freedom a decade or so before they become obvious to most people.)
Misunderstanding of embedded system designers
Posted Jan 17, 2006 6:56 UTC (Tue) by jae (guest, #2369) [Link]
The "folly" of all (great) ideals is that they have some "vision", and won't budge to short-sighted interests.
Fell free to take this as a flame if you want to.
Misunderstanding of embedded system designers
Posted Jan 16, 2006 22:36 UTC (Mon) by melevittfl (guest, #5409) [Link]
and
c) Will make systems that include DRM more expensive to build and more likely to be buggy.
This may lead to DRM-encumbered products costing more to consumers and proving less reliable.
This leads to consumers rejecting products that include DRM in favor of sticking to reliable technologies like CDs until such time the technology companies find their spine again.
Seems like this clause works for me.
Misunderstanding of embedded system designers
Posted Jan 16, 2006 23:19 UTC (Mon) by karim (subscriber, #114) [Link]
I disagree with your conclusion, but you're not entirely off track.
First, from what I have seen DRM is not going away any time soon.
Partly due to the fact that those producing copyrighted material
(i.e. the artists) have very little understanding of the technology,
its impact, and the rest, which makes them very easily convinced
that they must use every possible means to protect their turf. If
you can scare someone into believing that a foreigner (someone of
a different skin color, religion or -- closer to home -- more
technologically apt) will take away their bread and butter or
put their livelyhood in danger, you can bet they'll use every and
any possible means that this doesn't happen, including requiring
that those he entrusts his "work" to provide firm guarantees.
That's just human nature. And whether free software developers want
to allow developers caught in the crossfire to use a piece of
software or not won't really change much. DRM will remain until
the fear I describe above is present, there's nothing any
software license can do about it -- and that's partly why the
DRM clause in GPL3 is wrong.
You want to make DRM go away? Just don't buy DRM'ed material. It's
as simple as that. The one thing the "creators" will hate more than
the fear of not making money, is actually not making any.
Karim
Paraphrasing you
Posted Jan 17, 2006 4:30 UTC (Tue) by proski (subscriber, #104) [Link]
I disagree with your conclusion, but you're not entirely off track.First, from what I have seen spam is not going away any time soon. Partly due to the fact that those advertizing by the means of spam (i.e. those who hire spammers) have very little understanding of the technology, its impact, and the rest, which makes them very easily convinced that they must use every possible means to protect their turf. If you can scare someone into believing that a foreigner (someone of a different skin color, religion or -- closer to home -- more technologically apt) will take away their bread and butter or put their livelyhood in danger, you can bet they'll use every and any possible means that this doesn't happen, including requiring that those he entrusts his "work" to provide firm guarantees.
That's just human nature. And whether free software developers want to allow spammers caught in the crossfire to use a piece of software or not won't really change much. Spam will remain until the fear I describe above is present, there's nothing any software license can do about it.
You want to make spam go away? Just don't buy stuff advertized by spam. It's as simple as that. The one thing the "creators" of spam will hate more than the fear of not making money, is actually not making any.
Misunderstanding of embedded system designers
Posted Jan 17, 2006 18:33 UTC (Tue) by davecb (subscriber, #1574) [Link]
karim said:... those producing copyrighted material (i.e. the artists) have very little understanding of the technologyI'm one of those producers, and I and my (book) publisher found that free, non-DRM'd electronic distribution of our work drove book sales.
Baen has now followed O'Reilly in this, shipping completeley unrestricted PDFs of their back catalog with recent publications...
Some artists in the graphic and performing arts have seen this, though their publishers haven't
--dave
Misunderstanding of embedded system designers
Posted Jan 18, 2006 14:25 UTC (Wed) by nix (subscriber, #2304) [Link]
Baen has been doing this for a long time: I think longer than ORA. I have a book I bought in 2001 with a CD-full of other books at the back, in HTML and RTF...
Misunderstanding of embedded system designers
Posted Jan 16, 2006 22:39 UTC (Mon) by bk (guest, #25617) [Link]
Many embedded engineers have no love for DRM, but must ensure that the products they build cannot run anything but "authorized" applications in order to protect the copyrighted material others will allow to play on their devices.This sounds like a very oblique way of saying: "I am involved in the development of media player(s) that are locked down to prevent installation of anything other than factory-authorized firmware/software. This is so that the device can only be used with 'properly' restricted (DRMed) content."
Am I right? Can't your employer license some proprietary embedded OS for their locked-down device? Such development should be as difficult and expensive as possible, I see no reason to accomodate it with our free licenses.
Misunderstanding of embedded system designers
Posted Jan 16, 2006 23:06 UTC (Mon) by karim (subscriber, #114) [Link]
Please cut the us-vs-them crap and check who you're talking to first:http://www.oreilly.com/catalog/belinuxsys/
Being in my position, you kind'a meet a lot of people on both
sides of the fence, you kind'a see a lot of designs, and it kind'a
gives you a better view from a distance.
Coold heads (and philosophy 101) would tell you that making personal
attacks does not diminish your opponent's arguments.
And if I may suggest ... please don't present yourself in public
claiming to defend my view of software freedom.
Karim
Misunderstanding of embedded system designers
Posted Jan 16, 2006 23:11 UTC (Mon) by bk (guest, #25617) [Link]
In no way did I personally attack you. Nor did I question (or even bring up) your abilities or expertise in embedded design (thank you, however, for crudely insulting my philosophy erudition). Perhaps you should consider your own advice regarding cold heads.
Plaining speaking (rather than hiding behind mealy-mouthed apologetics) will make me respect your viewpoints more. All the publishing credits in the world won't change that.
Misunderstanding of embedded system designers
Posted Jan 16, 2006 23:27 UTC (Mon) by karim (subscriber, #114) [Link]
My publishing credits weren't meant to convince you of my viewpoint.
Rather, it was meant to demonstrate that there can be other reasons
for voicing an opinion that those you hinted at.
And no, you're right, I did not react with a cold head. It just
really gets to me when I see the kind of "us-vs-them" attitude. We
all have a responsibility for the greater good and we all have the
duty -- at least that's my belief -- to make an effort in
understanding others' viewpoints.
Karim
Misunderstanding of embedded system designers
Posted Jan 17, 2006 0:55 UTC (Tue) by cventers (subscriber, #31465) [Link]
"Us-vs-them" is looking at things the wrong way, I think. I could seesomeone using the same term to describe the fact that the GPL isn't
becoming, say, BSD-like in that it still doesn't allow Microsoft to link
parts of Linux into their proprietary Windows kernel.
If you're going to create a better world, you have to, at times, draw
lines in the sand. This is the difference between public domain and
copyleft.
Misunderstanding of embedded system designers
Posted Jan 19, 2006 20:40 UTC (Thu) by Fats (subscriber, #14882) [Link]
It's not "us-vs-them". What you say is that it is OK to have somebody make a device running a linux kernel but I can't compile a new kernel for that device and run it with the new code. This just doesn't feel right to me and I agree with RMS on this one (which doesn't happen that often). People who don't want to allow that should not use GPL software for their kernel.
Misunderstanding of embedded system designers
Posted Jan 16, 2006 23:40 UTC (Mon) by bronson (subscriber, #4806) [Link]
Take a few breaths, bk. There's enough hypocrisy in this thread for everybody.I see no reason to accomodate it with our free licenses.
"our"?
Misunderstanding of embedded system designers
Posted Jan 17, 2006 9:43 UTC (Tue) by nix (subscriber, #2304) [Link]
'Free licenses that are better than anything I could have written and that I wholeheartedly support'.
I use 'we' that way too, quite often. Perhaps it's a bit mendacious. :/
Misunderstanding of embedded system designers
Posted Jan 19, 2006 10:37 UTC (Thu) by jschrod (subscriber, #1646) [Link]
OK, so you think you're famous because you're active in the Embedded Linux area and have written an ORA book.
Does that make your view right by means of `I am better than you'?
From my impression, bk attacked your viewpoint. As a reaction, you attack him personally and don't answer his actual points factually. And then you advise him to have `coold[sic!] heads'. Well, cold heads, indeed.
This is just a feedback that you know how that exchange looks to others.
Cheers, Joachim
Misunderstanding of embedded system designers
Posted Jan 19, 2006 18:17 UTC (Thu) by karim (subscriber, #114) [Link]
Please go back and read the exchange.
His initial post clearly questioned my motivations, insinuating that
my viewpoint was tainted by my work. Like you, he thought my mention
of my book was meant to convince him of my viewpoint. It wasn't. As
I pointed out to him, the main goal was to show that there can be
other motivations for defending a viewpoint. If you'd care to follow
the thread, you would've also seen that I did ack my hot-head comments
... everyone's got his buttons ... some of us are self-aware, others
are less so inclined ...
Karim
Misunderstanding of embedded system designers
Posted Jan 16, 2006 23:40 UTC (Mon) by JoeBuck (subscriber, #2330) [Link]
You are correct that the FSF intends not to support the particular set of embedded systems designs you describe (those that implement DRM). If the free software developer community accepts this concept, then yes, it is true that engineers that have the job of building such systems will have to either write their own software, or buy proprietary software. And that's OK: the free software world doesn't owe these people any free help.But systems that include DRM are currently a very small subset of all embedded designs. Most embedded systems could continue to use GPLv3 code.
The terms you use ("They just need to build a product that protects the belongings of others") suggest that you're taking the DRM side in the coming war, and that you aren't just a neutral open source journalist. DRM protects "rights" that copyright holders do not have, by, for example, making it near-impossible for scholars and reviewers to include portions of the work in their reviews, a fair use right protected by law. They also protect unilateral take-aways of user rights, as restrictions are added to works that weren't in place when the customer paid for the right to enter the DRM jail.
Maybe we'll see a split among the Linux kernel developers on this issue: many hate DRM, others (like part of the audience for your book) may be eager to build DRM systems out of free software. We'll see.
Misunderstanding of embedded system designers
Posted Jan 17, 2006 0:04 UTC (Tue) by karim (subscriber, #114) [Link]
First, I would like to say that I contest the idea that DRMed systemsare but a subset of devices out there. I would say, in fact, that
DRM is increasingly found everywhere. Heck, some would even like us to
watch TV on our cell phones ... In as far as "consumer devices" go,
then for sure they're all on the DRM road already in some way, shape,
or form. What portion "consumer devices" has in "embedded devices"
is another debate altogether. Not that other "embedded devices", such
are your car's brake controller, don't need to be "protected" from
the person receiving the software (i.e. the consumer).
With regards to the cause of DRM, I'm really not much of a conspiracy
believer. The reason DRM can fly is because someone, somewhere is
afraid he'll stop making money. Whether others retrofit this to other
uses, including some which you hint at, is another issue altogether.
Note that I don't believe the latter could hold if the former did not
exist.
In as far as my position goes vis-a-vis DRM, please read my other
posting which explains the real thrust behind DRM. If you want to
kill DRM, then don't by DRM'ed products.
Karim
Getting embedded system designers fired
Posted Jan 17, 2006 0:28 UTC (Tue) by man_ls (subscriber, #15091) [Link]
So some engineers waste their time and efforts building stupid restrictions into devices. So for some reason (other than avoiding crappy hardware) we should care about them by making their jobs easier; and then altogether getting them fired by not buying the result of their work.Sorry, but I don't feel that way about members of the free software community. Either I want to help them, and then I want them to have good jobs; or I don't want them in the community. In my case, I don't want free software near e.g. the nauseating LIBRIe. It would give people the wrong message about free software and copyrights: that sharing information is wrong.
[OT] Librie
Posted Jan 18, 2006 9:39 UTC (Wed) by ikm (subscriber, #493) [Link]
Librie was "liberated" by SONY long ago -- by providing all the tools to produce unencumbered texts -- apparently after they have found no one bought the device without it.
Misunderstanding of embedded system designers
Posted Jan 17, 2006 5:14 UTC (Tue) by akumria (subscriber, #7773) [Link]
"If you want to kill DRM, then don't by [sic] DRM'ed products."
You suggestion only addresses the demand side of the problem. Yes, once manufacturers realise that people don't demand DRM they will stop bundling it.
Another mechanism to slow-down DRM is to look at the supply side of the problem. The intent is to make it more expensive to develop products which have DRM in then.
Hopefully entertainment expenditure is price elastic, in that as the price of entertainment (and associated equipment) rises less people purchase it. When manufacturers see less demand (because things are now more expensive) they are less likely to continue producing those items.
If we want to counter DRM successfully I think it is vital to address both the demand and the supply side of things.
Misunderstanding of embedded system designers
Posted Jan 17, 2006 13:41 UTC (Tue) by RobSeace (subscriber, #4435) [Link]
> I would say, in fact, that DRM is increasingly found everywhere....
> If you want to kill DRM, then don't by DRM'ed products.
Sounds like some kind of cognitive disconnect... If it's everywhere, then
how can we avoid buying it? Unless you suggest we not buy ANYTHING?? And,
that's not a very realistic suggestion, of course... So, either your first
statement above was extreme hyperbole or your "Just don't buy it!" strategy
isn't very realistic/effective... I tend to suspect a bit of both... But,
I think your first statement is indeed indicative of where things are
headed, even if we're not quite there yet... So, in such a world, I think
we need to find a much more realistic and effective method of killing DRM
than simplistically saying "Just don't buy it", something which is being
made increasingly impossible to do...
Misunderstanding of embedded system designers
Posted Jan 17, 2006 9:47 UTC (Tue) by nix (subscriber, #2304) [Link]
Furthermore, of course, even if the DRM vendors were trying to protect fair use rights and the like, they couldn't. It is impossible to build DRM that constrains users in one country to obey that country's laws without constraining users in other countries more than their law allows, and some countries have laws that vary dependent on your intent when copying, or even on your profession. There's no way that any software could verify that.
(of course IANAL, I just typed stuff up for them and am related to some)
Misunderstanding of embedded system designers
Posted Jan 17, 2006 0:13 UTC (Tue) by nchip (guest, #13292) [Link]
FSF just wants to close the "Device will only boot the that is signed with Key X" loophole. Embedded engineers could reap the fruits from Free Software movement, while deny access to same fruits to end-users. They distribute the source code of their kernel as GPL requires in word, but fail the spirit - user can build their own kernel, but it will not run on the device.
There is better ways out, for example having a "official key" that can decrypt the DRM codecs and can be used to verify that only authorized apps are running. And the provide with GPL sources a "GPL key" (GPL3 allows different keys), that allows using the hardware with any code of will, but can't decrypt DRM codecs (which aren't free software anyway).
Of course, currently Linux has GPL-2 only code, so your worries are not current yet. You still have time to convinience kernel developers that they should not relicense those parts to GPL >= 2. Unfortunatly there is not much evidence that engineers of DRM-restricted Linux systems have brought important features to mainline kernel...
Now to more philosophical matters: where are we actually going? Users despice DRM-locked hardware (see the bad press every time TiVo bends over and makes something a bit more restricting). Users are increasingly going to HTPC's because provide more freedom - ironically often to Microsoft Media Center. Will PC's get similar "authorized applications only" policy as media producers enforce now on embedded makers? Or will PC's replace restricted embedded devices completly? First Choice is bad for Embedded Linux engineers. Second is really bad for everyone. And BOTH of those might happen!!
Misunderstanding of embedded system designers
Posted Jan 17, 2006 1:52 UTC (Tue) by karim (subscriber, #114) [Link]
Well, if we're going to discuss "other ways" of doing DRM, here's a basicexample applied to the kernel (not that the kernel developers have
agreed to use GPL3 for the kernel, but just for the sake of argument):
Prior to booting kernel, let the firmware verify the kernel's signature.
Whether or not the signature is valid, boot the thing. But, if it isn't
valid, lock up or disable or just don't enable those hardware components
that control access to the "stuff" -- and do this in a way that requires
a hard reset for another pass at lock/don't-lock. Then package all the
proprietary/DRM software into individual applications. So everything just
runs as normal up to the time these apps try to access the hardware,
and now because it's disabled, the device is useless.
Using the words of the draft, there are no codes for you to "install and/
or execute" the work. In fact, you're free to install and execute any
kernel you wish. Plus, the kernel's "functioning in all circumstances is
identical". It's just that hardware beneath it just doesn't work any more,
and that, consequently, the proprietary applications running on top can't
do anything because the hardware is disabled.
There you have it, GPL3-compatible DRM -- to the best of my understanding
of course, and mind you I'm not a lawyer.
Again, fighting DRM is a worthy goal, but this is the wrong venue.
Karim
Misunderstanding of embedded system designers
Posted Jan 17, 2006 7:11 UTC (Tue) by foom (subscriber, #14868) [Link]
I think it is clear that the GPL can only protect the works that it covers. So, if you can fully use thehypothetical GPLv3'd kernel but some proprietary app is protected by DRM, there can be nothing
wrong with that. Yes, you cannot use the proprietary application, but, you must be able to fully use
everything on the system protected by the GPL.
However, note one further wrinkle. Let's assume that there will be an LGPLv3 similar to the current
LGPL + GPLv3 changes. Then, said proprietary app must allow the replacement of LGPL'd
subcomponents and still function. Such as...GNU libc. So, you can build your proprietary app with a
DRM checksum, but, I have to be able to replace the GNU libc and have the app still function.
Of course, you can build your app without libc, too...
Misunderstanding of embedded system designers
Posted Jan 17, 2006 8:22 UTC (Tue) by phip (subscriber, #1715) [Link]
It may be a small victory, but at least the pre-boot firmware could not be derived from free (GPL3) signature-checking code.
Another small benefit is it makes life more difficult for developers of locked-down hardware. They need to pay careful attention to how the lock-down is implemented to avoid violating the license, and if they slip up, it will be clear that they had every intention of violating the spirit of the license, even if the violation of the letter may be accidental.
Every little bit helps.
-Phil
'cannot be part of an effective prevention measure'
Posted Jan 18, 2006 0:54 UTC (Wed) by xoddam (subscriber, #2322) [Link]
That use case would be compatible with this draft of the GPLv3, yes.Thankyou for pointing out the loophole; the final licence may close it.
Supposing some OS kernel is licensed under a GPLv3 which retains this
loophole and used in a system such as you describe -- the GPLv3 kernel is
constrained not to be part of an 'effective prevention measure', meaning
that it is explicitly permitted to use the kernel (modified or not) as a
tool to reverse-engineer the DRM-enabled firmware, devices and
applications.
An OS kernel is fairly well positioned to do this job. I think DRM
device developers would be best advised not to use a GPLv3 kernel.
'cannot be part of an effective prevention measure'
Posted Jan 18, 2006 16:23 UTC (Wed) by karim (subscriber, #114) [Link]
FWIW, you'd be amazed what can be done by a piece of
hardware. So a scenario where the hardware has a latch
that can only be set once until hard-reset or power
down is very possible. Whether you can get the OS to
boot or not, and regardless of what that OS tries to
do, that hardware won't change state ... that's one
thing that's nice about hardware, you actually get to
control what software can and cannot do ...
Karim
'cannot be part of an effective prevention measure'
Posted Jan 20, 2006 3:24 UTC (Fri) by xoddam (subscriber, #2322) [Link]
> Whether you can get the OS to boot or not, and regardless> of what that OS tries to do, that hardware won't change state ...
So I fisrt boot the unmodified, signed kernel to which I have the source
(six months behind the current free version) and have the hardware fully
enabled. Now I use some kernel exploit (reported and promptly fixed some
time in the last six months) to kexec an updated kernel, configured as I
please. Voilą! I 0wn my own box.
'cannot be part of an effective prevention measure'
Posted Jan 20, 2006 3:48 UTC (Fri) by karim (subscriber, #114) [Link]
Ah ... yes ... thanks for bitting ... At last someone stepsup to the challenge ;D
It's worthy to note that the problem you allude to is
something a designer of such a system would absolutely need
to catter for even today. IOW, this is not an unknown issue.
Think no glibc ... think selinux ...
Not that it's easy to get it right. The hacks we've seen on
some consoles are based on similar ideas ...
Karim
'cannot be part of an effective prevention measure'
Posted Jan 20, 2006 8:04 UTC (Fri) by xoddam (subscriber, #2322) [Link]
"the problem you allude to"There's a problem? I'm not alluding to a problem, I'm working out how to
exercise my rights under the GPL :-)
I understand that if I receive a box with a differently-licenced
operating system then such exploits may violate the DMCA and its
equivalents in countries (such as my own) which have free-trade
agreements with the USA. The purpose of the DRM clause in the draft
GPLv3 is to ensure that GPL software is not used to take away the rights
of its users to use the software as they please.
Given that there is no GPLv3-licenced kernel, and that if there ever is
one it is not likely to be used inside such restricted devices,
*somebody* has to break bad laws and put up a spirited defence to them in
court or a time will come when they are considered normal and therefore
proper.
Misunderstanding of embedded system designers
Posted Jan 19, 2006 9:12 UTC (Thu) by hingo (subscriber, #14792) [Link]
In contrast with other commentors, I'm not at all convinced your scenario is allowed by this draft of v3. It seems that that kind of thing is exactly what it tries to prevent and in my opinion there is no loophole: If the key the manufacturer possesses is needed to use features of the hardware, and features can't be used without it, then it is part of the source code. If your interpretation was correct, one could ship binary-only kernel modules by saying "sure, you can do whatever you want with the kernel sources, you just won't have wireless lan (or whatever) anymore. The hardware will boot the kernel, just with less features."Now on the other hand, it is true that you could make an embedded Linux device and install non-gpl applications on it (Real Player, even Wine + MS Media Player in theory at least) that do the DRM in userspace. That is not forbidden, although such drm won't last very long. Fortunately!
Misunderstanding of embedded system designers
Posted Jan 19, 2006 15:08 UTC (Thu) by karim (subscriber, #114) [Link]
Are you telling me that in your view a software license can actuallydictate a hardware license?
Sorry, as a software publisher you have the right to dictate how
your work is being used, not other people's work -- lest you are
telling me that the GPL3 is a DRM tool itself.
Given that the kernel is not touched in any way and that no part of
it is implementing the software-side of the DRM, there is nothing
that precludes a designer to control the layer beneath the kernel
(i.e. the hardware) and the layer that's over the kernel (i.e. his
applications) as he sees fit. In fact, I'm pretty sure (though I'm
not a lawyer and this is not legal counsel) that if you did try
what you allude to -- using the kernel to circumvent the user-
space DRM -- you'd probably fall under the DMCA ...
Have all the fun you want, but this isn't a loophole, it's just
something the GPL cannot, to the best of my understanding, legally
cover.
Karim
Misunderstanding of embedded system designers
Posted Jan 19, 2006 20:52 UTC (Thu) by Fats (subscriber, #14882) [Link]
"Sorry, as a software publisher you have the right to dictate howyour work is being used, not other people's work -- lest you are
telling me that the GPL3 is a DRM tool itself."
You distribute the GPL3 code with the hardware. If you do something in the hardware that is incompatible with the GPL3 license of the software there is a provision in the license that forces you to not distribute the GPL3 software. You are free to distribute the hardware but not the accompanying GPL3 software. Don't know if this applies to this specific case though.
Misunderstanding of embedded system designers
Posted Jan 19, 2006 23:12 UTC (Thu) by im14u2c (subscriber, #5246) [Link]
Huh? How can the GPL say "You are not allowed to design hardware or software that recognizes only a single binary compilation of this program code."
That simply doesn't make sense. What if I wanted a Linux Security Module that verified all binaries on a system against a write-protected set of binary signatures, to verify no one's intruded on my system? Are you saying I can't do that for GPLv3 programs? That simply makes no sense.
The GPL doesn't say you can't design anything.
Posted Jan 20, 2006 3:28 UTC (Fri) by xoddam (subscriber, #2322) [Link]
The GPL does say you can't sell a version of GPLd software that is notmodifiable by the end-user. Draft GPLv3 says that if you need to sign
the software to run it, you must also provide the necessary key to the
end user -- it is considered part of the source code, and properly so.
Misunderstanding of embedded system designers
Posted Jan 20, 2006 6:36 UTC (Fri) by hingo (subscriber, #14792) [Link]
You mean you have take a hash of the final executable and the hardware will only run that and nothing else? I'm not sure on this one, but that may in fact be allowable (there is no secret key to give away, so you have given the user everything there is). It may not be very wise however, because if there is a bug in your software you cannot update it anymore, you'd have to replace the entire device. (If there is a non-hardware way to update it, the license requires you to provide the user with that mecanism.)Therefore the wiser thing to do is what Karim above wants to do, have the firmware check whether the executable is signed with a particular key. This way you can later produce updates and sign them. On this issue the v3 is very clear. You have to either a) provide the user with the secret key needed, or (more likely) b) enable the user to alter the device such that he can use another key of his own without losing any functionality because of that.
While I'm writing here, I'll reply to Karim as well: Obviously, the GPL cannot dictate the hardware license. You can build such hardware if you want, and if your software is GPLv3 you'll have to include the secret key. Sorry boy, you are just worng and confused, and you should let go already. (For the benefit of everybody, I don't intend to continue this thread although I fully expect Karim will do so.)
Misunderstanding of embedded system designers
Posted Jan 20, 2006 20:50 UTC (Fri) by karim (subscriber, #114) [Link]
Feel free to paint my position in whichever color makes you feel better. But here's the quote from the license:"Complete Corresponding Source Code also includes any encryption or authorization codes necessary to install and/or execute the source code of the work, perhaps modified by you, in the recommended or principal context of use, such that its functioning in all circumstances is identical to that of the work, except as altered by your modifications."
And what I suggest does exactly that. The kernel's behavior hasn't changed, its functioning is identical. It's the hardware beneath that isn't functioning the same way from the point of view of the user space applications accessing it ...
If confusion there is, I don't believe it's on my side.
Karim
Misunderstanding of embedded system designers
Posted Jan 17, 2006 14:43 UTC (Tue) by Los__D (subscriber, #15263) [Link]
If they make their own software semi-proprietary (By making it impossible to replace it in the system), then they might as well use proprietary tools.
We don't want to bring free software to DRM handicapped platforms, we want DRM handicapped platforms to either go away completely, or keep the hell away from the free software!
Misunderstanding of embedded system designers
Posted Jan 19, 2006 11:51 UTC (Thu) by ohanssen (subscriber, #2761) [Link]
There may actually be another reason for restricting replacement of software components, than DRM: Security, and control of our own computers.
I am of course against the spirit of DRM. However, I want freedom to control what software are allowed to be installed an run on *my* computer, and what that software are allowed to do. I dont want Sony CDs to install hidden rootkits. I want to give unsigned and unauthorised applets from the web, only very limited access to my system.
Misunderstanding of embedded system designers
Posted Jan 19, 2006 20:50 UTC (Thu) by Los__D (subscriber, #15263) [Link]
That doesn't change that the software should be replacable by the user...
We already have standard, and completely open systems for that, i.e. Unix authentication and authorization.
Misunderstanding of embedded system designers
Posted Jan 17, 2006 18:46 UTC (Tue) by jpick (subscriber, #29470) [Link]
My current employer is in the same boat. They will not be able to use GPLv3 code in their Linux-based settop box.
The FSF knows what it is doing. That's the intent of the license. I'm quite happy to see them taking on this battle.
If the Linux kernel goes to GPLv3, I'm sure somebody will maintain a GPLv2 fork. And embedded developers may look towards NetBSD or other projects with less restrictions.
The net effect of this is that it's going to be a bit trickier to build a DRM product from open source components. Many free software developers will now choose to not allow their code into DRM products.
Misunderstanding of embedded system designers
Posted Jan 19, 2006 14:18 UTC (Thu) by rwmj (subscriber, #5474) [Link]
Good. I wrote some of that GPL code, and I resent you ripping it of in such foolish and unfriendly schemes as DRM. When my code moves to GPL3, you won't be able to use it (or at least not the latest, bug fixed, optimized, featureful version), and I'll be very glad.
Rich.
Misunderstanding of embedded system designers
Posted Jan 18, 2006 7:27 UTC (Wed) by opennw (subscriber, #29001) [Link]
Hi Karim,
> Clearly the FSF once again fails to understand the realities of
> embedded system designers.
I would consider that Richard feels particularly strongly about embedded devices, since the original catalyst for the GNU project was a printer for which he couldn't get free source:
http://www.gnu.org/gnu/thegnuproject.html
> What it will do though is:
> a) require those engineers to use proprietary software, which [...]
> can put the user at risk.
> b) alianate those engineers from the free software community
Exactly, but you make it sound like it's a bad thing. "Sorry, our insecure DRM-using product was late because we couldn't find engineers to work on it".
Meanwhile a GPLv3 non-DRM product takes the market.
Mitch.
Misunderstanding of embedded system designers
Posted Jan 18, 2006 16:34 UTC (Wed) by karim (subscriber, #114) [Link]
I would love to be able to post a private exchange I hadwith Richard a few years back, but it's private, so I
won't. But it does clearly demonstrate the inverse of
your first statement.
Frankly, and again I can't go into too much detail, it
looks pretty clear to me that the FSF's realization that
embedded systems are an issue is only recent, and that
there hasn't been as much contact between their efforts
and a community of embedded system developers (as opposed
to their involvement in many efforts which have to do
with workstations and servers) -- yes, I'm aware GCC has
been cross-compiling for a while, but that's different
than having the actual software run on the gizmo ...
Karim
Misunderstanding of embedded system designers
Posted Jan 19, 2006 9:16 UTC (Thu) by hingo (subscriber, #14792) [Link]
Actually, I've always thought the "control program" of that printer refers to it's drivers or some other program used on the computer side, not some embedded code in the printer. I could be wrong of course.
Irrelevant
Posted Jan 19, 2006 21:00 UTC (Thu) by tjw.org (subscriber, #20716) [Link]
Clearly the FSF once again fails to understand the realities of embedded system designers.We all know that embedded system designers will go on ignoring the GPL regarless of what new clauses it has.
GPLv3: a first look
Posted Jan 17, 2006 0:14 UTC (Tue) by aigarius (subscriber, #7329) [Link]
Here is my take on the draft. I think there are some important problems that I think should be adressed.http://aigarius.blogspot.com/2006/01/ok-i-read-first-gplv...
Honest question
Posted Jan 17, 2006 7:24 UTC (Tue) by man_ls (subscriber, #15091) [Link]
If you don't take the time to summarize your point of view right here on LWN, why should we bother to visit your blog?
Honest question
Posted Jan 17, 2006 13:02 UTC (Tue) by bronson (subscriber, #4806) [Link]
I think there are some important problems that I think should be adressed.Isn't that a one-sentence summary?
Honest question
Posted Jan 17, 2006 13:43 UTC (Tue) by man_ls (subscriber, #15091) [Link]
A bit on the terse side. What are those crucial problemas that only aigarius could see? How do we know that it is not just some guy wanting to boost his Google advertising account?
Honest question
Posted Jan 17, 2006 17:04 UTC (Tue) by aigarius (subscriber, #7329) [Link]
Hmm, i tried not to spam the comments with a quite lengthy dump of my thoughts, so if someone cares to read them, he can go to the page. I have also submitted my concerns to the FSF at the comment page.
As for the AdSence - everyone by now should know that advertisers get nothing unless the ad is actually clicked, so there is no sence of just hoarding traffic with Google Ads.
Honest question
Posted Jan 19, 2006 17:35 UTC (Thu) by man_ls (subscriber, #15091) [Link]
And how, pray, do you intend people to click on the ads if they don't visit your blog in the first place?I didn't ask for a lengthy dump, just the basic ideas. But suit yourself.
GPLv3: a first look
Posted Jan 17, 2006 9:05 UTC (Tue) by russell (subscriber, #10458) [Link]
What would happen in this scenario.
1. Company X produces a program and releases under GPLv3
2. Company Y adds a feature for which company X has a patent.
3. Company X then sues company Y for patent infringement
4. Company X looses the right to distribute it's own program ??? Company X probably can't sue because that would destroy it's own business?
GPLv3: a first look
Posted Jan 17, 2006 11:00 UTC (Tue) by ronaldcole (guest, #1462) [Link]
Company X rips the GPLv3 sticker off of the work to which it owns the copyright and slaps another license sticker on it. The copyright owner has always had the right to choose which license he licenses his copyrighted work with. Ghostscript is an old but useful and legal example of this activity.
GPLv3: a first look
Posted Jan 18, 2006 0:07 UTC (Wed) by russell (subscriber, #10458) [Link]
What if company X was not the only contributor. They couldn't then change the license without the permission of others. It would mean the death of the program. Possibly deliberately by a hostile company Y
GPLv3: a first look
Posted Jan 19, 2006 1:03 UTC (Thu) by hazelsct (subscriber, #3659) [Link]
Sounds like you're saying that effectively Company X, by releasing any GPLv3 code, effectively loses any right to enforce any patent which derivatives of the GPLv3 code might infringe. I don't think that's quite what's meant by "all versions", but you just might be right...Then again, though it's a bit strong, it is in general alignment with the "no software patents" stance of its authors. :-)
GPLv3: a first look
Posted Jan 19, 2006 3:24 UTC (Thu) by russell (subscriber, #10458) [Link]
It's true that it may be inline with the "no software patents" stance, but it also conflicts with the "do no harm" goal of GPLv3. After all companies are users as well, and the company being penalised is a free software contributor.
Patent infringement
Posted Jan 19, 2006 17:45 UTC (Thu) by man_ls (subscriber, #15091) [Link]
The publishing company is not penalised unless they actively try to enforce their software patents. The only penalised party is the receivers of the lawsuit. The explicit goal of the FSF here is to avoid people actually using their software patents; it doesn't matter if it is a free software contributor since such patents are immoral and should not be used in any context.Suppose Red Hat (actually holding many software patents I believe) publish a program, and Novell add a feature. If Red Hat were to sue for patent infringement, they have clearly crossed the line. Now, if if you talk about countersuits it gets interesting.
Red Hat holds a lot of defensive patents. Suppose Evil Company X sues them for patent infringement, and Red Hat countersues using a special patent. Now ECX can put out a version of RHEL making obvious use of the patent, and unless Red Hat avoids suing for that particular use they lose the right to distribute RHEL. Remember that Red Hat is just using their defensive patents in the way they were supposed to be used, but ECX can trick them into losing distribution rights for the software.