Weekly Edition
Return to the Front pageRecent Features
| |||||||||||||
GPLv3: a first look
The Free Software Foundation has, at last, made a draft version of version 3 of the
General Public License available for comments. Your editor, having
read it five minutes ago, is now ready to comment. What follows is a quick
overview of the changes which have been made to the GPL; anybody wanting
more information should certainly read the accompanying rationale document, which
describes the changes - and their motivations - in detail.
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 managementMany 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:
As a free software license, this License intrinsically disfavors
technical attempts to restrict users' freedom to copy, modify, and
share copyrighted works. Each of its provisions shall be
interpreted in light of this specific declaration of the licensor's
intent. Regardless of any other provision of this License, no
permission is given to distribute covered works that illegally
invade users' privacy, nor for modes of distribution that deny
users that run covered works the full exercise of the legal rights
granted by this License.
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:
No covered work constitutes part of an effective technological
protection measure: that is to say, distribution of a covered work
as part of a system to generate or access certain data constitutes
general permission at least for development, distribution and use,
under this License, of other software capable of accessing the same
data.
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":
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. It also includes any decryption codes
necessary to access or unseal the work's output.
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 patentsAs 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:
This License gives unlimited permission to privately modify and run
the Program, provided you do not bring suit for patent infringement
against anyone for making, using or distributing their own works
based on the Program.
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:
Several other free software licenses include significantly broader
patent retaliation provisions. In our view, too little is known
about the consequences of these forms of patent retaliation.
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:
They may impose software patent retaliation, which means permission
for use of your added parts terminates or may be terminated, wholly
or partially, under stated conditions, for users closely related to
any party that has filed a software patent lawsuit (i.e., a lawsuit
alleging that some software infringes a patent). The conditions
must limit retaliation to a subset of these two cases: 1. Lawsuits
that lack the justification of retaliating against other software
patent lawsuits that lack such justification. 2. Lawsuits that
target part of this work, or other code that was elsewhere released
together with the parts you added, the whole being under the terms
used here for those parts.
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 termsA 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:
They may require that the work contain functioning facilities that
allow users to immediately obtain copies of its Complete
Corresponding Source Code.
Beyond that, version 3, like its predecessors, explicitly disallows the imposition of additional restrictions.
Other changesUnder 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
But OCaml has type-safe linking which means that object files
Rich.
LGPL derivatives Posted Jan 20, 2006 20:01 UTC (Fri) by spitzak (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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
They don't personally own such material, and neither does their
What this version of the GPL does, in as far as I'm reading it
Fighting DRM is a worthy goal, and I do encourage the FSF's
Just my 0.02$
Karim
Misunderstanding of embedded system designers Posted Jan 16, 2006 22:31 UTC (Mon) by cyd (guest, #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
It does not matter whether or not you *like* DRM, if you are designing a product that uses it, you
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
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.
That's just human nature. And whether free software developers want
You want to make DRM go away? Just don't buy DRM'ed material. It's
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
Coold heads (and philosophy 101) would tell you that making personal
And if I may suggest ... please don't present yourself in public
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.
And no, you're right, I did not react with a cold head. It just
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
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
In as far as my position goes vis-a-vis DRM, please read my other
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
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.
Using the words of the draft, there are no codes for you to "install and/
There you have it, GPL3-compatible DRM -- to the best of my understanding
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
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 (guest, #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
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
Think no glibc ... think selinux ...
Not that it's easy to get it right. The hacks we've seen on
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 (guest, #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
Given that the kernel is not touched in any way and that no part of
Have all the fun you want, but this isn't a loophole, it's just
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 jzbiciak (✭ supporter ✭, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #29001) [Link] Hi Karim,
> Clearly the FSF once again fails to understand the realities of
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:
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
Karim
Misunderstanding of embedded system designers Posted Jan 19, 2006 9:16 UTC (Thu) by hingo (guest, #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 (guest, #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
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 (guest, #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.
GPLv3: a first look Posted Jan 20, 2006 17:19 UTC (Fri) by giraffedata (subscriber, #1954) [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 It just means X can't distribute it anymore. Plenty of legal copies already exist outside of Company X. The public is fully licensed by all of the copyright holders including X to redistribute under GPL3 from those copies. X's patent lawsuit today can't revoke any of those licenses granted in the past. Someone who doesn't enforce software patents has to pick up the baton.
GPLv3: a first look Posted Jan 19, 2006 12:37 UTC (Thu) by zmower (subscriber, #3005) [Link] Or company X begs to itself to be allowed to continue distribution under GPL v3. I think it has a good chance of succeeding.
GPLv3: a first look Posted Jan 26, 2006 9:06 UTC (Thu) by Wol (guest, #4433) [Link] Actually, I think all that happens is that company X loses the right to distribute company Y's enhancements (that is, unless they have strengthened the patent retaliation clause!).
That's partly why I suspect the FSF is unsure about patent retaliation! The clause as it stands in the GPL simply says "if you sue a Free Software contributor, you automatically lose any rights to use stuff contributed by your victim".
So X could carry on distributing their program. They just need to remove Y's mods (which, if as in this scenario seems likely, they are the prime maintainer it would be an easy thing to do).
Cheers,
GPLv3: a first look Posted Jan 18, 2006 0:36 UTC (Wed) by bgilbert (subscriber, #4738) [Link] With GPLv3, the right to use the software - not just to redistribute it - can go away as a result of filing a patent suit.I think the wording in section 2, paragraph 2, was a bit sloppy. The definition of "propagate", the second sentence of section 2 paragraph 1, and the discussion of patent retaliation in the Rationale document all imply that the intention was to take away the right to run modified versions. IIRC the FSF has historically taken the view that running an unmodified, GPL'd program does not invoke copyright restrictions, meaning that it could not be prevented by a copyright license. 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. Note that this section (section 13) is shown in brackets in the draft. My understanding of the Rationale document is that the FSF will remove it unless convinced otherwise.
Embedded systems, part 2 Posted Jan 18, 2006 16:20 UTC (Wed) by pm101 (guest, #3011) [Link] A seperate problem with the anti-DRM clause is that it my affect embedded systems with no DRM involved, but that simply do not provide facilities to upgrade firmware. The clause in question:
"nor for modes of distribution that deny users that run covered works the full exercise of the legal rights granted by this License."
This precludes me using GPL software in anything that stores it on a ROM, anything where the form factor prevents me from having ports to flash it, or with any microcontrollers that do not support In-System-Programming (if I have a microcontroller with 20 pins, very often, I program it in a special socket first, and then in the system, use all 20 pins, leaving none to reprogram it with).
Embedded systems, part 2 Posted Jan 18, 2006 16:24 UTC (Wed) by karim (subscriber, #114) [Link] Very good point, I second that.
Karim
Embedded systems, part 2 Posted Jan 19, 2006 4:49 UTC (Thu) by russell (subscriber, #10458) [Link] As I understand it you are still able to use the same mode of installation that they used. It would require replacement of the ROM. As long as the scripts, etc, used to install the software into a new ROM were made available or were commonly available tools.
Object code vs Corresponding source Posted Jan 19, 2006 4:50 UTC (Thu) by bignose (subscriber, #40) [Link] All the distributions you mention are simply what the license defines as "Object code", i.e. a non-source form of the work. The distribution is fine, so long as the user is always informed how they can get the "Corresponding source"; check section 6 of the draft.
Microsoft ad on linuxtoday.com Posted Jan 19, 2006 21:25 UTC (Thu) by wilck (subscriber, #29844) [Link] I followed the link "Stallman told the KDE developers..." and came to a page on linuxtoday.com with an ad by Microsoft, right on top and about 40% of the screen width, titled "Linux reference center", with stories on "RadioShack Saves Millions of Dollars by Choosing Windows Over Linux", "Rayovac Chooses Windows Over Linux for Lower Cost of Ownership, Less Risk", and so on.
I wonder whether linuxtoday.com is still a site that should be linked to by LWN.net.
Or is that supposed to be ironic? If yes, I'm not getting it.
Microsoft ad on linuxtoday.com Posted Jan 26, 2006 9:10 UTC (Thu) by Wol (guest, #4433) [Link] Microsoft is targeting linux sites for adverts.
Any linux site that takes adverts is likely to get that crap, so I wouldn't worry - MS is funding their enemies' "propoganda" efforts.
Look at it this way - if LWN took paid adverts, MS would be desperately trying to get their advertising up here.
Cheers,
Lies, damn lies, and statistics ... Posted Jan 20, 2006 9:09 UTC (Fri) by hummassa (subscriber, #307) [Link] Am I the only one who abhors this language??QUOTE 0. Definitions. A "licensed program" means any program or other work distributed under this License. The "Program" refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either modified or unmodified. ENDQUOTE Why (oh why?!) do they have to explain "any derivative work under copyright law" with "a work containing the Program or a portion of it, either modified or unmodified", which is NOT the definition of a derivative work under ANY set of copyright laws that I have ever heard about?
GPLv3: a first look Posted Jan 27, 2006 8:17 UTC (Fri) by ekj (guest, #1524) [Link] No covered work constitutes part of an effective technological protection measure:This does indeed sound quite weak. Thing is, unilaterally declaring what something is, or is not, doesn't in any way (generally) change what the thing is. If I write in the license for a program I make: "This is not a computer program", this changes nothing whatsoever, if indeed the thing is ruled by a court to infact *be* a computer program. If the complainer is the one licensing the program, then Estoppel could prevent them from at the same time claim (in the license) that the program is not a technological protection measuer, and at the same time claim (in the complaint) that the program *is* a technological protection measure. But this wouldn't help if the complainer is someone else than the one licensing the program. If X distributed a program under GPLv3 that is used to restrict access to content, and Y distributes content protected by the mechanism implemented in the program, then there's nothing stopping Y from using the DMCA against people who break the DRM and access the content. X migth be prevented, because they're saying in the license that the thing they're distributing is no technological protection measure. But Y never said any such thing, so they are free to claim that it is.
Linux and GPLv2 Posted Jan 27, 2006 14:58 UTC (Fri) by forthy (guest, #1525) [Link] Debunking a myth: I did a quick grep for "any later version" in my SuSE 10.0's /usr/src/linux directory (.c files only). 2558 files of the Linux kernel have a FSF-style copyright notice. Most of the other files don't contain any specific words about the license. The text preceeding the COPYING file (written by Linus Torvalds) certainly can only be considered valid for those parts of the Linux kernel he wrote himself, as the GPL (any version) does not transfer the license agreement to some man in the middle. It's always an author-user relationship, and the authors of 2558 files (give or take some in different versions) have expressed their view that the user can choose whatever GPL (s)he finds suitable. So even if Linus screams and shouts that Linux is GPLv2, it's not him to decide. A significant portion of Linux is already ambiguous, and he can't remove that. Mixing GPLv2 with GPLv3 programs is possible, just as mixing LGPL with GPL, or BSDL with GPL. The license with more clauses wins (you have to fulfill all clauses to distribute -- if you can't, don't distribute). BTW: The copyright notice in every file is important. Projects may contain files that live under very different copyright conditions. E.g. the GNU system I'm leading (Gforth) contains parts under GPL, BSDL-like parts, and in future also possibly LGPL parts. Each of these parts can be reused in other projects, and depending on the nature of the other projects, it might be important which parts end up in the product, and what license is behind these parts. It is wise to follow this procedure the FSF requires for their projects, Linux should follow it where possible. It's also just fair: If some Linux driver developer takes over a big chunk of BSD work, that driver itself could remain under BSDL, though it's possible to change the license of a BSDL'd code afterwards.
|
|||||||||||||