Weekly Edition
Return to the Front page
| |||||||||||||
Similar in spirit?
The recent discussions on the proposed version 3 of the GNU General Public
License have been well documented here and elsewhere. This proposal has
clearly exposed some differences of opinion within the development
community, with the anti-DRM provisions being at the core of the debate.
The addition of these provisions has created a fair amount of ill will
against the Free Software Foundation; opposition to them appears to have
created similar feelings in the opposite direction.
In theory, this disagreement should not come about. GPLv2 contains the following language:
9. The Free Software Foundation may publish revised and/or new
versions of the General Public License from time to time. Such
new versions will be similar in spirit to the present version,
but may differ in detail to address new problems or concerns.
If the FSF is adhering to its part of this bargain, then anybody who bought into the "spirit" of GPLv2 should not have trouble with this revision. So, clearly, those who oppose the GPLv3 draft - many of whom have released vast amounts of code under GPLv2 - believe that the revisions are not "similar in spirit." Some have gone as far as to accuse the FSF of using its power over the GPL to push its founder's radical agenda onto the code of large numbers of unwilling developers. That accusation is probably over the top. The FSF is, with GPLv3, attempting to respond to a number of problems as it sees them. Software patents are a clear problem, and the GPLv3 draft tries to mitigate that problem somewhat. International applicability of the license has not yet proved to be a problem in practice, but it is clearly something that reasonable lawyers can worry about. It seems worth fixing the language before some court somewhere on the planet decides that the GPLv2 incantations only work in the US. And so on. The FSF also, clearly, sees locked-down systems as a problem. It is interesting that this has not always been the case; back in 2000, LWN took issue with an interview with Richard Stallman, where he said:
I'm less concerned with what happens with embedded systems than I
am with real computers. The real reason for this is the moral
issues about software freedom are much more significant for
computers that users see as a computer. And so I'm not really
concerned with what's running inside my microwave oven.
(This interview has disappeared off the original site, but the Wayback Machine has it). Most TiVo owners probably see their gadget as being more like a microwave oven than a computer. It is not that TiVo has come along since then (the 2000 LWN article mentions it); what has changed is the FSF's - or, at least, Richard Stallman's - position on it. There are few people who disagree with the idea that locked-down systems can be a problem. Beyond the fact that such devices will always deny users the full potential of the hardware, they can spy on us, deny fair use rights under copyright law, lock us out of our own data, prevent us from fixing serious problems, and so on. Locked-down systems are designed to implement the goals of somebody other than the ultimate owner of the device. Such systems are undesirable at best, and outright evil at their worst. The disagreement is over how this problem should be addressed. The two sides, insofar as there are two clear sides, would appear to be these:
This logjam looks hard to break. Your editor, in his infinite humility, would like to offer a couple of suggestions, however:
Finally, while your editor is standing on this nice soapbox... The anti-DRM language was very appealing when it first came out. Your editor does not much appreciate the idea of some vendor locking up his software and selling it back to him in a non-modifiable and potentially hostile form. It is a violation of the social contract (if not the legal license) under which the software was contributed. But the attempt to address this problem in GPLv3 carries a high risk of splitting the development community while doing very little to solve the real problem. Dropping that language could help to bring the community back together behind the new license, leaving us united to fight DRM (and numerous other attacks on our freedom) in more effective ways. The FSF may want to consider whether, in the long run, its goals would be better served by a license which lacks this language. Such a license might be closer to the spirit which brought this community together in the first place. (Log in to post comments)
Similar in spirit? Posted Oct 5, 2006 0:55 UTC (Thu) by Sombrio (guest, #26942) [Link] > There are few people who disagree with the idea that locked-down systems can be a problem.
Could you please post the survey data that you used to come to this conclusion. I would like to know what questions were asked of the survey participants, and how you selected the survey participants, and what the margin of error is on your survey.
Similar in spirit? Posted Oct 5, 2006 1:32 UTC (Thu) by corbet (editor, #1) [Link] Oh come on. Could you please post an example of somebody who believes there are not abusive uses of that technology? That is not where the disagreement lies.
Similar in spirit? Posted Oct 5, 2006 2:19 UTC (Thu) by drag (subscriber, #31333) [Link] No shit.
For DRM you have to realise that ALMOST EVERY major hardware maker is pro-DRM. They see it as a way to attract content providers to the computer so that they can finally say that they have truly 'multimedia' PC.
They want to make the PC the hub of the electronics in people's living rooms.. As the television, stereo system, games, dvr, etc etc. The whole nine yards.
Sure today the 'Tivo' is used as a example. But now EVERY computer you buy is going to have trusted computer stuff on it. Now this have a viable security use, but in reality it's #1 purpose is DRM.
The is the main reason why we now have extensions like VT and Pacifica to help with VM! Back when Microsoft was touting 'Paladium' the idea was that with Paladium you would have a sort of mini-system seperate from your host operating system. The VM would provide the division to protect the data stream from being tapped software-wise, and the trusted computing modules ensured that you were unable to tamper with the VM or the software in it.
Now this stuff is in every PC your going to buy. It's a good thing for Linux (better VM, better security), but it's bad because of what it was and is going to be used for.
Now the DRM provisions in GPLv3 is bothersome for embedded developers who want to make their devices 'user proof' to cater to major copyright controllers of media. (they can easily work around any free software restrictions by doing a palladium-vm of their own anyways for media playback.. which I expect a number of people are already looking into)
HOWEVER the DRM issue is a problem for _all_of_us_. Not just users of embedded devices. Because the same restrictions (or better then) restrictions that are present in a TiVO is present in all PCs, in all servers.
So don't think a second this is just about embedded devices or some anti-tivo rampage.
The difference between 'GOOD' trusted computing (the kind that you can use to fight off rootkits) vs 'BAD' trusted computing (the kind that allows people like Sony to install rootkits which are illegal for you to remove) is weither or not you hold the keys to your own computer.
If you hold the keys, then all this stuff is great. The DRM provisions are attempting to protect your right to have control over your own hardware.
Weither it is in your DVR, your 'open source' router, your PC, your server, or whatever else.
I don't think that you're correct Posted Oct 5, 2006 4:04 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] Actually, many hardware makers strongly oppose giving Hollywood a veto over their designs. They are willing to make devices with DRM in them where it's profitable, but they oppose giving the "content industry" the power to dictate DRM everywhere.
Similar in spirit? Posted Oct 5, 2006 16:05 UTC (Thu) by sepreece (subscriber, #19270) [Link] I can't speak to whether "most manufacturers" are pro-DRM. I'm not sure even what that would mean.
Manufacturers DO want to be able to play the content that their customers want access to and they DO want to be able to build devices that talk to services that their customers want to use, both of which often require some kind of DRM, so you could say that manufacturers support having hte ability to DRM when producing such devices.
In more general terms, manufacturers aren't crazy about DRM. It raises the cost of their hardware, increases the complexity of their designs (and, therefore, the development and maintenance cost of their products), and creates downstream user problems. You say "Customers have to replace their products for newer versions of the DRM" the manufacturer says "I have to redesign my product more often." Manufacturers love it when they can use the same design over and over, for years and years; it builds margins.
On the other hand, manufacturers generally would like to be able to keep consumers fingers out of the insides of their products, because it adds support costs and potential civil liabilities. Even if you say "Modifying this device voids your warranty.", in practice, people STILL expect to get support in that case. Also, when a modified device breaks and causes damage, either to the user or to a network or a content provider, the manufacturer STILL can get sued, both for direct liability and for negligence in not preventing the user from making the change. It also offers opportunities for bad PR - when cell phone batteries explode it is virtually always non-manufacturer batteries that are involved, bu the press usually just uses the manufacturer's name in the story.
And, remember, the number of people who want to change their software is a tiny fraction of the total device market. So, the manufacturer has to spend money and accept risks to support a community that has no real impact on the market for the device. Those costs end up factored into the price of the devices, so people who have no interest in the freedom to modify the device end up paying something to support the wishes of the small group that do want that freedom.
It's just not a simple equation...
Similar in spirit? Posted Oct 5, 2006 2:48 UTC (Thu) by Sombrio (guest, #26942) [Link] I fully believe that DRM is NOT an abusive use of any technology or of the general public. Everyone I know does not believe in the DRM consipiracy theories either, so I am not alone. DRM is a problem manufactured by the FSF, and I for one, would like to know what percentage of people in the real world would consider DRM a problem. There is nothing wrong with DRM. A manufacturer has every right to incorporate any kind of technology into his device and offer it for sale, as long as it does not break any laws. If the public doesn't like what he has to offer, then don't buy it. But, do not characterize legitimate, law abiding, job providing, and upstanding members of our society as evil abusers of rights that you do not have.
Similar in spirit? Posted Oct 5, 2006 2:58 UTC (Thu) by drag (subscriber, #31333) [Link] Nobody said it should be illegal or evil for hardware manufacturers to support it.
Do you know what the anti-DRM stuff in the license is even designed to do?
It's not designed to stop DRM or stop free software used for DRM. What it does is prevent people from using DRM to effectively make the software you use unmodifiable.
It does that for the same exact reason why the GPLv2 forbids people from taking the code and using it in closed source software.
It's designed to keep software free. Right now DRM is used to make GPL'd software unmodifiable by it's end users. Tivo is the most famous example of this, but there are others.
It doesn't stop people from using encryption. It doesn't make it illegal to playback WMV10 on your computer or anything like that. It doesn't stop people from using trusted computing to make their systems more secure. It doesn't even stop people from using GPL'd software to create, distribute, or playback DRM'd media.
It only stops people from using DRM to make GPL'd software unmodifiable. That's ALL it does. That's it.
Similar in spirit? Posted Oct 5, 2006 3:21 UTC (Thu) by Sombrio (guest, #26942) [Link] Can you also explain this to me then.
"The Free Software Foundation has declared October 3, 2006 a "Day Against DRM" with demonstrations in New York and London. Also today, the Free Software Foundation Europe launched DRM.info. "DRM.info is based on the idea that people should be informed and involved in decisions that will affect them on a very personal level. "DRM technologies are based on the principle that a third party has more influence over your devices than you, and that their interests will override yours when they come in conflict. That is even true where your interest is perfectly legitimate and legal, and possibly also for your own data," explains Georg Greve, FSFE's president."
Similar in spirit? Posted Oct 5, 2006 3:59 UTC (Thu) by AJWM (guest, #15888) [Link] What part of "DRM.info is based on the idea that people should be informed and involved in decisions that will affect them on a very personal level." do you have a problem with?Perhaps you agree with Peter Lee, an executive at Disney, who said in The Economist: If consumers even know there's a DRM, what it is, and how it works, we've already failed,? Shame.
Similar in spirit? Posted Oct 5, 2006 4:19 UTC (Thu) by Per_Bothner (subscriber, #7375) [Link] Perhaps you agree with Peter Lee, an executive at Disney, who said in The Economist: If consumers even know there's a DRM, what it is, and how it works, we've already failed,?I think you're misreading the statement, which is just saying that unless DRM is near-invisible to the typical consumer, or if the "consumer experience" is made unpleasent because of DRM, then DRM will have failed. It's making the technical point that DRM will fail if it is something the consumer needs to be aware of. And that is the big problem DRM faces: consumers are happy with CD-quality sound and DVD-quality video, and they're not going to trade restrictions in what they feel they can legitimately do for relatively minor quality improvements. And that is the fundamental problem the "DRM industry" faces.
Similar in spirit? Posted Oct 5, 2006 13:22 UTC (Thu) by jneves (guest, #2859) [Link] When we're building a world where consumers also become producers, then DRM is a problem. DRM is just a way to defend the current status quo and it will disappear in the end, because it's not acceptable for people who want to do more that consume. Until then it'll be a PITA, but in the long run, a disappearing PITA.
Similar in spirit? Posted Oct 5, 2006 4:34 UTC (Thu) by Sombrio (guest, #26942) [Link] > What part of "DRM.info is based on the idea that people should be informed > and involved in decisions that will affect them on a very personal level." > do you have a problem with?
I have no problem with this statement. Do you think that selecting benign statements out of my post and trying to embarass me with them is a debate in good faith.
> Perhaps you agree with Peter Lee, an executive at Disney, who said in The
Ooooh, big bad Disney. I have the utmost respect for Disney, there are few corporations in America that express the true heart and soul of the American people as well as Disney does. My kids grew up on Disney, and they are better people for it. How many companies can claim that? I am sure this statement is taken out of context to promote an agenda.
The part I have a problem with is
This is FUD, that has no basis in fact, nor does it have a basis in law.
Similar in spirit? Posted Oct 5, 2006 5:48 UTC (Thu) by drag (subscriber, #31333) [Link] ""The part I have a problem with is"DRM technologies are based on the principle that a third party has more influence over your devices than you, and that their interests will override yours when they come in conflict. That is even true where your interest is perfectly legitimate and legal, and possibly also for your own data".
This is FUD, that has no basis in fact, nor does it have a basis in law.""
What exactly do you think DRM does? Have you taken a look at the DMCA ever?
from http://en.wikipedia.org/wiki/DMCA
All 100% fact.
What this effectively makes it completely illegal to attempt to, or tell people about, or distribute programs or software, that circumvent any sort of digital copyright protection scemes IRREGARDLESS of the user's intention.
So what DRM does is provide a way to control what software you are and are not allowed to run on your computer by wrapping it in the notion that these restrictions are intended to protect copyrighted material.
For instance you have 'FairPlay' versions Windows Media Video 10. These are DRM encrusted media files we are told are intended to protect the copyrights of various artists who produce music.
Now effectively due to the DMCA it is ILLEGAL to play these files on Linux. Because in order to do that you have to break the DRM encryption to do so and if your a 'pirate' you could use the same software that plays back music to copy music. Thusly enabling support of FairPlay in Linux with open source software is a U.S. Federal crime.
Now this DOES NOTHING TO STOP PIRACY. People have found easy ways to work around DRM restrictions and provide content on the internet. Once one copy is out there then anybody can find it and download it. Effectively DRM delays music being 'stolen' by a matter of minutes.
What it does accomplish though is it allows Microsoft to try to convince folks like the RIAA to sell music under their Fairplay DRM. Once people purchase the music then Microsoft, protected by the U.S. Federal Government, can now dictate to these people what software and operating systems they are allowed to use to to play back the music they purchased and what sort of other audio devices they are allowed to use.
Apple does a similar thing with their DRM'd Itunes service. They restrict people from licensing their DRM technology for MP3 players and such and they don't let other people create software to play it. If somebody from another country with no DMCA-like restrictions creates a compatable player or software then Apple will change the format of the DRM to effectively break their software or hardware. It does not have anything to do with protecting from piracy because Apple themselves allow end users to burn cdrom copies of music with no loss of fidality. The time it takes for a new song on Itunes to appear on the internet in a P2p site is measured in _minutes_.
So this does NOTHING to stop piracy. However because Apple says its a digital encryption intended to protect copyright then they now are protected by government law and can now control what software, what operating systems, what media devices, you are allowed to listen to music you purchase from them.
Basicly they are using DRM to make return customers of Ipods.
Same thing with the HDCP from Intel and friends.
HDCP is 'high definition copyright protection'. It is a encryption sceme for hardware they claim intended to 'protect' High definition content from being copied. HDCP, however, seemed to be a rather weak encryption method and was cracked years ago.
So it accomplishes absolutely nothing in preventing real piracy. Remember once you get one or two copies of unencrypted data on the internet it's easily aviable to millions and millions of users. For people with high speed internet it's easier and quicker to steal ex-drm'd content off the internet then it is to go down to the store and buy a new dvd.
However what it effectively does is this. That when you go out and in the near future by a High-Def or Blueray DVD it will probably have HDCP protections.
In order to legally play it back you will be required to purchase a special DVD player (no suprises), purchase a motherboard with a 'encrypted media path', purchase Vista 64bit (32bit won't work), purchase a new video card that support the protected media path, and purchase a new video monitor that supports HDCP.
Even though in other countries you can buy devices to circumvent this and allow older hardwar to work, in the United States it is illegal to produce or distribute or buy or use those devices because they could possibly be used to circumvent the 'protections' and allow 'piracy'.
OR if you want to use a HD dvd, if you got one now it probably won't work with HDCP protected content. You'll have to buy a new one.
It won't work with any HD television you may own right now either.. You'll have to by a new one.
It's a huge freaking scam. Over and over and over again any time you see 'DRM' it turns out to be almost exactly like the above.
HOWEVER NOTHING IN THE GPLv3 does anything about that. Nothing at all.
As far as Dinsey and 'Americanism' goes.. Disney sucks. I am proud to be American and am pretty freaking conservative.
It's just a snow job that they are for family values and such nowadays. That was over in the 60's. The Disney corporation owns many many major music recording, television, and movie studios. A lot of it produces the most vile anti-american, anti-family, BS you ever heard. And they'll happily do it as long as it sells and it doesn't get associated with the Disney name. It's not that they are anti-anything, they are just very pro-money. They do what sells. Now I am pro-money, pro-profit, pro-capitolism and all that, but I like to think that I am somewhat moral about it how I go about it.
Similar in spirit? Posted Oct 5, 2006 6:08 UTC (Thu) by drag (subscriber, #31333) [Link] Na. Nevermind about Disney. Now I think about it they aren't so bad, not as bad as other things at least.
I'd give them about a C- :P
Similar in spirit? Posted Oct 5, 2006 9:25 UTC (Thu) by nix (subscriber, #2304) [Link] What an excellent description of the problems with DRM that affect Joe Public that is.
Do you have any objections if I send it to a few doubting friends of mine before the subscriber-only period expires?
Similar in spirit? Posted Oct 5, 2006 11:17 UTC (Thu) by drag (subscriber, #31333) [Link] Ya sure. Just keep in mind that it's just my opinion and accuracy is not garrenteed.
It's no wikipedia article :-p
Similar in spirit? Posted Oct 5, 2006 11:19 UTC (Thu) by drag (subscriber, #31333) [Link] "Do you have any objections if I send it to a few doubting friends of mine before the subscriber-only period expires?"
Ya sure, go ahead.
Just keep in mind that it's only my own personal opinion and accuracy is not garrenteed.
Similar in spirit? Posted Oct 5, 2006 4:46 UTC (Thu) by drag (subscriber, #31333) [Link] The FSF have a hatred on DRM.
But it's not getting into the GPLv3 as you may think. Look at it for yourself.
In the GPLv3 the DRM provisions are there to preserve the right of the end user to modify and run GPL'd software. Nothing more nothing less.
"" Can you also explain this to me then.
"The Free Software Foundation has declared October 3, 2006 a "Day Against DRM" with demonstrations in New York and London. Also today, the Free Software Foundation Europe launched DRM.info. "DRM.info is based on the idea that people should be informed and involved in decisions that will affect them on a very personal level. "DRM technologies are based on the principle that a third party has more influence over your devices than you, and that their interests will override yours when they come in conflict. That is even true where your interest is perfectly legitimate and legal, and possibly also for your own data," explains Georg Greve, FSFE's president." ""
Did you pull that out of the GPLv3 license? I think not.
Again. The FSF has a anti-DRM agenda. So do most sane people once they realise that DRM is designed to control end users not designed to control piracy. (Look at DRM implimentations and how they apply in the real world. It's obvious that it has less to do with piracy and everything to do with market control and manipulation)
HOWEVER the dispute is over the GPLv3 license, not FSF's stance on DRM in general.
The GPLv3 license is a ATTEMPT to ensure that you as a end user and you as a developer will always be able to freely modify and run modified GPL'd software.
It has no language against using GPL'd software to play, create, or distribute DRM'd content. If somebody figures out a clever way (Sun is working on it) to have a open source application that play/distribute DRM'd content with strong protections legally, while still being modifiable, then there is no reason why a person can't license it GPLv3.
From the FSF point of view the lack of DRM language in the GPLv2 is effectively a loophole that provides a way for people to effectively make GPL'd software behave as if it was closed source. If you can't modify the software and still run it.. is it realy Free/Open source software?
To them, No it's not Free software anymore and thus is a violation of 'the spirit of the GPL'.
That is entire the point of it of the GPLv3 DRM language.
Weither or not it's needed I haven't decided yet... Also it may have unintended consequences.
Similar in spirit? Posted Oct 5, 2006 8:06 UTC (Thu) by nim-nim (subscriber, #34454) [Link] What the FSF feels about DRMs in general, and what the GPLv3 actually forbids are two different things. The GPLv3 scope is necessarily limited to the areas where DRM and GPLed software interact.
Moreover the "Day Against DRM" is about fighting the attempts to make DRM mandatory and protected every possible way by the law. Even if it is hugely successful it won't outlaw DRMs (Tivos for example existed well before the drastic Hollywood DRM laws started being written.
Your argument don't stand
Similar in spirit? Posted Oct 5, 2006 3:49 UTC (Thu) by AJWM (guest, #15888) [Link] I hesitate to feed the obvious troll, but...
> A manufacturer has every right to incorporate any kind of technology into his device and offer it for sale, as long as it does not break any laws.
Certainly. And software developers have every right to refuse to allow their software to be used in such devices.
>[DRM users] as evil abusers of rights that you do not have
I have a right to purchase a copy of a work, hold on to it for 95 years (or whatever the current limit is), and then make free use of that work in any way I choose. DRM curtails that right.
I have a right to copy limited portions of a work still in copyright for use in a review or research. DRM curtails that right.
I have a right to privacy. Spyware embedded in a device sold for an entirely different purpose, which does not permit me to remove the spyware without damaging the device, curtails that right.
I have a right to the peaceable enjoyment of a system which I own. Certain DRM measures, such as the Sony rootkit, can and have curtailed that right.
These are all rights encoded in existing law, which (bad) DRM threatens.
Can you honestly defend Sony's rootkit malware as "NOT an abusive use of" technology or the general public? Didn't think so.
Similar in spirit? Posted Oct 5, 2006 5:03 UTC (Thu) by Sombrio (guest, #26942) [Link] > I hesitate to feed the obvious troll, but...
Ok, this is just making me angry, and I have to disengage. I apologize for offending all of you to the point where I am now called names. I deny this charge, I am not a troll. I don't work for one of the companies all of you consider to be evil. I am not paid to annoy you. I simply disagree with you.
I certainly wish you all the best with your fight against DRM. Freedom is a great thing and you deserve the freedom to fight against your perceived evils.
I guess I need to go back to the fold of proprietary software developers. I do miss their professionalism and I think that I have just grown to the age where I can no longer relate to the ideals of the Free Software movement. You all just seem so radical to me now. I sure never thought I would join the establishment, but, they do have a whole lot more money, and I hear they are looking for evil coders. Now, where is that old Windows/CE manual.
Similar in spirit? Posted Oct 5, 2006 7:32 UTC (Thu) by k8to (subscriber, #15413) [Link] The initial statement was that locked-down systems can be a problem. Your hijack of this thread can be fairly described as trolling, by pulling it into a discussion of a particular type of locked-down system which is a hot-button toopic at the moment, and a particular set of issues and attitudes surrounding that type of locked-down system.
The debate about the issues surrounding DRM systems does have to occur in the open/free communities, but your narrow presentation and slicing don't help. You may not be a troll by intention, but you have achieved trolling by result.
Similar in spirit? Posted Oct 5, 2006 9:27 UTC (Thu) by nix (subscriber, #2304) [Link] I'm impressed by the reasoning at the end: don't respond to the arguments, just complain about unfairness and say you're going to pick up your toys and go home.
If that's 'professionalism', I'll take the free software community. I prefer amateurs anyway: they have more enthusiasm (and more competence).
Similar in spirit? Posted Oct 5, 2006 14:47 UTC (Thu) by sepreece (subscriber, #19270) [Link] I think the corollary to Godwin's Law should be extended to include the use of the terms "FUD" and "troll", which never advance the discussion and are basically just uncivil...
Similar in spirit? Posted Oct 5, 2006 22:46 UTC (Thu) by man_ls (subscriber, #15091) [Link] So, what do you say to someone which is spreading FUD or is an obvious troll? Like this:Everyone I know does not believe in the DRM consipiracy theories either, so I am not alone.Ad populum. Or this: DRM is a problem manufactured by the FSFKill the messenger. Again in this: I for one, would like to know what percentage of people in the real world would consider DRM a problem.Ad populum again. Or even worse, this: There is nothing wrong with DRM.Blanket statement. And this? A manufacturer has every right to incorporate any kind of technology into his device and offer it for sale, as long as it does not break any laws.Excusation non petita, accusatio manifesta. Finally this: But, do not characterize legitimate, law abiding, job providing, and upstanding members of our society as evil abusers of rights that you do not have.Appeal to emotion. I'd say the message is a troll, even if the person is a cartesian thinker.
Similar in spirit? Posted Oct 6, 2006 1:56 UTC (Fri) by sepreece (subscriber, #19270) [Link] If you think someone has raised an irrlevant argument, ignore it. Or explain why it's worthless. Or just say it's a worthless argument.
I just see way too many posts in way too many threads where "FUD" and "troll" are used to mean "You disagree with me." The particular example where it was applied to Sombrio felt to me like such an example.
Similar in spirit? Posted Oct 6, 2006 8:39 UTC (Fri) by stijn (subscriber, #570) [Link] Agreed. The dissection in the grandparent post, now *that* carries weight.
Similar in spirit? Posted Oct 5, 2006 14:36 UTC (Thu) by cventers (subscriber, #31465) [Link] If unfree is the mark of a true professional, I'll gladly call myself amere amateur for the rest of my life!
Similar in spirit? Posted Oct 13, 2006 8:06 UTC (Fri) by forthy (guest, #1525) [Link] In Germany, being "professional" has two meanings, which are actually the same - doing it for money. The second meaning therefore is "prostitute", they are doing "it" for money, not for love. And then, "amateur" is the right opposite, since that's a french word meaning "lover". Most prostitutes are actually enslaved in some way or another (and it seems to be that this is true for other professionals, as well, who are wage sclaves ;-).
Similar in spirit? Posted Oct 5, 2006 14:35 UTC (Thu) by sepreece (subscriber, #19270) [Link] A number of these complaints fail to distinguish between the copy you bought and your rights under copyright.
I have a right to purchase a copy of a work, hold on to it
No, it doesn't. At that point you are free to circumvent the DRM, because the work is no longer under copyright. Copyright does not require them to provide you with a copy when the copyright expires, it just bars you from making your own copy in the meantime.
"I have a right to copy limited portions of a work still in
Yes, you have a right to copy limited portions of a work. However, the copyright owner is NOT required to provide you with those portions. If you make a copy (say by videotaping a TV playback) to use in a review or research, that is not infringing. But there is nothing in the law that requires that you be able to copy such excerpts from a piece of licensed media that you own.
"I have a right to privacy. Spyware embedded in a device sold
Now that's a good argument. That's one to take to your representative and ask for legislation that specifically protects consumers against such reporting. It has, however, nothing specifically to do with DRM.
I think DRM makes content less desirable. People should object to it and push back on the content owners to not use it, just as consumers once successfully marginalized copy protection on software. I wouldn't mind seeing a mandatory licensing law that barred DRM and required payment of a small royalty on blank media, as consumers and device manufacturers also once successfully demanded. I would also love to see the DMCA repealed.
I just don't think the anti-DRM language in GPLv3 draft 2 will accomplish anything other than causing some amount of fracturing within the community.
Similar in spirit? Posted Oct 5, 2006 16:40 UTC (Thu) by felixfix (subscriber, #242) [Link] "Yes, you have a right to copy limited portions of a work. However, the copyright owner is NOT required to provide you with those portions."
That's not the problem. No one says the copyrightholder has to provide the specific portions. The problem is that the reviewer is not legally allowed to copy those portions. To break the DRM to copy them is illegal.
This DRM restriction is like saying it is legal to print anything you want but it is illegal to own a printing press or any other means of printing.
It may be legal to have a copy of something, but you have to break the DRM, and thus the DMCA law, in order to get that copy. That's what is wrong with DRM.
Similar in spirit? Posted Oct 5, 2006 19:38 UTC (Thu) by sepreece (subscriber, #19270) [Link] My point is that fair use does not in any way imply that the author must allow you to make direct, perfect copies from a particular copy that you own. You do not have and never had such a right. That would be akin to saying "all copyrighted text must be printed in black on a white background, so that copying machines can make clean copies for fair use purposes."
All fair use says is "if I use a copy of a brief segment of the work in a review, the owner may not sue me". You have basically the same recourse for electronic video that you would have for photographic video - capturing the video as it is played back.
Fair use does not give you any special rights with respect to your physical copy of the work, it only gives you protection from claims of infringement with respect to the underlying work. Your right would be exactly the same if you did not own a copy of the work or if the work was not available for private purchase (say, a movie).
Fair use does not in any way require that there be a way for you to make a copy; it is just a defense to copyright infringement. If you think that it should (which sounds good to me), lobby for legislation to support that.
Similar in spirit? Posted Oct 5, 2006 23:00 UTC (Thu) by man_ls (subscriber, #15091) [Link] I think I understood your point the first time, but the issue under discussion is completely different.Before, you had the right to copy certain things, and you could buy or build devices which did the copying. Today those copying devices are unlawful. Your intent doesn't matter; circumventing technical measures that protect copyrighted works is illegal, even if you do it to copy your own holiday pictures. Since DRM is based on those technical measures, you are screwed no matter what it protects. You don't have any recourse.
Similar in spirit? Posted Oct 6, 2006 2:08 UTC (Fri) by sepreece (subscriber, #19270) [Link] I completely agree that it should not be illegal to circumvent technological protection measures. I would be ecstatic to see the DCMA repealed.
Your point about your holiday pictures is wrong. It is not illegal to circumvent if you have the copyright holder's permission. Presumably, for your holiday pictures, you are the copyright holder. [In fairness, I had the same belief until I looked at the law again today.]
DRM didn't take away any rights you had [though the DMCA did]. The copyright holder always had the right to make it difficult or impossible to make copies.
DRM does take away rights Posted Oct 6, 2006 4:45 UTC (Fri) by felixfix (subscriber, #242) [Link] If content is locked up under DRM by an encryption key, and that key disappears, the content is lost forever.
Even if the key is not lost, if it is not available for someone who merely wants to exercise fair use rights, it effectively bans fair use. This destroys the balance of granting copyright for a limited time in exchange for fair use.
The average person should not have to jump thru hoops to exercise fair use rights. DRM requires that, even if the DMCA were to be repealed.
DRM does take away rights Posted Oct 6, 2006 13:27 UTC (Fri) by sepreece (subscriber, #19270) [Link] Sorry, I stand by what I said. "Fair use" is a defense to infringement, it is not a requirement that the copyright holder enable you to get or make copies.
If you think it should be (I wouldn't necessarily disagree), then you need to get the Act modified.
DRM does take away rights Posted Oct 12, 2006 16:54 UTC (Thu) by quintesse (subscriber, #14569) [Link] Saying the Fair Use is only some kind of excuse to allow infringement is showing a lack of respect for the intelligence of the people that actually penned down the act.
You have to remember that in those days the right you had as an auther either did not exist or followed the english model (IIRC) where the protection was absolute and for eternity.
It was recognized that neither was really any good because if you have no protection what incentive do you have in doing any original work? Somebody can just copy it 5 minutes after you put it on sale. But the other way around didn't work either because it stifled cultural and scientific progress.
So that's when they thought that a time-limited protection would be a good idea, I think it was only something like 7 years in the beginning? The idea being that in those years you could make enough money of your work but also recognizing that the term shouldn't be too long because again, what would be the incentive to make new work if you could live the rest of your live of a couple of good works? (In those days there was still a strong feeling that you actually had to work for a living)
But 7 years can still be a long time if you talk about scientific discoveries or about new important cultural developments. So in their wisdom they included, exactly, "Fair Use". With Fair Use you couldn't copy wholesale for publication or claim a work for your own but you could copy parts of it _for_publication_. You see, I'm not even talking about the possibility that you were able to extract part of the work, but you were even allowed to use it in your own works! That was considered to be a _very_ important part of the Copyright Act and can not be seen seperate from it or as being "tacked on" somehow.
In the end the Copyright Act was never about the authors, but about society: how to keep authors producing while preventing them from having a monopoly on their works and thereby depriving the society as a whole from learing and profiting from it.
But DRM is threatening to change all that. If you say that the Copyright Act says nothing about copyright holders being obliged to allow Fair Use you are exactly right, but you also have to remember that until now it was never _impossible_ to use your Fair Use rights given to you by the Copyright Act. And these protections are ever lasting as well, who is to say that in 90 years we're actually able to "crack" the DRM? Would we even be allowed to? Who knows existing work will still use the same DRM so it might still be illegal to crack the DRM because it would make existing work vulerable as well.
So yes, the best thing to do if you want to keep the spirit of the Copyright Act is to change it to include some limitations on what copyright holders can do in their crusade to prevent piracy. But with the kind of power the media companies have nowadays it's going to be a tough battle.
DRM does take away rights Posted Oct 13, 2006 6:54 UTC (Fri) by sepreece (subscriber, #19270) [Link] With respect, I think you just said, at rather greater length, the same thing I had said - if you think there should be an additional right to access to make fair-use copies, then you need to work to change the Act.
Circumvention Posted Oct 6, 2006 6:50 UTC (Fri) by man_ls (subscriber, #15091) [Link] It is not illegal to circumvent if you have the copyright holder's permission.IANAL, but paragraph 1201 says that No person shall circumvent a technological measure that effectively controls access to a work protected under this title.Then there are exceptions for certain classes of copyrighted works (as published by the Librarian of Congress) and uninfringing uses. I'd say it is illegal. Then it says that No person shall manufacture, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component, or part thereof, that [...] is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title.This means that you cannot even get the circumvention from someone else; this time the Librarian has nothing to say. DRM didn't take away any rights you had [though the DMCA did].DRM is bad enough without DMCA, its evilness only tempered by the fact that it is probably doomed to fail. Combined with the DMCA, it is positively evil. Right now the DMCA is in effect (and we have a similar law in Europe); when it is repealed this argument may not be valid, but until then it looks like it is illegal to circumvent even for your own holiday pictures.
Circumvention Posted Oct 6, 2006 13:25 UTC (Fri) by sepreece (subscriber, #19270) [Link] Yes, but you're missing the definition of "circumvention" in (a) (1) (3): "to descamble, to decrypt ... without the authority of the copyright owner". So, if you have the copyright owner's permission, it isn't circumvention [so, I misworded my statement, too].
Circumvention Posted Oct 6, 2006 13:34 UTC (Fri) by man_ls (subscriber, #15091) [Link] For circumvention to be illegal, it is enough that there is one work under valid copyright, not necessarily the one you want to access. Suppose you try to crack Microsoft's DRM scheme to gain access to: some outdated tunes from the 20's, a few excerpts for an academic study, or your own music. Since the "effective technological measure" also "controls access to a work protected under this title", you cannot circumvent it or even get a means to circumvent it from a third party.
Circumvention Posted Oct 6, 2006 17:10 UTC (Fri) by sepreece (subscriber, #19270) [Link] Yes, if you had your own content protected by the same DRM as other content, then it would be illegal to circumvent that protection. It's not necessarily a bizarre scenario, either, but one I would recommend avoiding.
Similar in spirit? Posted Oct 5, 2006 18:40 UTC (Thu) by AJWM (guest, #15888) [Link] >> "I have a right to privacy. Spyware embedded in a device sold>> for an entirely different purpose, which does not permit me >> to remove the spyware without damaging the device, curtails >> that right."
> Now that's a good argument. That's one to take to your representative and ask for legislation that specifically protects consumers against such reporting. It has, however, nothing specifically to do with DRM.
In the TiVo case, it does. Tivo's argument for locking down the box is that the content industries are demanding it, so that one can't use the Tivo for anything but time shifting (explicitly allowed under the Betamax decision). Hence, a DRM measure. That lockdown also conveniently prevents users from disabling the piece that records your recording/viewing habits and occasionally phones home with them.
In other words, the manufacturer is using DRM as a convenient excuse for preventing the disabling of spyware.
Similar in spirit? Posted Oct 5, 2006 19:51 UTC (Thu) by sepreece (subscriber, #19270) [Link] This whole discussion has thoroughly muddied the distinction between DRM (content protection) and Trusted Computing (control over what software runs on the device). My statement maintained that distinction. DRM has nothing to do with spyware or with whether you can replace your software. The technologies used for DRM and TC are sometimes related, but it makes no sense to conflate them. They are both technologies that restrict users' freedom in return for certain benefits.
DRM sometimes (but not always) relies on some kind of TC mechanism to make sure that the software accessing the content is trusted. In other cases the DRM and content acces are bundled in a separate module so that the controlling software is unable to access the decoded content, in which case no TC is needed.
It's reasonable to expect that as hardware with built-in TC is commoditized, use of TC to simplify DRM implementations will become more common.
Note, however, that situations such as you describe (where "spyware" is in the trusted software) are typically service situations, where your contractual relationship with a service provider probably dictates that that software be used, anyway. [Not that there aren't exceptions.]
Most Tivo devotees say that the device's ability to track and predict their use is the primary reason for preferring a Tivo to a generic DVR. What you consider "spyware" is a critical product feature to them. Don't like it? Buy a different device.
Similar in spirit? Posted Oct 5, 2006 11:16 UTC (Thu) by lysse (guest, #3190) [Link] > I for one, would like to know what percentage of people in the real world would consider DRM a problem.
The majority of iPod owners, for a start, judging by their avoidance of it.
However, as far as I can see the FSF isn't banning the use of DRM; they're simply requiring that GPL'd software can be run once it's compiled, which could be done by providing a signing key for each machine that only works on that machine, or a GPL'd signing program that could do the equivalent - as far as I know, the GPL is silent on the *right* to distribute universally-runnable binaries, merely setting out the obligations of those who do. So try as I might, I simply cannot see how the FSF is doing anything other than making explicit what was previously implicit, in the face of a situation where it would not otherwise be possible.
Similar in spirit? Posted Oct 5, 2006 18:33 UTC (Thu) by Ross (subscriber, #4065) [Link] "DRM is a problem manufactured by the FSF"
I find it hard to take you seriously. If you are trolling, I'm sorry I'm contibuting.
There are many examples of DRM abuses. Look a ebooks, defunct music downloads which no longer work because the company went out of business, etc.
If people had no problem with DRM, why do DRM devices always go away when there is a non-DRM version with the same features? Sony had to give in. Their portable music players wouldn't play non-DRM music so nobody bought them.
The GPL is not law, it is a license. If people don't want to abide by its rules they don't have to. But then they can't use the software. You can't incorportate other people's code into a product just because you are "job providing" or "upstanding". You have to have their permission.
Similar in spirit? Posted Oct 5, 2006 20:35 UTC (Thu) by mrfredsmoothie (subscriber, #3100) [Link] They take the operating system which includes my work, and sell it back to me , unchanged by them except wrapped in DRM inside their wireless router, and I want to alter the kernel or the configuration of said to block my teenage child's access to porn sites. I can't. Now, it may not be "illegitmate" or illegal, but it violates the spirit of the license of my work which they're using, without compensating me in the only way I cared about: ability to run modified code. You may not consider that to be a problem; I certainly do and I suspect many others do too.
Similar in spirit? Posted Oct 7, 2006 4:51 UTC (Sat) by bojan (subscriber, #14302) [Link] > I fully believe that DRM is NOT an abusive use of any technology or of the general public.
I'm really not big on conspiracy theories, but you'll have to admit that by shifting the trust from the user to the software or device, the "who can do what" shifted with it as well. Sure, there are good uses of DRM, as people pointed out - like in medical and safety equipment etc. But claiming that technology cannot be abused in factually untrue.
> DRM is a problem manufactured by the FSF
A think a more accurate statement would be that FSF pointed out to some potential problems with the use of DRM technologies.
Similar in spirit? Posted Oct 7, 2006 16:34 UTC (Sat) by sbergman27 (guest, #10767) [Link] Thanks, Jonathan, for hitting the nail on the head. The major question facing us is not whether the DRM provisions or right or wrong. The question is whether the DRM provisions are worth the division of the community that will almost certainly result.
Unfortunately, this is Richard's license, and in my humble opinion, the "Year of Debate" is a dog and pony show.
But the fact that the situation is tense enough to elicit an outburst from you (I've been reading LWN for years, and your comment above *IS* an outburst... for you. That's a compliment, BTW.) speaks volumes to me.
This new license version is poison to the community. We can't afford it.
Similar in spirit? Posted Oct 5, 2006 2:02 UTC (Thu) by njs (guest, #40338) [Link] While personally I am undecided on the GPLv3 provisions, I find the brouhaha about "similar in spirit" a little curious. A thought experiment for those who it bothers: suppose 5-10 years ago, before DRM was actually on the horizon etc., I had asked you, "What if it was possible to have a computer whose software could only be modified with the permission of the original manufacturer -- do you think RMS and the FSF would consider such a computer to be antithetical to everything they stand for?" If someone had asked me this, I would have said "yes"; the FSF's philosophy seems to make that quite clear. Recall also that while in these discussions we just say "or later version" as a shorthand, the full language we write in our licenses explicitly adds "as published by the Free Software Foundation".
If you agree that the FSF's philosophy is consistent from then to now, and that those of us who used the "or later version" language were explicitly placing our trust in the FSF -- then how can you be surprised when they interpret clause 9 in the same way now as they would have back then? If someone makes you a promise, and also publishes hundreds of pages of positions papers explaining what they meant by it, you can't be surprised when they hold to their version of the promise, rather than what you wished they meant but never said (or explicitly repudiated).
To reiterate, I'm not saying that objections to the current v3 draft are unjustified; just that dragging in clause 9 seems disingenuous.
I also find all the people preemptively removing the "or later version" language from their software strange. Like Ingo points out, this puts a really astonishing amount of power into the FSF's hands, and that's a scary thing. But the scary possibility, the thing that takes an extraordinary leap of faith, is trusting that the FSF will not add _more_ permissions -- in particular, removing things like the "tit-for-tat" that are so fundamental to protecting us. RMS is the only person who could do that. I can't blame people like Linus for deciding to play it safe in this respect.
But, it turns out that all the objections I've heard to the v3 drafts have to do with adding more _restrictions_. For me, there's a fundamental distinction here -- if I found out that my software, that I thought was free, could suddenly be incorporated into proprietary software, that would piss me off. If, OTOH, I found out that someone could suddenly add some patches to my code and the result could only be used on certain machines, then, well... that's annoying, and counter to the GPLv2, but... I would survive just fine. I only object to people forking my code to live in their own little more-restrictive universe if their doing this somehow impacts my own development.
Which is a worry. People (e.g. Ingo) have pointed out that code can go "v2 or later" -> "v3", but not vice-versa, and this gives v3-only forks an advantage that could potentially suck away developer resources. But we're lucky -- most of this stuff is so scary and contentious because the stakes are high and none of us really know how to predict what will happen. In this case, though, we actually have data! _Lots_ of projects have licenses that are "upgradeable" to more restricted ones -- as someone pointed out on the last thread, the LGPL in particular has the property. I'd actually forgotten until it was pointed out. Why had I forgotten? Because it _never_ gets used (except maybe to incorporate some LGPLed code into a pre-existing GPLed project). The same is true of the BSDs... BSD code gets proprietary forks all the time, but have you ever heard of a BSD-licensed project getting forked to GPL? And the fork being successful? Wine is sort of an example of this, except IIUC pretty much everyone switched licenses together -- so it's hard to call it an example of a harmful fork that diluted developer resources.
(See also Don Marti: http://www.linuxworld.com/community/?q=node/182 )
So, since I trust the FSF not to add permissions, and history doesn't support there being non-trivial harmful effects to adding restrictions, I'm leaving the "or later version" language on all my software for now.
I guess finally I'll say something bad about v3 too, since I claimed at the beginning that I hadn't decided but here I am making only arguments for the "pro" side... I am actually, despite the above, really really scared of v3. It isn't the whole debate about whether v3 puts restrictions on use, or separately created hardware, or whatever, that bother me the most. I'd actually call myself a Free Software guy, over the years I've come around to agree with a _lot_ of the FSF's philosophy, but it's this issue of freedom that scares me.
For me (and this matches my reading of the GNU Manifesto), free software means that I can learn from and modify the tools I use, and help my neighbor. And, if the whole world can't be free (since copyright law is not so easy to change), then with tools like the GPL and the GNU project at least we can create a sandbox for ourselves, and so long as we stay inside it, we can stop dealing with obnoxious copyright rules -- we can act as if we're really free.
A not-really-digression: this is what pisses me off about Sun and their CDDL. I'm happy they freed their software, that's very generous of them, woohoo, but they made it GPL incompatible. That's their decision, but it's like the person who says they will only be your friend if you stop hanging out with your other, existing, friend. If you want to come play in our sandbox, great, the more the merrier, but don't try to split the sandbox in two by putting a big wall down the center. The whole point is to never trip over those walls.
This is what worries me about how the v3 process is turning out: if it manages to split the FOSS community, then even if I agree completely with the FSF's goals, I can't shrug that off as just a practical problem, or the regretful but morally necessary outcome of some people deciding that they prefer pragmatics to freedom. It directly, and potentially dramatically, impacts my own ability to act as a free developer. The possiblity terrifies me, viscerally.
I'm starting to wonder if we shouldn't treat the draft v3 DRM provisions like we all treat questionable patches. The legal and technical landscape around DRM is so unsettled right now that no-one seems to be sure if the DRM clauses _are_ in fact necessary to preserve freedom or not, or even if the proposed clauses will actually have any practical effect at all. (Maybe next year it will turn out that the latest preferred way to achieve DRM-like effects doesn't run afoul of the draft language at all.) There's also a worry, just from the difficulty getting the language right so far, that they may have nasty, unforseen negative consequences (i.e., somehow preventing perfectly legitimate and freedom-enhancing projects).
Compare that to a patch adding a new feature to a project. If we can't tell yet whether the feature actually has the right design, the coding style is a little grotty, enough to make us worry it might have bugs in it to make the whole program crash... maybe the feature is actually really, really important to have in the long run. But we already have a bunch of other stuff landed on mainline to go into the next release, and we're not going to delay getting all that to users's hands just so we can get this other new thing right.
So maybe we should push back DRM provisions to GPL v4. The way patches go, half the time it turns out that just by waiting a bit and getting more experience with how the software is used, suddenly the right solution turns out to be obvious to everyone and the debate disappears.
So, to conclude this epic comment:
Similar in spirit? Posted Oct 5, 2006 4:09 UTC (Thu) by proski (subscriber, #104) [Link] So maybe we should push back DRM provisions to GPL v4.Actually, I haven't heard anyone saying that GPLv3 is better than GPLv2 except the DRM issue. Whoever criticizes changes in GPLv3 compared to GPLv2 criticizes other changes as well. My prediction is that most code that is under GPLv2 now will stay under GPLv2. But we may see new projects under GPLv3. We may also see some currently non-GPL code relicensed under GPLv3. We may see a new Java implementation under GPLv3. We may see Qt under GPLv3. We may see truly innovative software under GPLv3 due to the fact that it's more explicit with regard to patents. Making changes to GPL piecemeal would likely increase fragmentation, not avoid it.
Similar in spirit? Posted Oct 5, 2006 4:38 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] you contradict yourself
you say exisitng code will stay GPLv2, but that there may be a QT under GPLv3
why would they change from GPLv2 to GPLv3?
Similar in spirit? Posted Oct 5, 2006 8:48 UTC (Thu) by khim (subscriber, #9252) [Link] Because it's way better Trolltech. Really. Think about it: Qt is used in closed boxes. A lot. But right now you can (in theory) take GPL version and lock it down with DRM. GPLv3 is perfect for dual-licensing scheme! Community projects rarely change the license (because it's hard). Company-owned projects are toally different kettle of fish. If IBM will "approve" patent changes (who's approval will you trust in regard to patents clause if not IBM?) then I'm pretty sure we'll see a lot of software licensed under GPL, not just Qt.
Similar in spirit? Posted Oct 5, 2006 14:57 UTC (Thu) by sepreece (subscriber, #19270) [Link] That's a fascinating observation that I hadn't really thought about before, but it's clearly true: by banning the application of GPLv3 software in protected applications, the FSF is making dual-licensing more attractive, because the alternative licenses do allow such use.
Similar in spirit? Posted Oct 5, 2006 4:36 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] the LGPL->GPL conversion isn't the same problem as the GPLv2->GPLv3 conversion for one big reason
there are a lot of people takeing religious stances on the GPLv2/v3 issue who are being extremely adamant about the need to switch to code to v3. there is not a similar body of people determined to eliminate the LGPL
and frankly these people have a point, while I personally prefer the GPLv2, there is no point in having a GPLv3 if all code remains at GPLv2 or later, yes you can use the v3 license, but if it's prohibiting things that v2 allows, anyone wanting to do those things just ignores v3 and acts under the v2 license. Also, the 'license compatability advantage' of GPLv3 is meaningless if a project is trying to maintain GPLv2 compatability.
so there are three outcomes
1. code remains GPLv2 or later and GPLv3 is meaningless as none of it's provisions are every used.
2. code migrates to GPLv3
3. the community splits between the two versions, probably with continual snipeing back and forth.
the FSF is intending for result 2, but unfortunantly I expect result 3 to take place. there are a lot of people who strongly believe both sides of this issue, and if forced to choose, will go different ways.
Similar in spirit? Posted Oct 5, 2006 8:54 UTC (Thu) by drag (subscriber, #31333) [Link] Generally speaking it seems that the license choices of the major contributors are respected even if the license can be 'upgraded' to the GPL.
Look at the large number of BSD-licensed software. A major example is PostgreSQL. If there is any peice of software poised for a 'GPL Takover' then that one would be one! But I don't think I've ever heard of anybody trying to 'take over' PostgreSQL with a GPL'd license (although I am sure that it's used in inumerable propriatory products).
There are numerious projects on non-copyleft licenses like zlib and such.
Also don't forget that the GPLv3 is due for a few more revisions before it gets out there. People are all excited right now because it's new and the debates help people figure out what is going on. (I know it helps me a lot)
I think that if the majority of the people in a GPLv2 or later project want it to remain GPLv2 or later then I think that most of them will be fine.
*shrug*
I think the majority of the fights are going to be with people who have "GPLv2 only" style licenses. These people usually had a reason to distrust the FSF/RMS stuff and while the "GPLv2 and later" crowd have little problem integrating with GPLv3 code from other projects (probably all it would take would be a nice email for permission to GPlv2 the code)..
the "GPLv2 only" people will probably end up with huge fights when people try to take them to "GPLv2 or later" for "better compatability" with other programs. The original people that choose the license in the first place will probably perceive it as a underhanded attempt to take their project to GPLv3.. while the other side of the internal project debate will want to see the project gain compatability with GPLv3 code rather then risk going of into irrelevency. (definately not talking about the Linux kernel here, it has it's own special rules)
Eliminate the LGPL? Posted Oct 5, 2006 23:32 UTC (Thu) by man_ls (subscriber, #15091) [Link] there is not a similar body of people determined to eliminate the LGPLWhat about the own proponent of the license, Richard Stallman? Also, the 'license compatability advantage' of GPLv3 is meaningless if a project is trying to maintain GPLv2 compatability.Not if you just take advantage of the "or later" clause; switch to GPLv3 all those things that are GPLv2 "or later" and you can be compatible with Apache code. the FSF is intending for result 2, but unfortunantly I expect result 3 to take place.Frankly, we don't need this FUD. Notice how njs in the parent comment says that his biggest fear is not with any GPLv3 clauses, but with the split it might cause. Even our favorite editor seems to think the same way. That is what many people seem to be trying here on LWN: creating division, crying: "Stop this licensing madness!" I for one am happy that Stallman is not one to change his mind under pressure, even if on other occasions it has worked to the detriment of free software.
Similar in spirit? Posted Oct 5, 2006 14:58 UTC (Thu) by cventers (subscriber, #31465) [Link] > This is what worries me about how the v3 process is turning out: if it> manages to split the FOSS community, then even if I agree completely > with the FSF's goals, I can't shrug that off as just a practical > problem, or the regretful but morally necessary outcome of some people > deciding that they prefer pragmatics to freedom. It directly, and > potentially dramatically, impacts my own ability to act as a free > developer. The possiblity terrifies me, viscerally.
That worries me too, but I don't stay up thinking about it at night
The kernel community is one of the most visible and vocal parties when it
It's no surprise to me that it appears as if we're split right down the
There seem to be a lot of people that are really happy with the way
The _real_ danger isn't from the GPLv3 license - it's from the GPLv3
Cheers!
Similar in spirit? Posted Oct 6, 2006 14:37 UTC (Fri) by mingo (subscriber, #31122) [Link] The kernel community is one of the most visible and vocal parties when it actually has something to say in the public. The kernel community is the biggest project that is closest to the hardware, so you should not be surprised that we have a direct (and vocal) opinion when it comes to issues of the GPLv3 trying to control hardware. We are dealing with tons of hardware issues today, our work has been DRM-ed by Tivo, and we'll be amongst the first ones suffering the fallout of any negative effect of a bad license change in this area.
Similar in spirit? Posted Oct 6, 2006 17:22 UTC (Fri) by cventers (subscriber, #31465) [Link] > The kernel community is the biggest project that is closest to the> hardware, so you should not be surprised that we have a direct (and > vocal) opinion when it comes to issues of the GPLv3 trying to control > hardware.
I claim no surprise. I observe precisely what you've said.
> We are dealing with tons of hardware issues today, our work has been
Indeed.
> and we'll be amongst the first ones suffering the fallout of any
How so? The kernel is under GPLv2 only, and the issue of forming a
This is an easy question to answer I'm sure, but please don't forget
And I still haven't gotten a satisfactory answer from anyone as to why
Why will no one answer my charge?
Similar in spirit? Posted Oct 13, 2006 10:13 UTC (Fri) by forthy (guest, #1525) [Link] The kernel is under GPLv2 only Please read the license, this is not true. Linus redistributes what he has got under GPLv2 only, which is his right. Most of Linux either does not tell anything about the license version (in which case you need to assume that it's GPL any version), or it explicitely tells you that it is GPLv2 or later. Few, if any, files are marked with an explicit "GPLv2 only" by the original author. Linus is not in the position to change the license terms of the original authors, and the GPL clearly states that you get the license from the original author. Node besides: Linus didn't ask anybody about his GPLv2-only comment in 2.4.0-test-something, so he can remove that whenever he's convinced that GPLv3 is ok for him. Being a loudmouth who makes more than enough errors, and then takes years to recover from that, this is not likely to be soon, but it may happen.
Similar in spirit? Posted Oct 5, 2006 19:35 UTC (Thu) by pimlott (guest, #1535) [Link] Maybe next year it will turn out that the latest preferred way to achieve DRM-like effects doesn't run afoul of the draft language at all.That possibility seems quite real to me. As I posted before: What if software provider and the service demanding remote attestation are different entities? Eg, the device manufacturer distributes the GPLv3 media player and the media company verifies that it is a "known-good" version (according to their list). This seems a plausible arrangement. So if I hack the media player, the device doesn't "play the same songs", but the manufacturer has no power to change this and the media company has no obligation to the device owner. Who do we go after?
Similar in spirit? Posted Oct 6, 2006 14:22 UTC (Fri) by nim-nim (subscriber, #34454) [Link] The check for the media company signature *is* deployed by the manufacturer in its devices, so the manufacturer can hardly pretend he was not involved one way or another.
Now the interesting part in this scenario is the manufacturer may not have the private key of the media company, so if the GPLv3 latest draft only handles this case, it needs to be tightened up.
Similar in spirit? Posted Oct 6, 2006 15:34 UTC (Fri) by pimlott (guest, #1535) [Link] The check for the media company signature *is* deployed by the manufacturer in its devices, so the manufacturer can hardly pretend he was not involved one way or another. Fair enough, but they can argue that this is simply a standard facility of their (proprietary) operating system, and that they don't control how third parties make use of it. Or extend the scenario another link: Say entity A distributes the device and operating system which supports trusted remote querying of the running software; entity B distributes a GPLv3 media player; and entity C distributes music to the device only after determining that a good (according to their list) version of the media player is running. I think that any "tightening up" of the GPLv3 that could block this scenario is reaching too far (if it doesn't reach too far already).
Similar in spirit? Posted Oct 6, 2006 15:55 UTC (Fri) by nim-nim (subscriber, #34454) [Link] The entity wich installs the initial GPLed software version has by definition the means to authorize it.
You can add indirections, cloak it in multilateral agreements, that does not change this basic fact
Similar in spirit? Posted Oct 6, 2006 16:24 UTC (Fri) by pimlott (guest, #1535) [Link] The entity wich installs the initial GPLed software version has by definition the means to authorize it.I believe that's simply not true. In my scenario, the media distributors are merely validating a checksum of the media player binary. This checksum needn't even be provided by the media player company. They could simply distribute a (DRM-enabled) binary, then the media distributors verify that it is sufficiently user-hostily (by inspecting the source code and recompiling with the same toolchain to see that the same binary is produced) and add it to their approved list. Nothing the media player company does can make the media distributors add to their approved list.
Similar in spirit? Posted Oct 6, 2006 21:46 UTC (Fri) by nim-nim (subscriber, #34454) [Link] Your scenario is not credible.
0. Your use of a checksum muddies the water somewhat, because it implies a 1<->1 relationship between authorization and software version. But a fixed checksum list would be of little use, so the list itself must be updateable, and the checksum of the update list is unknown beforehand, which means you have a master key somewhere which can approve any checksum or list, which takes us back to square one.
1. The media player company is not distributing its binary in the hope that, maybe, a media distributor will pick it up, approve it, and it will end up in the device. They have contracts with all these entities if only to get paid. If they take the money without ensuring the licensing obligations are respected, they'll be condemned.
2. Even assuming it does release a binary without any counterpart or contact with the other companies, I believe that by ensuring it can made its way on the device they are participating it its distribution, and have to honor the licensing obligations. Certainly should they approve a binary containing sequences "lifted" from an Hollywood media they wouldn't expect not to be sued.
This is a general weakness of many of the examples provided so far. You all assume that because the GPL "payment" is not monetary, or due to hobbyists, it's somehow optional or weak and you only need to make the situation complex enough before people give up. The law does not work this way.
Before you post any other scenario, take the time to replace "GPLed software" with "Hollywood film" and "GPL licensing obligations" with "Hollywood film licensing obligations". If your house of cards wouldn't protect you when distributing an "Hollywood film", do you actually believe using it for a "GPL software" will work any better before the judge?
Also, do remember that no judge will rule that since you're broke, you didn't have to pay at the shop. He'll rule that since you're broke, you shouldn't have taken what you couldn't afford (and send you to jail). Likewise, being in no position to honour GPL licensing obligations does not give you a free pass at GPLed software. Especially if you've painted yourself in this corner knowingly.
Similar in spirit? Posted Oct 6, 2006 22:31 UTC (Fri) by pimlott (guest, #1535) [Link] I agree that the weak point in my scenario lies in the relationships between the parties. If you can show that the media player maker is colluding with the device manufacturer or the media distributors to keep users from exercising their rights, you might be able to use the GPLv3 against them. But I am not as sanguine about this as you: I still fear that courts would not consider my scenario (or some variation) collusion. DRM is still an experiment, and we should keep an open (that is, cynical) mind about all of the imaginitive ways in which the media industry will try to use it.On your point 0: the checksum list is maintained by the media distributor, so there is no need for a master key. Also, you seem to have made some interpretation I didn't intend about what's in the media player binary. At least, I don't know what "sequences 'lifted' from an Hollywood media" refers to. What I had in mind is simply that the media player only plays files signed by the media distributor's public key and enforces use restrictions specified in the files. If I offered such a binary (along with its sources) on my web site, having no relationship with any device manufacturer or media distributor, just to be ornery, surely I wouldn't be violating any license.
Similar in spirit? Posted Oct 7, 2006 12:38 UTC (Sat) by nim-nim (subscriber, #34454) [Link] > On your point 0: the checksum list is maintained by the media> distributor, so there is no need for a master key.
And how do the device knows it can accept a new checksum list? If it can not at all or if it can accept anyone your system is pretty useless
> Also, you seem to have made some interpretation I didn't intend about
Let me rephrase it then:
1. Let's say Disney decides to participate in a campaign against evil_of_the_day and makes a great mickey cartoon freely distributable provided it's alway bundled with the latest localised update of education_pamphlet_against_evil_of_the_day
2. one of your nebulous entities authorizes the video for a device sold all over the world, but does not bother with the education_pamphlet_against_evil_of_the_day, or all the localized versions, or ignores updates
3. another of your nebulous entities makes the authorized binary available advertising it can be played in media player
Questions:
Similar in spirit? Posted Oct 9, 2006 3:38 UTC (Mon) by pimlott (guest, #1535) [Link] And how do the device knows it can accept a new checksum list?The device doesn't need the checksum. The device merely reports the checksum to the media distributor, which validates it against its own (self-maintained) list. Let me rephrase it then:[snip] I think I understand your scenario, but I truly think the outcome is sensitive (as in my scenario) to the details of the relationships between the entities, and their intentions. If the entity in (3) is advertising the authorized binary for use in many media players, maybe they can say, "hey, it's not our fault that the device in (2) refuses to view the pamphlet--every other device views it". To repeat, I agree that there may be grounds for finding a GPLv3 violation in some cases like I described; however I don't agree that it is clear-cut for all cases.
Similar in spirit? Posted Oct 9, 2006 15:33 UTC (Mon) by kleptog (subscriber, #1183) [Link] The device doesn't need the checksum. The device merely reports the checksum to the media distributor, which validates it against its own (self-maintained) list.Well, that's obviously not going to work. Then I can simply set the code to return the expected checksum while actually running something else. For a remote entity to verify you're actually running a particular binary is hard. The act of sending the checksum becomes the weak link, because some upstream router can just change it. So instead, the device has to fetch a list of valid checksums and have some TPM of its own to verify the checksum against the list. It's the verifying of an authentic checksum list that is the crucial part, and where of use of encryption keys comes from.
Similar in spirit? Posted Oct 9, 2006 16:10 UTC (Mon) by pimlott (guest, #1535) [Link] Then I can simply set the code to return the expected checksum while actually running something else.As I said earlier in this thread, the device (with its proprietary operating system) "supports trusted remote querying of the running software". The query protocol naturally ensures the authenticity, integrity, and confidentiality of the communication. You or an upstream router can't tamper with it. The media distributer can be sure that it is talking to the unmodified operating system and getting trustworthy checksums.
Voting and X-Ray machines? Posted Oct 5, 2006 3:33 UTC (Thu) by GreyWizard (guest, #1026) [Link] Voting machines? X-Ray machines? The parties who own such devices can and probably should make use of tamper resistance features. Voters and patients should not be permitted to make changes, for the same reason guest accounts shouldn't have root access on servers. Maybe politicians and doctors should be restricted as well but governments and hospitals should clearly have the power to modify the software themselves if necessary.
Perhaps there are legitimate uses for DRM (I would like to know about them) but these particular examples seem confused. The extent to which the GPLv3 draft prohibits tamper resistance deployed by a system owner as opposed to DRM imposed by a vendor is unclear to me, but if it does that is probably not intended.
Voting and X-Ray machines? Posted Oct 5, 2006 3:49 UTC (Thu) by felixfix (subscriber, #242) [Link] I tell you what -- I don't care about X-ray machines. Who in their right mind will want to change their X-ray machine software? Considering that they cost so much, it is simply not going to happen unless some super crazed admin were to go off the deep end, and that admin would go to jail as soon as something bad happened.
Voting machines are a different problem. The danger with them is not from voters, it's from the manufacturer mainly and the individual govt bureaucrats to a lesser extent. Almost all problems with voting machines could be solved by producing a paper ballot which was the one and only source of vote counting, and then it doesn't matter what monkey business goes on with even the manufacturer. If each voter gets a paper printout which they put in the ballot box, and that is what is counted for all vote tallies, who cares what goes on with the voting machine itself? If someone messes with it, it would only take a very few voters to complain to get the cracker in hot water.
Voting and X-Ray machines? Posted Oct 5, 2006 8:27 UTC (Thu) by nim-nim (subscriber, #34454) [Link] > Voting machines? X-Ray machines? The parties who own such devices can and> probably should make use of tamper resistance features.
And surprise the GPLv3 actually allows it.
What it forbids is the manufacturer keeping the key for himself (to take an analogy : you can build a password auth in your product, but you can't hardcode a password you do not share downstream. The direct result obviously is no hardcoded password and the owner choosing whatever password he likes)
For voting machines for example there are *many* documented occurences of the manufacturer stealthily changing the software after the customer had audited one version. No DRM-as-forbidden-by-the-GPLv3 would have helped as they leave the key control in the manufacturer's hands.
For X-rays-machines displaying a "warranty void if uncontroled software uploaded" during the update process is the strict equivallent of the tamper-proof seals which have served the industry well against hardware tampering for years. Again, no DRM-as-forbidden-by-the-GPLv3 is needed.
DRM-as-forbidden-by-the-GPLv3 are the analog of security locks whose keys are kept by the manufacturer (and not distributed with the product). Did you see one of those in actual life ? Stangely this level of protection was never justified in the no-software world, but once it's DRMized it "makes sense"
Laser & DRM Posted Oct 5, 2006 12:54 UTC (Thu) by mingo (subscriber, #31122) [Link] And surprise the GPLv3 actually allows it. The GPLv3 does not allow the use of DRM in a couple of other cases, for example to prevent the tweaking of barcode-reader laser light intensities by shop owners. (As described in a thread before on lwn.net, shop owners frequently requested the manufacturer of such devices to allow the increasing of the intensity of the laser - against work safety regulations - just to increase their efficiency and thus improve the throughput of shops (not caring about the eyesight of their workers).) So this is an example of a case where the GPLv3 would hurt the little guy, and literally so. Again, the reason for the injustice is that the FSF is making the false assumption that DRM is "evil", and that "upstream" providers are doing "evil lock-in", while "downstream recipients" are the "victims". In the laser-scanner case the situation is exactly the opposite: the upstream manufacturer is more moral (and has the larger legal liability), while the downstream "owner of the hardware" is less moral - and the little guy suffers under the GPLv3's DRM provisions.
Laser & DRM Posted Oct 5, 2006 13:18 UTC (Thu) by stijn (subscriber, #570) [Link] In your example, in my opinion, the problem lies with willful violation of safety regulations, not with GPL v3. Making devices tamper proof is a wholly different dimension. Similarly, I don't have root access at the (Debian) workstation where I type this. It is a policy enforced by my employer, orthogonal to the workings of the GPL v2.
Laser & DRM Posted Oct 5, 2006 13:42 UTC (Thu) by mingo (subscriber, #31122) [Link] In your example, in my opinion, the problem lies with willful violation of safety regulations, not with GPL v3. The problem lies in the GPLv3: in essence it declares the "tool of DRM" evil, without leaving for circumstances. It does so by defining the DRM keys to be part of the "Source Code" (see Section 1 of the GPLv3) - and hence forbids the non-release of keys upon redistribution (they are defined into source code, and thus must be released). Without leaving for circumstances (except a limited list of hand-carved exceptions of a currently known good uses of DRM) it's just plain impossible to correctly map all "good" and all "evil" uses of DRM in advance. The GPLv3 allows little for the licensor (or the judge) to weigh circumstances - it forces the decision of "good vs. evil" right in the license. Furthermore, in its public messaging, the FSF does not even allow for the /possibility/ of "good" DRM uses - DRM has been villified in its entirety. This is what i loosely described in other threads as "the GPL now gets into the business of defining good and evil, and it should not do so". To go back to your suggestion: even if there's a blatant violation of safety regulations, if the manufacturer is proven to /not/ have done everything technically possible to protect health, it can be found liable. (there are precedents for that) So a manufacturer, if it cannot use DRM in its laser, X-ray, radio or radar machine might just pick another OS, just to be on the safe side. And even if it's not found liable, the manufacturer's engineers might have (gasp) conscience.
Laser & DRM Posted Oct 5, 2006 14:32 UTC (Thu) by nim-nim (subscriber, #34454) [Link] > To go back to your suggestion: even if there's a blatant violation of safety> regulations, if the manufacturer is proven to /not/ have done everything > technically possible to protect health, it can be found liable. (there are > precedents for that) So a manufacturer, if it cannot use DRM in its laser, > X-ray, radio or radar machine might just pick another OS, just to be on the > safe side.
If the tamper-proofness of the device is so important he should go ROM. DRM is not an absolute protection either.
Laser & DRM Posted Oct 5, 2006 14:38 UTC (Thu) by stijn (subscriber, #570) [Link] Right now I have not yet seen convincing examples where DRM could be Good. In the proposed scenarios the Goodness comes from preventing certain evil things, where to me it seems that those evil things are illegal to begin with and can be prevented by other means, e.g. contract, warranty, ownership, access and probably a few others. The proposed scenarios, as far as I am aware, furthermore have so far been thought experiments. Correct me if I am wrong. As for the "engineer's conscience", we drive cars that are well capable of killing ourselves and other people with a minimum of effort (and the list is neverending), never mind guns.
So on the one hand we have evil DRM marching in on our lives, limiting our rights and taking away stewardship, with no Good specimen yet to be discovered. On the other hand we have the possibility that Good DRM may further our lives at some point in the futures. As far as I am aware, the Good DRM in those scenarios 1) can be replaced by other means and 2) is likely not a definite remedy to the problem it is supposed to solve either.
I appreciate your concern about 'defining good and evil', but the considerations above and the scenarios thus far have to my mind not yet advanced the DRM case.
Then there is the issue whether the DRM clause now makes v3 transcend software by tying keys to the source. The discussions elsewhere have not convinced me that Pandora's box has been opened. It is a view consistent with the four freedoms that Tivoization violates the spirit of GPL v2, although I am still trying to decipher your Tivo/PC/harddisk/binary example elsethread!
Laser & DRM Posted Oct 5, 2006 19:29 UTC (Thu) by drag (subscriber, #31333) [Link] Exactly.
It's like saying:
Hey barcode readers owners shouldn't be allowed to tweak their devices. Therefore the GPLv2 is bad because it doesn't allow people to embed binary-only drivers into the Linux kernel to prevent this!
Also manufacturers are legally obligated to restrict certain frequencies and power outputs on their Wifi cards. The Linux kernel being GPLv2 doesn't allow people to embed binary modules to prevent this and thus GPLv2 is bad.
It's realy kinda silly.
Laser & DRM Posted Oct 5, 2006 13:26 UTC (Thu) by nim-nim (subscriber, #34454) [Link] This particular example is screaming "firmware" at me. Though I don't think the manufacturer would be the one condemned here.
Laser & DRM Posted Oct 5, 2006 15:33 UTC (Thu) by GreyWizard (guest, #1026) [Link] I don't doubt the sincerity with which you present this argument but it makes no sense to me. Either a shop owner owns or does not own the laser scanner. In the first case (as long as the manufacturer properly documents applicable regulations and potential safety hazards) modifications that break the law are clearly the responsibility of that owner. In the second case there is no reason the actual owner can't deploy tamper resistance and anti-DRM licensed software at the same time.
This appeal to emotion with regard to "hurting the little guy" doesn't stand up to reason. There are innumerable ways in which an employer could abuse an employee. Most have nothing to do with software, but an accounting package could accept payments below the minimum wage, cash registers could generate fake errors that the employee is forced to pay for and so on and so fort. Do you propose to address all of these problems with DRM too?
The law already deals with such problems effectively, but if we re-solve them with technology we can force the shop keeper to rent the devices from a third party (possibly the vendor) and use tamper resistance to achieve the same effect. An owner has historically been able to use property in any manner desired without interference from any party other than the government. Why should software change the definition of ownership?
Laser & DRM Posted Oct 6, 2006 2:40 UTC (Fri) by sepreece (subscriber, #19270) [Link] Why do you limit tamper resistance to rented equipment? Many manufacturers attempt to make their hardware tamper resistant, regardless of whether the equipment is intended for sale or rental. For instance, cases may be sealed (the case would be replaced if the item had to be repaired) or may require special tools or techniques to open.
The primary reason for this is liability. If you make a good-faith effort to make it hard to modify your device, you reduce the probability that someone will convince a jury that you negligently enabled a misuse or failure that caused damage.
A secondary reason is reputation. If the user modifies the device and it fails in a way that gets publicized, the press and the public will hear about it as the failure of your device. For instance, newspaper stories about exploding cellphone batteries almost always mention the phone manufacturer; if the retailer or the user has installed an aftermarket battery, that rarely gets mentioned.
The same factors apply to software. Of course, this only speaks to why the manufacturer cares. If user freedom is what matters to you, it may not matter whether the manufacturer has a legitimate reason to want to lock down the software in its devices.
Laser & DRM Posted Oct 6, 2006 7:50 UTC (Fri) by nim-nim (subscriber, #34454) [Link] For those rare cases where you need to be tamper resistant it's easy enough to:1. use ROM 2. use an update jumper located inside the case you've already made tamper-resistent to protect from hardware mods
If you can't afford either, I guess the device is also "protected" with "warranty broken if opened" paper seals or locks with standard keys, so the only reason you're so sold on DRMs is:
Laser & DRM Posted Oct 6, 2006 13:46 UTC (Fri) by sepreece (subscriber, #19270) [Link] There are several scenarios for flash-based software in consumer devices:
- Field upgradeability (adding new features, etc.); this is widely used in music players ["new iPod updater is available"] and set-top boxes. In the former case it's usually the owner doing the update; in the latter case the update is usually pushed by the service provider, more-or-less transparent to the user.
- Field repairs (fixing broken software); this is often included in the kind of upgrades described above; sometimes security updates are done, as for desktop software; again, it's usually either owner-initiated or pushed by the service.
- Customization in distribution; this is very important to the device manufacturers, especially for mobile phones; in this case the phone is flashed with a generic load in the factory and software specific to the carrier and/or market is flashed in distribution or at the point-of-sale; it would be possible to blow an e-fuse at that point to make all or part of the software nonmodifiable after sale, but the user would probably object, since they do sometimes ask for updates after they have the phone. There have been [very] rare phone recalls, but phone upgrades in the field are usually user-initiated.
Note that previous discussions have always centered around "user able to modify" versus "manufacturer able to modify". This ignores the more common real-world case of "user able to have the phone updated" versus "manufacturer able to update phone unilaterally".
Device manufacturers typically have no access to a device in the field [set-top boxes that are updated by a service provider are an obvious exception]. A mobile phone carrier has access, and sometimes uses it to push content updates and service-enablement updates, but generally not to update the base software. In most cases, only the user has the right/ability to initiate a software update. However, their only option is to select another manufacturer/carrier-approved load for their device.
I point this out only because it reshapes the discussion somewhat. The fairness argument has been presented as "pass along the same rights you have". In this case, the situation actually is more like "the end user can choose to upgrade the phone to a newer version of the software", which sounds much less asymmetrical.
Laser & DRM Posted Oct 6, 2006 14:01 UTC (Fri) by nim-nim (subscriber, #34454) [Link] However, as long as the recipient of the software binary and code is in control, the GPLv3 is happy. The reason why very improbable and creative scenarii have been presented so far is the GPLv3 absolutely does not forbid sane uses of signing and cryptography (such as your examples)
Laser & DRM Posted Oct 7, 2006 2:15 UTC (Sat) by mikov (subscriber, #33179) [Link] Even if you are right and the manufacturer is resorting to DRM only because they are dirt-cheap or the device is buggy, it is certainly not the GPL's place to make manufacturers "not cheap" or to force them to sell a high quality product. Manufacturing is a much more complex, difficult, risky and expensive process than many people realize. It is absolutely nothing like releasing software and I feel that many people in their understandable zeal for software freedom are ignoring this, probably because they don't have first hand experience with manufacturing physical goods as opposed to software. Pragmatically speaking, I feel that since GPLv3 cannot fully prevent all restrictions to software modification (as many people pointed out a ROM is an easy option), it should not attempt it all. Further on, even if GPLv3 is ultimately the right thing to do, seeing how it is splitting the community in two before our own eyes, it is very likely to do more harm than benefit (again, as many people have pointed out).
Laser & DRM Posted Oct 7, 2006 12:46 UTC (Sat) by nim-nim (subscriber, #34454) [Link] > Pragmatically speaking, I feel that since GPLv3 cannot fully prevent all> restrictions to software modification (as many people pointed out a ROM is > an easy option), it should not attempt it all.
Pragmatically speaking, I feel that since DRM cannot fully prevent all modifications (as many people pointed out a ROM is an easy option), it should not attempt it all
Liability & Reputation Posted Oct 6, 2006 15:14 UTC (Fri) by GreyWizard (guest, #1026) [Link] Both reasons are unconvincing. Many products are dangerous but cannot be made safer using DRM so the law must find a balance between requirments for manufacturers and end user responsibility. Why should a standard that suffices for makers of guns and baby toys not work for software too? Most people don't believe vendors should be held accountable for specialized changes made by third parties, so this is a public relations problem rather than a technical one.
But all of this is really beside the point. I didn't ask why a manufactuer might want to deploy DRM because that's obvious. Controlling devices after sale allows advanced market segmentation as well as more nefarious things that have been described elsewhere. I am asking if there is a public benefit that might justify the costs of tolerating DRM, not least of which is confounding the age old notion of ownernship which has served society well.
Liability & Reputation Posted Oct 6, 2006 18:55 UTC (Fri) by sepreece (subscriber, #19270) [Link] I didn't actually claim that DRM made the products safer [and, of course, I was talking about Trusted Computer, rather than DRM]. It makes the manufacturer safer by reducing potential liability. In the particular example that started this subthread (modifying the software controlling a laser to increase its output) it presumably would also make the product safer, but that's not really what we were talking about.
You actually asked why software should be different than hardware. I wasn't really arguing that it should. The same kinds of liability and PR issues attach to hardware as well, and manufacturers typically do what they can to avoid user modification of dangerous or regulated hardware, including things like sealing cases, drilling out screw heads, and using sealed modules.
You ask now if there is a public benefit to tolerating locked-down software [I assume that's what you meant by DRM in this context.] For regulated devices, I think there is a clear public benefit; otherwise the devices wouldn't be regulated. Note that here you asking for software to be treated more permissively than hardware, where you had previously asked why they should be treated differently - there are no legal restrictions on manufacturers' ability to make hardware unmodifiable.
You posit commercial and nefarious reasons for manufacturers to deploy DRM. I certainly know of cases where manufacturers have used reversible technical measures (either hardware or software) to downgrade special versions of products, so that they could sell them at lower prices than products without those restrictions. This is sometimes referred to as "slugging". In most cases those have been in situations where there was a contractual relationship preventing the customer from (like the well-known case of the IBM unit-record equipment that could be jumper-modified to be twice as fast]. TC clearly would help the manufacturer avoid customer self-upgrades. I don't consider that to be nefarious (nor qualitatively different from the case where exactly the same end is achieved with a one-way change that makes the device non-upgradeable).
I don't expect to convince anybody who is already convinced in the other direction. If you believe the freedom of your code is paramount, and don't mind that that freedom limits its use in certain kinds of devices, that's your choice.
Public Benefit is the Question Posted Oct 10, 2006 3:44 UTC (Tue) by GreyWizard (guest, #1026) [Link] I was talking about Trusted Computer, rather than DRM Then you were off topic. You comment is a reply to mine which is about DRM. That comment is attached to an article about the GPLv3 drafts which would prohibit distribution of code licensed that way to implement DRM. Perhaps you are confused about what the relevant clauses of the GPLv3 drafts do and suppose that they restrict activities which are not DRM? It makes the manufacturer safer by reducing potential liability. This claim is fanciful in the case of DRM and questionable otherwise. I have some devices which are user servicable and others with comparable purposes which use sealed cases of one kind or another. Do you contend that the manufacturers of the former are more exposed to liability than the latter? I find that hard to believe. Once I take a screw driver to a thing the results are clearly my responsibility, which is why there are sometimes safety warnings on stickers covering the screws. On the other hand I have no trouble believing that liability and public relations are excuses to conceal motives such as market segmentation. Making dangerous things easy might make a manufacturer liable. Failing to make them impossible will not. Generally speaking, making a laser scanner with a knob that allows the output to be set to unsafe levels is a recipe for trouble. Making a laser scanner for which the user can extract the source code, modify that using specialized programming skills, compile and install the result is not. Good luck convincing a court that you did all that accidentally. You ask now if there is a public benefit to tolerating locked-down software [I assume that's what you meant by DRM in this context.] Here is the text you responded to: "I am asking if there is a public benefit that might justify the costs of tolerating DRM [...]" I am pleased that when I write "DRM" you *presume* that I mean "DRM" but I cannot guess your motive for making a fuss about this. For regulated devices, I think there is a clear public benefit; otherwise the devices wouldn't be regulated. What you seem to be saying is that "compliance with appropriate regulations is good" implies "any measure which makes non-compliance more difficult is good." Nonsense. Every check on compliance has a corresponding cost. Requiring a police officer to monitor the use of all laser scanners would make it much harder to use an unsafe power level than merely deploying DRM, but obviously this is not a reasonable solution. So far uses of DRM that don't involve managing digital rights seem like solutions in search of problems. Note that here you asking for software to be treated more permissively than hardware, where you had previously asked why they should be treated differently - there are no legal restrictions on manufacturers' ability to make hardware unmodifiable. You believe I am asking for this because it pleases you to do so, not because I have suggested legal restrictions on locking down software or otherwise proposed some policy. Perhaps you are confused by the phrase "tolerate DRM"? By this I did not mean "allow DRM to be a legal practice" (this community has no power to make that decision) but "permit software that we write to be used to implement DRM" -- in other words reject the relevant provisions of the GPLv3 draft. I have been asking for an explanation of how DRM might benefit the public as well as criticising some examples that seem poorly thought out (specifically voting machines, x-ray equipment, liability and reputation). You posit commercial and nefarious reasons for manufacturers to deploy DRM. A discussion would be easier if you bothered to read before responding. I noted that the reasons manufacturers like DRM include advanced market segmentation (of which your story about "slugging" is an example) as well as more nefarious reasons. I did not offer an opinion on whether advanced market segmentation is nefarious, except to say that more nefarious reasons exist. Anyway, the point of all that was to say that there is no question that some manufacturers like DRM. They do. The issue worth discussing is whether DRM can provide a practical benefit to the public. That your attempts at an answer are muddled nonsense does not prove that a reasonable affirmative case can't be made, so I don't know the answer.
Public Benefit is the Question Posted Oct 13, 2006 2:03 UTC (Fri) by sepreece (subscriber, #19270) [Link] Umm, The topic of the thread was technology used to lock down software so the user/owner can't modify it. That's TC, not DRM. TC is often used in implementing DRM, but is not iteslf DRM, in normal usage.
Your belief that fear of liability is fanciful may make you comfortable, but the corporate lawyers I know disagree with you. And, yes, a device that is user-serviceable carries more potential for liability than one that isn't, other things being equal. I never said it was practical or a goal to remove all risk of liability; that doesn't reduce the impetus to reduce it where the cost is not prohibitive.
"I have been asking for an explanation of how DRM might benefit the public as well as criticising some examples that seem poorly thought out (specifically voting machines, x-ray equipment, liability and reputation)."
Cell phones are a reasonable example of a place where there is a public good in making operating software non-modifiable except by authorized parties. Modified cell phones could be used to disrupt cellular networks that are considered to be public safety assets. As to actual DRM, as opposed to TC, I guess I'd have to ask how you define "public benefit". Is it a public benefit to make content available to consumers that otherwise would not be?
I did not say you said that market segmentation was nefarious, I said you had posited commercial and nefarious raasons. I intended that to mean reasons that were commercial and reasons that were nefarious, but I guess that it was ambiguous.
DRM is the topic Posted Oct 15, 2006 3:05 UTC (Sun) by GreyWizard (guest, #1026) [Link] Umm, The topic of the thread was technology used to lock down software so the user/owner can't modify it. No, the topic is DRM. I should know since it was my comment that started this thread. I said, "Perhaps there are legitimate uses for DRM [...]" and did not mention any implementation technology. Your comment that began this sub-thread is attached to mine, in which I mention DRM twice and Trusted Computing not at all. Finally, this thread is attached to an LWN article titled "Similar in spirit?" which likewise mentions DRM but not Trusted Computing. The controversial GPLv3 draft terms in question would prohibit DRM but not any particular technology. There is no reason to be discussing Trusted Computing in this context. Your belief that fear of liability is fanciful may make you comfortable, but the corporate lawyers I know disagree with you. Are you referring to fear of liability in general? If so, then you are off the mark yet again because I made no statement about that. Here is the text you are responding to: "This claim [that DRM makes a manufacturer safer by reducing potential liability] is fanciful in the case of DRM [...]" If not and you intend to demonstrate that fear of liability caused by leaving out including DRM is reasonable then you must do better than invoking unnamed lawyers who take your position. Can you name one? Can you cite a case in which a manufacturer was found liable for failing to include DRM? Do you even have much weaker evidence like a manufacturer that explicitly claims in a public statement to use DRM for reducing liability? Cell phones are a reasonable example of a place where there is a public good in making operating software non-modifiable except by authorized parties. Cell phones are an excellent example of a technology where openness would benefit the public by unlocking the potential for innovation. Despite the message you are replying to you still ignore the costs of preventing modifications. For good measure you overstate the benefits too: a cell phone is not the only or even the most convenient way to disrupt cellular networks. Cell phone jamming devices are illegal but readily available and possibly even a benefit to the public in some cases. (See http://www.slate.com/id/2092059/ for a thought provoking discussion of this topic.) A case for the public benefit of DRM needs less ambiguous examples.
DRM is the topic Posted Oct 17, 2006 14:11 UTC (Tue) by sepreece (subscriber, #19270) [Link] "in which I mention DRM twice and Trusted Computing not at all"
I apologize. Your note that started this thread mentions DRM twice and "tamper resistance" also twice. One of those uses is in a place where it appears to be paralleled to "DRM". I mistakenly took "DRM" to be mteaning tamper resistance, which I interpreted as TC (locking down the software, as opposed to content). The base LWN article, however, is about TC (anti-Tivoization) as much as it is about DRM.
I am not free to quote or name our corporate lawyers. However, the liability w/r/t DRM would be based on contract conditions with whatever service the DRM was protecting. Similar issues could arise at several levels in a cell phone context (the content provider(s) and the carrier). For cell phones, there would also be potential liability for network damage or interference caused by a modified device. That last liability would be unlikely to end up in court, but would be a factor in negotiations between manufacturer and carrier.
The fact that there are other means of jamming cellular networks is completely irrlevant to the question of whether it's a public benefit to avoid malicious modification of cell phones. The phone itself is a particularly easy and ubiquitous vector for an attack. Note that there are cases of incorrect operation by phones (not modified phones) not just doing local jamming, but bringing down a broader network.
I'm not sure what you're asking for in saying that I'm ignoring the costs. I'm sure there is an opportunity cost in reduced innovation, though I don't think you can quantify it any better than I. On the other hand, contractual requirements with carriers make it, to some extent, a moot point - the level of TC support required by the carriers for tamper resistance is increasing steadily.
Again, I am interpreting "DRM" in this case to mean "tamper resistance", which I take to mean "trusted computing", because that's what you seem to be talking about. DRM (content control) clearly has nothing to do with protecting the network. I agree that it's hard to quantify the public benefit of DRM.
There clearly is public demand for content that the content owners will make available only under DRM. Some of that content is stuff that most people would describe as a public benefit (educational and cultural material). Obviously, there is also public demand for other things that would not usually be considered a public benefit (like pornography), so demand is not a sufficient argument.
Defining DRM Posted Oct 17, 2006 19:20 UTC (Tue) by GreyWizard (guest, #1026) [Link] The base LWN article, however, is about TC (anti-Tivoization) as much as it is about DRM. I'm not sure what you mean by this. The LWN article is about the GPLv3 drafts, which would prohibit the use of covered software in systems that implement DRM. By DRM I mean a system which enforces some software behavior regardless of what the owner might want. This seems to be the conventional definition of the term, so "Tivoization" is DRM. Trusted Computing is a technology with which DRM and possibly other things can be implemented. Since the GPLv3 drafts would affect Trusted Computing only when it is used for DRM I still don't see how it can be relevant. However, the liability w/r/t DRM would be based on contract conditions with whatever service the DRM was protecting. DRM clearly has advantages for the businesses who control the keys in the same way censorship is an advantage for those implement it. The question is whether a free software license should attack DRM. I don't propose to answer that question but clearly contracts between vendors are not relevant. The fact that there are other means of jamming cellular networks is completely irrlevant to the question of whether it's a public benefit to avoid malicious modification of cell phones. On the contrary, the availability of jamming devices demonstrates that cell phone network disruption is not a serious problem in practice. Consider an analogy. Some programmers create malicious software that attacks exposed internet services. Wouldn't there be a public benefit to regulating compilers and using DRM to embed identifying information in all source code? This way people who do harm could be discovered and punished. Isn't the availability of unauthorized compilers completely irrelevant to the question of whether this would be beneficial? I'm sure there is an opportunity cost in reduced innovation, though I don't think you can quantify it any better than I. I'm not asking you to quantify it exactly but to think through the consequences. DRM doesn't seem to accomplish anything for cell phone network robustness that couldn't be done more effectively with proven technology, but it clearly creates problems. Gloves can be used to avoid leaving fingerprints at the scene of a crime, but we don't insist they be registered. Cryptography can be used by criminals for conspiracy, but this is not a strong enough reason to keep it out of the hands of legitimate users. For the same reason, we should not insist on preventing people from changing a cell phone operating system merely because we can imagine disruptive uses. There clearly is public demand for content that the content owners will make available only under DRM. There is no shortage of educational and cultural material on the market and the notion that content owners are sitting on an enormous pile of it that they will only release when the playing field is tipped still further in their favor is often presented by certain trade associations but is always unescorted by evidence. We've reached the point of diminishing returns on that strategy. Distributing material under copyright without the consent of the owner is already illegal and successful enforcement happens all the time, often without the need to go to court. Indeed, enforcement is so easy that legitimate uses are often suppressed. Denying people control of their own computers is not going to improve this situation.
Defining DRM Posted Oct 18, 2006 22:20 UTC (Wed) by sepreece (subscriber, #19270) [Link] "By DRM I mean a system which enforces some software behavior regardless of what the owner might want. This seems to be the conventional definition of the term, so "Tivoization" is DRM."
I haven't heard "DRM" used this way other than in this discussion of GPLv3. The conventional use of "DRM" is for content control (management of access rights to content). That was my point (and I'm not the only one who has tried to make that point in both this discussion and in the Busybox discussion that was on the same LWN front page). Locking down software is TC, not DRM.
"clearly contracts between vendors are not relevant"
All I can say is, it's not irrelevant to the companies that make consumer electronics, nor to the people who want to buy content despite the DRM that the content owners require. You are, of course, free to consider that they are irrelevant.
"we should not insist on preventing people from changing a cell phone operating system merely because we can imagine disruptive uses."
Well, we DO choose to ban or control some things with dangerous or disruptive uses. So far, the manufacturers, the carriers, and the FCC are on the side of controlling this one. If you can convince them otherwise, then arguing about the GPL would be unnecessary. Changing the GPL isn't a high-leverage approach to convincing them.
"Denying people control of their own computers is not going to improve this situation."
Generally, they're not being denied control of their computers, even if you buy the argument that a cellphone should be considered a computer. They're being denied the ability to access services with untrusted clients. That seems to me to be within the purview of the service providers, regardless of the ownership of the device.
DRM, DRM, DRM Posted Oct 19, 2006 3:05 UTC (Thu) by GreyWizard (guest, #1026) [Link] The conventional use of "DRM" is for content control (management of access rights to content). And in what way does this statement contradict mine? Tivo clearly employs DRM for content control. That the conventional use is content control does not deny the possibility of other uses. The LWN article seems to agree with me, as it refers to the GPLv3 draft provisions that would affect Tivo as "anti-DRM provisions" several times. Locking down software is TC, not DRM. First, Trusted Computing is but one technology for locking down software. See http://en.wikipedia.org/wiki/Trusted_Computing for more details. Second, locking down software can be done under the control of the hardware owner or some other party. Since the GPLv3 has no effect on the former case it should be clear that locking down software in general is not what is at issue. We need some term that expresses only the latter. DRM seems to be that term as far as I can tell (though of course DRM can be implemented less effectively without hardware), but if that usage offends you propose another term that doesn't confuse the issue in this way. All I can say is, it's not irrelevant to the companies that make consumer electronics, nor to the people who want to buy content despite the DRM that the content owners require. You are, of course, free to consider that they are irrelevant. Here is the text you were responding to: "The question is whether a free software license should attack DRM. [...]clearly contracts between vendors are not relevant." In what way is it unclear that "relevant" means "relevant to the question" in this case? Replacing the plain meaning of those words with the notion that companies making consumer electronics and the people who buy them are "irrelevant" in general is either an incredible failure of comprehension or outright intellectual dishonesty. Well, we DO choose to ban or control some things with dangerous or disruptive uses. Cell phone disruption is generally much less dangerous than guns or drugs, to choose two such things over which there is much disagreement. The preferences of established economic powers and the politicians they patronize does not demonstrate that strict regulation in the specific case of cell phone operating systems would be appropriate or reasonable. Changing the GPL isn't a high-leverage approach to convincing them. Some people would dispute this claim and many who wouldn't still find ensuring that their software is not used to implement DRM reason enough. But this is a larger issue than the one raised by this thread, which is merely whether DRM has advantages for society as a whole. Generally, they're not being denied control of their computers, even if you buy the argument that a cellphone should be considered a computer. I wrote about "denying people control of their own computers" in response to your claim that there is "public demand for content [...]available only under DRM" which was not specifically about cell phones. That said, while one might plausibly argue that control of a cell phone operating system is unimportant or that cell phones are such special purpose devices that freedom is not useful enough to defend (we'll have to agree to disagree on these points) the ability to replace cell phone operating system software is undeniably a form of control and a modern cell phone is most definitely a computer. Since you've forced me to revisit this, I wish I had noted in my last message that claiming DRM is good for the public because content owners will only release things the public wants under those circumstances is circular reasoning. Suppose the public wants cultural or educational content owned by an organization that refuses to release it without a human sacrifice. Does this demonstrate that human sacrifice is good for society?
Laser & DRM Posted Oct 6, 2006 12:22 UTC (Fri) by man_ls (subscriber, #15091) [Link] The GPLv3 does not allow the use of DRM in a couple of other cases, for example to prevent the tweaking of barcode-reader laser light intensities by shop owners.How come changing the intensity of a laser is "DRM"? Where are the "digital rights" that are managed? Those of the employee, those of the employer? Sorry, Ingo, but you are tweaking your meanings once again; you are presenting another example of "Trusted Computing" as defined by Microsoft et al, or of a Trusted Platform Module (TPM). Not DRM. The difference is important and crucial to this debate. For a TPM, the key might be set by the owner at the time of purchase and changed whenever was thought necessary. For DRM the key must stay in possession of the manufacturer / developer. A TPM is a possible solution to the problem presented, even though technically it is not very good (allowing software to change laser intensity above a certain level is probably a bad idea). DRM is not a possible solution. Note that the FSF is against "Trusted Computing" (Stallman calls it "Treacherous Computing") as well as against DRM. Again, the reason for the injustice is that the FSF is making the false assumption that DRM is "evil", and that "upstream" providers are doing "evil lock-in", while "downstream recipients" are the "victims".This distinction is the very essence of DRM. Corporations distributing "content" to passive consumers.
Laser & DRM Posted Oct 6, 2006 13:59 UTC (Fri) by sepreece (subscriber, #19270) [Link] While I completely agree that the distinction between DRM and Trusted Computing support is important, and actually pointed it out in a comment in one of these treads yesterday, it's wrong to point at Ingo as the source for confusing them. The blame for that confusion is pretty much universal. Stallman has done it, the kernel developers did it in their statement. Ingo was just using "DRM" as it has been widely used in the multiple discussions over the last couple of weeks.
Use vs distribution Posted Oct 5, 2006 3:47 UTC (Thu) by proski (subscriber, #104) [Link] These provisions are a new restriction on how the software can be used, and, thus, are not "similar in spirit" to GPLv2.I think this stance is highly inaccurate. Nothing prevents a hardware manufacturer from using software under GPLv3 internally. It's only when third parties are involved that the "anti-DRM" provisions come into effect. If I'm using a Nokia phone on the Cingular network, who is the user? Maybe Cingular, but not Nokia. If I'm playing a game on that phone, who is the user? Definitely not Nokia.
Use vs distribution Posted Oct 5, 2006 12:35 UTC (Thu) by mingo (subscriber, #31122) [Link] Nothing prevents a hardware manufacturer from using software under GPLv3 internally. It's only when third parties are involved that the "anti-DRM" provisions come into effect. [sarcasm] The anti-DRM provisions come into effect "only" when third parties are involved, for example third parties to whom the hardware manufacturer wants to distribute its products to: like paying customers. Nah, never mind, lets ignore this minor special-case, you are right, why should it matter to anyone! [/sarcasm]
Use vs distribution Posted Oct 5, 2006 21:17 UTC (Thu) by proski (subscriber, #104) [Link] Actually, the goal of GPLv3 is to make customers buying products with DRM a minor special case. Something akin customers buying a Ferrari with a governor set at 50 mph :)
Use vs distribution Posted Oct 5, 2006 15:47 UTC (Thu) by sepreece (subscriber, #19270) [Link] The "use" argument is from the overloading of a common word with specific legal meaning. Most people would say "Yeah, I used Linux in our new product." even though that particular "use" also involves distribution. I don't have better language to suggest, but it's unfortunate that the confusing usage gets in the way.
"If I'm using a Nokia phone on the Cingular network, who is the user? Maybe Cingular, but not Nokia."
It's important to note that in the given example, it's typically Cingular, not Nokia, that is the distributor to the end user. The manufacturer typically does not have the ability to modify the phone in the field, the carrier does. Similarly, most DVRs are not upgraded by the manufacturer, but by the cable/satellite operator that provides them to the customer. This doesn't really alter the argument (the distributor is usually just passing through stuff that the manufacturer provided to it), but it's good to describe the situation correctly.
This week in history. Posted Oct 5, 2006 4:27 UTC (Thu) by neilbrown (subscriber, #359) [Link] What ever happened to the "This week in History" that was introducedin the 1st June 2000 issue of LWN mentioned in this article?
Last year: The boardcast flag is back? and Wine approaches its first 'beta' rlease.
Two years ago: Redhat acquires various Netscape software.
Hmmm. maybe 2 year old news just isn't interesting any more :-)
This week in history. Posted Oct 5, 2006 12:55 UTC (Thu) by corbet (editor, #1) [Link] It went away because we just didn't have the time to do that and do this week's news too. I'd sure like to have it back, someday...
Similar in spirit? Posted Oct 5, 2006 7:44 UTC (Thu) by ortalo (subscriber, #4654) [Link] There is another problem I foresee with locked down embedded systems. Their producers may make false claims about their device (especially in the security area) while simultaneously denying us the ability to make counter claims.This is not very annoying in the DRM area. We don't really bother if our media player, our TV box or our children play station has some vulnerability that may defeat the device security and that the vendor does not want to disclose for mere marketing reasons. But there are other areas where we do care about this: who really knows about the (internal) security of smart cards, of mobile phones, of voting machines, of public institutions databases, of embeded devices driving our car's braking system, or our plane network system, even today? Don't you think believing vendors security marketing without them delivering any factual guarantees (not to speak about the original source code) is playing Candide? And whatabout tomorrow when all these systems will become even more open and more generalized? The same vendors or institutions that try to hide their own vulnerabilities may be those who will adopt Linux under the cover tomorrow. I am tempted, like the FSF probably, to remind them that this implies more than just swapping their actual (possibly deficient) software platform.
Similar in spirit? Posted Oct 5, 2006 15:51 UTC (Thu) by sepreece (subscriber, #19270) [Link] I'm not sure what your point is. The argument is about requirements that affect whether modified code can be installed in the device by the user, NOT about visibility of the code. I think the GPLv2 and GPLv3 sub-communities agree completely on the requirement that source code for modifications to GPLed code must be available to users.
Check the provided sources Posted Oct 6, 2006 13:57 UTC (Fri) by man_ls (subscriber, #15091) [Link] Not having the crypto keys might prevent the owner from knowing what is inside the device, e.g. to verify that the program was actually built from the provided sources. But you are right, it seems a bit far-fetched.
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 13:17 UTC (Thu) by mingo (subscriber, #31122) [Link] Another area in the GPLv3 where i see significant departure from the spirit of the GPLv2 is the issue of whether the GPL controls "other, independent works" not based on any GPL-ed code. The GPLv2 speaks very clearly about this in Section 2: Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. This language is not present in the GPLv3, and indeed the GPLv3 tries to extend its reach to certain works not created by us and not based on any GPL-ed code: parts of the hardware (certain keys). For now. While this might sound like a technicality, it corrupts a core principle of the GPLv2 and opens up the floodgates: it fundamentally changes the simple, powerful and fair "we give you source code if you give back all source code based on this code" rule to something that is open-ended. We needed 10 years to convince developers that the GPLv2 rule is fair and square, we lived for 15 years with this property of the GPLv2 and participated in the writing of a huge, more than 1 billion lines of code GPL ecosystem, so the bargain should not be changed now, without our consent. No-one on the FSF side so far was willing to limit the scope of this change. For example will future versions of the GPL attempt to prohibit non-GPL-licensed works to be distributed together with GPL-ed works? This open-ended isolation of the GPL ecosystem, at the behest of the FSF, is just as dangerous (if not more dangerous) than the whole DRM language. Or as Linus has said it on lkml, more than 6 years ago: There's been some discussions of a GPL v3 which would limit licensing to certain "well-behaved" parties, and I'm not sure I'd agree with such restrictions [...] Linus has been consistent on that ever since, and that fundamental objection of him still stands. No amount of participation in the GPLv3 process seems to have removed this fundamental flaw from the GPLv3, in 6 years of "consultation".
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 14:20 UTC (Thu) by cventers (subscriber, #31465) [Link] Ingo, (once again, I've got nothing but respect for you, but I don't agree with your take on this at all...) I don't think the reach is extending beyond even what the GPLv2 says. 'Intent' is a word about why something was done a certain way. And I think that there are still plenty of us who believe that the Intent of GPLv2 was very clearly to preserve Freedoms 0-3, especially given that the entire opening section of the license persists of talking about these freedoms: When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. Some people seem to assume that the Free Software Foundation is trying only to make political moves or statements. But unfortunately in our current world it is becoming clear that some kind of anti-DRM language is needed to preserve Freedoms 0-3. Freedoms 0-3 is what the license is really about. It's not tit-for-tat, as Linus calls it. It may have the tit-for-tat property, or the fair and square property, but it is a free software license and it's frankly delusional to try and call it anything else. What Linus says about "well-behaved parties", at least as much as you have quoted, has implication but no substance. In a sense, GPL has always limited licensing to well-behaved parties - the parties that don't seek to undermine free software! That's why we have a GPL in the first place. If the license didn't aim to stop people from undermining free software, it would have no reason to exist -- everyone could just use BSD. DRM vendors, whether incidentally or intentionally, are moving on a path that can undermine what we've all worked so hard for. If the Linux developers or any other community don't want to stand in their way, that's totally okay. But please recognize that as one other astute LWN reader said in another comment on another thread, we won't help them build the jail with our own code! It's a free software license from the free software foundation. But even so, they want your participation. I never really got a reply from you earlier, but I'm pleading with you to take this LWN comments discussion straight to the FSF and to bring some of the other kernel developers with you. The FSF wants your participation, even if that means disagreeing with them. Even if they don't strike down everything you disagree with, you are passing up an opportunity to get involved in the official drafting process which is definitely open. If you don't take the opportunity, you're (no offense) no better than people who moan loudly about how bad the politicians suck and then sit on the couch on voting day. For crying out loud, Sun Microsystems says the process is open, and they say they like this new license! And we just learned yesterday that Nokia also seems to be happy, and says that the DRM provisions in GPLv3 were 'clarified' for them, leaving the impression the license is well on the way to being agreeable by nearly all parties. ...except the kernel developers, the one community that pointed out it can't use GPLv3 even if it wanted to. What kind of bizarro world is this? Why won't you get officially involved?
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 15:02 UTC (Thu) by mingo (subscriber, #31122) [Link] Thanks for your comment. (Please read my reply in its entirety, even if you dont agree with sections of it, it's a complete whole and any counter-arguments should consider the totality of my opinion. Thanks!) that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. The contention that this somehow turns into a "right to tweak the hardware" is false. The term "right to tweak" has been invented well after the GPLv2 was released, well after Linus released Linux under the GPLv2, and well after i chose to contribute under the GPLv2. I reject such a retroactive interpretation of a pretty clear license. If you look at the plain language of the GPL sentence you cite above, it is a recitation of the exclusive rights authors have under the Copyright Act: the right to create and distribute copies, the right to modify and derive code. See USC 17 / 106. The "receive" stands for distribution, "change the software or use pieces of it in new free programs" means the exclusive right for modification and derivation. No-one in their right mind, neither i nor Linus ever understood that plain langugage to mean: "you have to allow to make binaries in ROM's modifiable". IMO that interpretation is often just wishful, revisionist thinking, possibly created by "oh what should we do about this DRM thing" thoughts. But note that the section you cited talks about source code (i highlighted that in the quote above). Tivo gives out their modified kernel source code (a derivation of the kernel), and gives you the rights to use, modify and derive Tivo's added work freely. Tivo also gives you the right to distribute copies. Tivo completely lives up both to the moral and to the legal deal. What it does not give you is a totally separate piece of work: the hardware's keys. (That is, by the way, also a conflict in the position of the FSF: for decades they insisted that the GPL is a license, not a contract. But only a contract can affect works that are not covered by copyright law! So what is the GPLv3 now, a license or a contract?) The contention that DRM and using crypto keys to protect hardware integrity is somehow new is false too. Intel has been using DRM since ~1996, ever since they made their microcode uploadable. RMS has been using it probably every day in the past 10 years or so, and he probably didnt even realize it. Would you want to run CPU microcode "modified" by a friendly virus writer? What if the CPU is based on a GPL-ed work, such as: this GPL-ed CPU design? IMO this whole thing that to me appears to be a vendetta against DRM is largely misplaced and wastes our resources. And i'm asking, if it is this hard to make such a relatively simple issue understood by the FSF, if it's so easy to turn it into a nasty emotional and political issue, how will we be able to deal with more complex issues? I believe that in the light of this debacle the only sane and morally correct solution would be for the FSF to voluntarily give up power (which power is quite similar to unilateral relicensing power over a huge codebase), and to remove the "or later" language from the default COPYING file. Leave it up for authors to explicitly chose this if they trust them on it. In fact: the FSF, just like Linus, should reject blanket authorizations of trust, like an open-ended "or later version" language. Dont let inertia and laziness drive an important decision like that. That way authors of new code can judge the licenses on their merits once they are released, and the FSF can release new licenses at a much faster pace. "Release early, release often" applies here too.
4 points Posted Oct 5, 2006 15:17 UTC (Thu) by coriordan (guest, #7544) [Link]
Tivo and point 4 Posted Oct 5, 2006 22:15 UTC (Thu) by zlynx (subscriber, #2285) [Link] Quick note on your point 4:The keys are not required for the work to run. Take Tivo for example: a Tivo binary should execute just fine on some other non-Tivo PowerPC based system.
So what the keys do is prevent executing a binary on a particular piece of hardware, not prevent executing it at all. At least, in the Tivo case. An encrypted binary, rather than a signed one, would be a different situation.
So it seems the key is a part of the hardware, not the software, and thus a separate work.
It's just like having a Linux or HURD (since Linux is staying GPLv2) kernel executing from a virtual machine. If I restrict the execute permissions of the kernel's VM image to a single user, is that user's login password suddenly a "part of the work" required to run the kernel? Ridiculous.
A better example yet, say I build a HURD kernel just the way I like it and take it's SHA1 key. I customize a copy of QEMU to only run if the boot image matches that SHA1 key. Your copy of my image isn't affected. You just can't run a modified version on my QEMU.
Tivo and point 4 Posted Oct 6, 2006 10:57 UTC (Fri) by nim-nim (subscriber, #34454) [Link] > So what the keys do is prevent executing a binary on a particular piece of> hardware, not prevent executing it at all.
That's assuming availability of non-DRMed hardware. This is not a safe bet, especially if the existing software pool can be DRMed at will.
Tivo and point 4 Posted Oct 6, 2006 16:10 UTC (Fri) by man_ls (subscriber, #15091) [Link] Take Tivo for example: a Tivo binary should execute just fine on some other non-Tivo PowerPC based system.If I had purchased a Tivo and it had some serious flaw which the company did not want to fix, it would not help much to know that I could execute it on some other piece of hardware. The keys are part of the particular software distribution, which is contained in the Tivo. You could have another type of hardware, another distribution So it seems the key is a part of the hardware, not the software, and thus a separate work.Hardly. I could make the same argument about a particular driver: my Linux kernel might run just fine without the driver, on a different hardware configuration. Therefore the driver is part of the hardware. The key is just a magic number. It is required to install and run the software on a particular piece of hardware. Providing source code but not the magic number is cheating IMHO.
4 points Posted Oct 6, 2006 9:26 UTC (Fri) by mingo (subscriber, #31122) [Link] There is nothing in GPLv3 to "make binaries in ROM's modifiable", I don't know where you're getting that from.You are misrepresenting what i said. If you read my comment, i was talking about the language in the GPLv2, which language someone else suggested means that "the right to tweak" was somehow embedded in it. When Linus and i adopted the GPLv2, the GPLv3 draft and the term "right to tweak" did not exist yet, and i resist revisionist interpretation of the GPLv2 license. Please re-read my ROM point with that in mind, and consider that i'm interpreting the GPLv2 license: The "receive" stands for distribution, "change the software or use pieces of it in new free programs" means the exclusive right for modification and derivation. No-one in their right mind, neither i nor Linus ever understood that plain langugage to mean: "you have to allow to make binaries in ROM's modifiable". IMO that interpretation is often just wishful, revisionist thinking, possibly created by "oh what should we do about this DRM thing" thoughts. Thanks.
4 points Posted Oct 6, 2006 9:51 UTC (Fri) by mingo (subscriber, #31122) [Link] "DRM is not new" - GPLv3 doesn't prohibit DRM, it prohibits tivoisation (one particular use of DRM). Firstly, did you read the article you are replying to? In particular the bit where Richard Stallman is quoted as saying: I'm less concerned with what happens with embedded systems than I am with real computers. The real reason for this is the moral issues about software freedom are much more significant for computers that users see as a computer. And so I'm not really concerned with what's running inside my microwave oven.The Tivo is not a general purpose computer pretending to be freely modifiable. The Tivo is a PVR (Personal Video Recorder), a special-purpose specialized appliance, not much different from a microwave oven. Secondly, i never claimed the GPLv3 prohibits "all" forms of DRM - not even the FSF is /that/ out of touch with reality. But if for example Intel based any parts of its microcode on GPL-ed code, and even if they released the source code and met the GPLv2 bargin in every way, the GPLv3 would require them to either stop using the GPL-ed microcode, or to share the DRM key with the public at large (which includes our friendly virus writers). What you and the FSF is missing is that there are lots of legitimate cases where the "desire to trust a piece of hardware" overrides the "desire to modify hardware". A blanket "freedom must always override physical trust" characterisation can only be true in a society where laws are /always/ fair and are always enforced and acted upon. Such a society does not exist.
4 points Posted Oct 6, 2006 12:16 UTC (Fri) by alexbk (subscriber, #37839) [Link] Much better case than a Tivo would be latest Nokia phones, which *are* general purpose computers that happen to have smaller than normal screens and keyboards. These phones also have a sophisticated mechanism for verification of installed applications called Symbian Signed. That mechanism ensures that only Nokia and vendors approved by them can write software that does interesting things such as getting coordinates from built-in GPS receiver or working with the phone's microphone and speaker. They can legally use GPLv2 software to do that, and keep the keys to themsevles. Saying "don't buy the phones if you don't like that" is not really an option - there are no other devices that offer similar functionality.
Also, when you say "desire to trust a piece of hardware" you should be more specific - who has that desire, and who owns the hardware?
4 points Posted Oct 6, 2006 14:15 UTC (Fri) by sepreece (subscriber, #19270) [Link] "Saying "don't buy the phones if you don't like that" is not really an option - there are no other devices that offer similar functionality."
I would argue both with the statement (there are devices with similar functionality from other manufacturers) and the apparent conclusion that the uniqueness of a particular device would somehow create a special obligation to allow you to modify it. If you don't like what the device allows, don't buy it. It's not life-critical that you own one.
Note that there is no real asymmetry here, either. Only you (or someone you have authorized, like your service provider) has access to the device to load software into it. Nokia can't, because it has no access (unless you take the phone in and ask them to). You can choose to load various software into it, but that software comes from a constrained set. That's different from "you can modify the software but I can't".
4 points Posted Oct 6, 2006 15:30 UTC (Fri) by alexbk (subscriber, #37839) [Link] Uhm, you seem to have misunderstood me. My point was that if Ingo thinks Tivo is a bad example because it's only a narrow-purpose appliance, I can give a different and hopefully better example of an increasingly popular (24 million units shipped H1 2006 vs 14 million in H1 2005) general purpose programmable computer running Symbian OS, where access to some (but not all!) important APIs and hardware peripherals is restricted.
The manufacturers don't have an obligation to give me that access of course, but then I don't want them to use and modify my code for their benefit *and* disallow everyone else including me to do the same thing. Once again: they're not producing a Tivoesque appliance but a real computer. Nothing to do with demanding freedom to tinker, everything to do with being fair.
If you know similar devices that are less restricted, please name them, I always want to know about new gadgets :)
Stallman's quote in real context Posted Oct 6, 2006 14:27 UTC (Fri) by cventers (subscriber, #31465) [Link] Ingo,
I hesitate to reply to you here because you still haven't addressed any
It's interesting that you quote Stallman here, and so has Jonathan. I
To quote Stallman further:
> But I don't think that's where the social and political issues arise.
The Tivo is a good deal different from a microwave oven because its
is one of countless sites on the subject that Google presents when
I don't think a microwave oven would be likely to ever fall into this
But it's not just Tivo we should be worried about. Think about another
This project is a GPL-licensed firmware replacement for MP3 players from
I hope I'm not the first free software developer to ask this question,
How long before the manufacturers of MP3 players realize they can take
I know you're not a Rockbox developer. Neither am I. But since you argue
Despite Stallman's great crystal ball, it seems the world still changes
And I further hope that you won't drop the other thread of discussion we
Stallman's quote in real context Posted Oct 6, 2006 14:32 UTC (Fri) by cventers (subscriber, #31465) [Link] Ah, I made a goof. When I said:
> How long before the manufacturers of MP3 players realize they can take
I should have said 'changing the software.'
But the goof may raise an interesting counter-argument, 'the GPLv3 cannot
Stallman's quote in real context Posted Oct 7, 2006 3:01 UTC (Sat) by sbergman27 (guest, #10767) [Link] Just to give you some credibility, could you please post a link to some code which you have released under GPLv2 which will be automatically colicensed under GPLv3 when it is released?
Or are you simply in this to push your politics?
Could you pass the red herring please? Posted Oct 7, 2006 7:10 UTC (Sat) by cventers (subscriber, #31465) [Link] I will not participate in any attempts to turn what is hopefully aninsightful discussion into a pissing match. And I almost did. I was in the process of tarballing up some unreleased (as in prealpha) stuff I've been hacking on for months, but I realized that it would be a poor waste of my time to divert in order to satisfy this red herring you are now attempting to serve. Incidentally it appears that the GPLv3 will be ready by the time I issue an alpha release of my server software and its supporting 'C' library. And I fully intend to skip the relicensing step and move straight to version 3, especially because I think the new anti-DRM provisions might be specifically relevant to some things I'm currently doing. I promise of course that I would have fully appreciated the opportunity to automatically relicense had that been a necessity. I argue now because Ingo proposes to deny me the chance to vote with this new code of mine at all. He seems to want this license development stopped. I don't think Ingo would succeed in stopping the process, but I speak as someone who cares deeply about that process and as someone who will absolutely engage in code release under GPLv3, and who would rather do that release under GPLv3 than the less good (but still quite good) GPLv2. Notice that I'm specifically avoiding telling him what I think he ought to do with his stuff, or you with yours, because I have no stake in that. I have no doubt in my mind that your next reply will criticize me on the grounds of not having published code about to undergo relicensing. Since that is surely your intent, fire away and enjoy. Credibility is a funny thing - it is the first and last thing people like to attack when they can find absolutely no other argumentative point of substance. You accuse me of politics when attacks on credibility rather than reasoned analysis are most often performed by the dirtiest of politicians. So I'll ask you to pardon me if I roll my eyes while you are busy adding your two cents to this conversation. But I promise that I won't do that if you instead decide to say something of substance.
Stallman's quote in real context Posted Oct 7, 2006 8:23 UTC (Sat) by stijn (subscriber, #570) [Link] That is a very poor diversion. Ad hominem. Now for your arguments please.
4 points Posted Oct 6, 2006 10:10 UTC (Fri) by mingo (subscriber, #31122) [Link] Removing "or later versions" would lead to many new free software projects later arriving in the same mess the Linux copyrights are in. If an absurd interpretation of GPLv2 was ruled valid by a court tomorrow, what would Linux do? It would have to relicence and it would be a mess. FSF foresaw this mess decades ago and put two infrastructures in place. One is the "or later versions" language, another is the copyright assignment for GNU projects. two quick points. Firstly, i have heard this "what if the GPLv2 is ruled unenforceable" boogeyman a number of times. It is just not happening. What is happening is that the GPLv2 is alive and kicking and enforced (and even litigated) in lots of important jurisdictions. A healthy number of precedents have built up in Europe for example, and in the US 99%+ of the defendants rushed into settlements without even thinking about a trial. Judges in Germany, the US and elsewhere are showing a clear and deep understanding the GPL and the obligations attached to it. Please think about it, and dont just accept the FSF's position at face value. Please show some critical thinking. On one side of the equation are more than 1 billion lines of code, worth tens of billions of US dollars, given away for free, with a few common-sense conditions attached to it, described in very clear words (in the GPLv2) that is easily translated to many languages, and which has been enforced to the true letter and intent of that license in important jurisdictions. On the other hand we have the theoretical worst-case possibility of some other jurisdiction suddenly growing an "absurd" interpretation of the GPLv2, which, i assume, would mean the forfeiture of the whole codebase and its putting into the public domain. What is better protection against absurdity than the plain and clear language of the GPLv2. Secondly, what kind of judge do you think would do that to a body of work that has such a huge value, which wouldnt immediately be overturned on appeal? Judges are often amongst the fairest and most objective people in most societies (even in dictatorships), and the law is based on thousands of years of history of fairness. I trust judges a lot more to interpret my license than i trust a mathematician that is currently presiding the FSF ... Secondly, it is a false dichotomy to suggest that the only option is a total rewrite of the GPLv2. There are lots of options. The FSF could add a limiting language like: "if any portion of the license becomes unenforceable then we reserve the option to correct that language, with the minimal amount of changes needed to make it enforceable again". Problem solved via GPLv2.01. But i get the feeling that giving up power and letting the community go is quite hard for Richard Stallman to do ...
The crux of the issue Posted Oct 6, 2006 14:52 UTC (Fri) by cventers (subscriber, #31465) [Link] Ingo,
(I shall include by reference my request made elsewhere that you return
> Firstly, i have heard this "what if the GPLv2 is ruled unenforceable"
You're right. GPLv2 is a strong license. And I think no one does a better
> Please think about it, and dont just accept the FSF's position at face
You know Ingo, it is perfectly valid for you to hold an opinion on this
Attorneys don't sit around passively and react to situations; part of
No matter how unlikely you think it is that GPLv2 could ever fail to do
Once again, it is important to realize that Linux, a largely Western
So I think it's damn essential that the GPL not only defend our software
Once again, Ingo, you have the full right of not using GPLv3, and I have
> On one side of the equation are more than 1 billion lines of code,
I find it interesting that you keep referring to the large body of GPL
But when it is the FSF proposing to defend those billions of lines of
So you don't want the FSF - the drafters of the GPL license, the
Mr. Molnar, I'm beginning to suspect the reason you haven't replied to
4 points Posted Oct 7, 2006 4:28 UTC (Sat) by bojan (subscriber, #14302) [Link] > The keys needed to run a piece of software are not a "totally seperate work". If the two were not intertwined, they would not have the relationship of one being necessary for the other to run.
Actually, the keys are most likely not a "work" in terms of copyright at all. I would say too unoriginal. I doubt one could obtain copyright on any kind of cryptographics keys.
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 16:00 UTC (Thu) by cventers (subscriber, #31465) [Link] Ingo,
Thanks for the response. To continue:
> The contention that this somehow turns into a "right to tweak the
Well, let's be careful about what we're talking about here. I agree with
By contrast, the anti-DRM provisions say "don't use technological means
So it's really not about the right to tweak the hardware at all. It's
> The term "right to tweak" has been invented well after the GPLv2 was
Well, I'm not using "right to tweak" as the language and I don't think
- The freedom to run the program, for any purpose (freedom 0).
We are talking about freedom #1. The Tivo device (sort of) adheres to #0,
And if you're thinking "ROMs don't provide #1 either", you're right. But
> No-one in their right mind, neither i nor Linus ever understood that
I don't think "you have to allow to make binaries in ROM's modifiable" is
> But note that the section you cited talks about source code (i
As stated, Tivo doesn't respect freedom #1. Putting in a crypto
> (That is, by the way, also a conflict in the position of the FSF: for
It's still absolutely a license. It doesn't affect hardware where the
> The contention that DRM and using crypto keys to protect hardware
I suppose you're right about the microcode example; thanks for the
The virus writer example goes too far. My reason is an analogy on free
> IMO this whole thing that to me appears to be a vendetta against DRM is
Vendetta against DRM? That's absolutely true. But I guess what is hard
> I believe that in the light of this debacle the only sane and morally
I don't see why. I know you don't agree with them now, but you agreed to
And I also think that your "sane and morally correct solution" assumes
The FSF is not releasing a new GPLv3 that says "You may have this code to
Or are you worried that the GPLv3 is going to catch on, and you
> and to remove the "or later" language from the default
But that language is there for a reason, as a utility! It _is_ and has
I resent this notion that programmers are so lazy as to ignore the
Perhaps there are some developers, in a minority, that did so and are now
> In fact: the FSF, just like Linus, should reject blanket authorizations
Well, I trust the FSF, but that's a philosophical argument for another
> Dont let inertia and laziness drive an important decision like that.
Ingo, if people are that prone to inertia and laziness, we're all
> That way authors of new code can judge the licenses on their merits
They can do that today. They can do as Linus has done, and state "GPLv2
And that is absolutely letting the authors decide. At that point if
> and the FSF can release new licenses at a much
If the FSF releases licenses at a faster pace, that is a sign that
You might be tempted to speak as Linus has here - "The GPLv2 has no
You mention "release early, release often". One of the big reasons for
Why, Ingo, aren't you getting involved?
(sorry if that grates on your nerves, but I do think it's a fair
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 19:14 UTC (Thu) by AJWM (guest, #15888) [Link] > Why, Ingo, aren't you getting involved?
> (sorry if that grates on your nerves, but I do think it's a fair question...)
Considering the volume of messages on this subject I've seen here from Ingo, and their thoughtfulness, I'd say it was neither a fair question nor a very intelligent question.
He is involved. Just apparently not in the manner that you'd like him to be.
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 19:28 UTC (Thu) by cventers (subscriber, #31465) [Link] Pardon me but I think you are missing the rest of the comments I've madealong those lines in my discussion with Ingo, and thusly I don't consider your judgement of the apparent intelligence or fairness valid.
As I've pointed out before, it's one thing to debate the license on LWN,
I very much appreciate that Ingo is taking his time to write the comments
So I believe the question still stands, and since that question was
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 20:48 UTC (Thu) by sepreece (subscriber, #19270) [Link] "So it's really not about the right to tweak the hardware at all. It'svery much about the right to tweak the _software_."
Yes, but it's about the right to tweak the software within a particular piece of hardware, so it clearly extends beyond just the software. Depending on the specific mechanism used to implement trust in a device, "keys and authorization codes" might also be required to allow changing values stored in special-purpose areas in the hardware, which also sounds like "tweaking the hardware."
"The virus writer example goes too far. My reason is an analogy on free
Note that the great mass of people have repeatedly shown themselve to be eager to trade rights that they have no desire to exercise for increased security. The vast majority of the people I know, aside from those in software jobs, would be completely happy to have hardware that ran only software signed by some trusted authority, if in return they didn't have to worry about viruses and other attacks.
"As stated, Tivo doesn't respect freedom #1."
Well, that's the crux of the issue between the sub-communities. We see freedom #1 as saying, on its face, "you are free to run this software on any device that will run it"; you see freedom #1 as saying, on its face, "you are free to run this software on this particular device". So, to us, Tivo is respecting freedom #1 and to you it isn't.
The other thing that concerns me about the anti-Tivoization language in the current draft is that it seems to claim some right to impose restrictions on the non-GPL software in the device. Maybe. The language is unfortunately ambiguous [this is a problem in the most of the controversial areas of the license, as might be expected, given that they're where the most change occurred].
That is, in requiring that "if it's a DVD player, a modified version must still play the same disks", it seems to putting requirements on the whole body of software in the device, proprietary and non-proprietary, not just on the GPLed components. [It is also possible to read the section narrowly, in which case you would have to assume it meant that the DVD player in the example was entirely GPLed software.]
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 21:33 UTC (Thu) by cventers (subscriber, #31465) [Link] > Yes, but it's about the right to tweak the software within a particular> piece of hardware, so it clearly extends beyond just the software.
I don't see how this is true at all. It's merely making sure that you can
That says nothing about what they're allowed to do with the hardware.
> Depending on the specific mechanism used to implement trust in a
Can you give an example? I can take some guesses but I'd rather discuss
> Well, that's the crux of the issue between the sub-communities. We see
Pardon? Freedom #0 is the freedom to run it as you wish. Freedom #1 is
> Note that the great mass of people have repeatedly shown themselve to
Granted, but I'm not sure if you're invoking this to imply anything in
I can understand mere disagreement over this point but when you really
> That is, in requiring that "if it's a DVD player, a modified version
The example is expanding on the idea of including keys necessary to
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 23:34 UTC (Thu) by jdivine (guest, #18042) [Link] > Pardon? Freedom #0 is the freedom to run it as you wish. Freedom #1 is> the freedom to modify it as you wish. If the manufacturer slaps a lock on > the software to prevent you from modifying it, how could the manufacturer > possibly be construed as upholding the freedom that says you are free to > modify?
They aren't preventing you from _modifying_ the software. You can modify the software all you want. They are preventing you from _running_ the modified software on the particular piece of hardware they manufactured. You can adapt the code, use it in other programs and on other devices, do whatever you want with it.
You may want to run modified code on the device you bought from them (which is totally reasonable) but your freedom to modify the code has not been abridged.
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 6, 2006 1:48 UTC (Fri) by sepreece (subscriber, #19270) [Link] I think we've gone around the particular tree enough times, so I'm not going to do a detailed response. Just a couple of quick answers to specific points:
I apologize for forgetting that the FSF numbers the freedoms from 0. I meant 0.
The point about the willingness of people to trade freedom for security was in response to your "The virus writer example goes too far. My reason is an analogy on free society - it would be like the police asking for us to give up our rights so that we don't get stabbed by burglars or something." The point is just that while it may be too far for you, many people would disagree.
I simply disagree with you about priorities. I think there are devices where trust is more important the user's ability to modify the software in the device, and I would not have any problem at all with my software being used in such devices. Obviously, YMMV.
And, finally, yes, I have been commenting on the GPLv3 drafts.
Cherry-picked Posted Oct 6, 2006 23:00 UTC (Fri) by man_ls (subscriber, #15091) [Link] The vast majority of the people I know, aside from those in software jobs, would be completely happy to have hardware that ran only software signed by some trusted authority, if in return they didn't have to worry about viruses and other attacks.I like this one. Let me use a counter-example: I own a PSP. The vast majority of the people I know, including those in software jobs, have chosen a PSP because it can be cracked to run software not signed from a trusted authority. They don't give a damn about viruses and other attacks; they want to run:
Cherry-picked Posted Oct 8, 2006 1:34 UTC (Sun) by sepreece (subscriber, #19270) [Link] Perhaps we travel in different circles. I do know a few young people who do use PSPs, as you describe, for things the manufacturer did not authorize. However, they are a small minority of the people I know. The ones who are older than, say, 35, would mostly REALLY like to not have to worry about malware coming with their e-mail or from visiting poorly chosen websites. And they're mostly Windows users, because it's the path of least resistance.
I'm not saying that's good, nor am I saying I disapprove of the kids using cracks on their PSPs. My statement was just about the general public.
Cherry-picked Posted Oct 8, 2006 2:46 UTC (Sun) by man_ls (subscriber, #15091) [Link] Maybe we could temporarily conclude that people over 35 choose security over freedom. And that people over 35 are the majority of people in occidental societies (so that "the general public" is mostly composed of people over 35). A tentative reason could be that people over 35 have more money than desire of freedom, at least those in your circle.Certainly people in my circle prefer to crack their PSP's than pay 60 per game; and prefer to play DivX movies of random sizes than convert everything to MPEG4 320x240 -- or pay for Sony's absurd multimedia kit. Even people over 35. So yes, we must travel in different circles. If you don't live around the metropolitan area of Madrid, Spain, Europe, then we indeed travel in different circles. So your original statement: Note that the great mass of people have repeatedly shown themselve to be eager to trade rights that they have no desire to exercise for increased security.is void, at least in the great picture. Luckily, I would add. We might change it to read "most US people over 35", but it would lose some weight. We could also conclude that those "rights that they have no desire to exercise" change depending on your age and country of origin, with the same overall effect. Your statement doesn't add much to the discussion apart from giving weight to the quote attributed to Benjamin Franklin: Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety.
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 6, 2006 15:00 UTC (Fri) by mingo (subscriber, #31122) [Link] > The contention that this somehow turns into a "right to tweak the > hardware" is false. Well, let's be careful about what we're talking about here. I agree with you and others when you mention that some devices already put software into ROM. If the FSF were trying to ensure a right to tweak hardware, there would probably be language prohibiting putting GPL code into ROM. By contrast, the anti-DRM provisions say "don't use technological means to circumvent the license".Why are you changing the topic and continuing to discuss that new topic without addressing the question I raised? What i talked about in the post you replied to was the interpretation of the GPLv2 that does not show any "right to tweak". It was /your/ contention in the original post that the GPLv2 talks about something that results in the "right to tweak", and that this somehow justifies the GPLv3's attempts to control hardware. It was /you/ who quoted the GPLv2's opening section to underscore it. I repeat: how could Linus have considered this new-found, retroactive, absurd and illogical interpretation of the GPLv2 in 1991? How could i have considered it when i started contributing to Linux in 1995?
Staying on track Posted Oct 6, 2006 15:17 UTC (Fri) by cventers (subscriber, #31465) [Link] Ingo,
I regret to see that you have not extended me the same favor of replying
There is a very distinct difference between the right to tweak hardware
The operative difference -- the very reason for an anti-DRM provision in
I think Linus, and now you, are doing people a disservice when drawing a
But the simple fact of the matter is that the hardware and software is
Why don't you respond to the real issue instead of covering it in this
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 7, 2006 5:17 UTC (Sat) by bojan (subscriber, #14302) [Link] > #3. You can't adapt the program to your needs or the device will refuse to start!
I think that's the point that kernel deveoplers have been trying to make - *that* device won't start.
However, by purchasing a different device, they say, Freedom #1 is restored.
Now, if *all* devices on the market were DRM devices, of course, Freedom #1 could not be regained but by a few that hold the keys.
I would think that hardware manufacturers will go all-DRM if that's what the market forces start demanding (i.e. Hollywood says so :-). GPLv3 or not.
> And if you're thinking "ROMs don't provide #1 either", you're right. But the FSF doesn't want to make hardware design decisions for manufacturers.
Hmm, it would seem to me (and I'm still very much undecided on the GPLv3 v. GPLv2 issue) that in fact new anti-DRM provisions do exactly that. They effectively say to hardware manufacturers: "If you build a DRM chip into the machine and want to ship GPLv3 software on it, you may as well not have the chip as it will be useless".
Again, it all depends on what the market will decide regarding DRM hardware. One thing is probably foreseeable: if Linux kernel were to go GPLv3 today, most DRM devices would most likely not ship it.
hackability by the people Posted Oct 5, 2006 16:08 UTC (Thu) by atai (subscriber, #10977) [Link] If in 1991 the PC has had something like today's DRM to limit what can be run and people need to purchase special hardware (and probably software, assuming free tools like gcc cannot run) at some high cost to do development for the PC platform, Linux could not get contributions from so many people so easily. And it is these people who gave Linux the critical mass by 1998 before major commercial interests got interested in Linux.
the reference Posted Oct 5, 2006 15:04 UTC (Thu) by coriordan (guest, #7544) [Link] Just to fill out the information. The paragraph that you mentioned as being removed was removed in draft 2 (it was still there in draft 1). The rationale for it's removal is: "We have deleted this statement of intent; we consider it unnecessary. It also had the disadvantage of using terminology specific to U.S. copyright law." From the draft 1 to draft 2 changes document (PDF).
the reference Posted Oct 6, 2006 9:08 UTC (Fri) by mingo (subscriber, #31122) [Link] The rationale for it's removal is: "We have deleted this statement of intent; we consider it unnecessary. It also had the disadvantage of using terminology specific to U.S. copyright law." So is it your position that the GPLv3 is not trying to control (and is not intending to control) any works that are independent of any GPLv3 codebase?
the reference Posted Oct 6, 2006 23:22 UTC (Fri) by man_ls (subscriber, #15091) [Link] I will be glad to hear Ciaran's answer to this point, but I will give my point of view too: yes, the GPLv3 is not trying nor intending to control any works independent of any GPLv3 codebase, as long as it is not essential to deploy and run the GPLv3 codebase. Why? Because if said work is required to deploy and run the GPLv3 codebase, it should not be said to be independent; it is either dependent or it is not a "work".I cannot rent you a house and then withdraw the keys. Similarly, if the GPLv2 explicitly states that software should include: [...] all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.You will agree that a crypto key (essentially, a big prime number) required for "installation of the executable" is not too far away from the definition. In fact it might be thought to be part of the "script used to control installation". So, is this prime number independent of the work under the GPLv3? Well, given that numbers are not copyrightable (even if they can be patented), I would say it is independent. Is it an "independent work"? I would say that a random prime number cannot be "a work", so it can hardly be "an independent work". So is it part of the hardware? Well, I don't think so because numbers do not belong in hardware. Also, the prime number seems to be definitely part of the "installation script" (as any other magic number). Just as if the script needed a password, or a magic memory address, to install the software. So, even under the GPLv2 the intent seems to be clear, even if the case is not so clear-cut and a cryptographically-challenged judge might think otherwise.
simple answer: a DRM-allowing exception Posted Oct 5, 2006 14:48 UTC (Thu) by coriordan (guest, #7544) [Link] Section 7a gives every project the infrastructure to remove that provision (by granting an exception).
Then we can all benefit from the other improvements in GPLv3, the compatibility issue will be solved, no need for any rift or split.
simple but wrong answer: a DRM-allowing exception Posted Oct 6, 2006 8:59 UTC (Fri) by mingo (subscriber, #31122) [Link] Section 7a gives every project the infrastructure to remove that provision (by granting an exception). Then we can all benefit from the other improvements in GPLv3, the compatibility issue will be solved, no need for any rift or split. What you are missing is the "detail" in 7c that anyone remove any such extra permission! See section 7c of the GPLv3 draft: c. Terms Added or Removed by You. When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. 'Conveying' is defined in Section 0 as: To "convey" a work means any kind of propagation that enables other parties to make or receive copies, excluding sublicensing. I.e. remove the extra permission from the source and redistribute the result - the extra permission is gone! I.e. the 'extra permissions' language of the GPLv3 makes extra permissions second-class citizens compared to the "pure" values expressed in the GPLv3. Extra permissions in the GPLv3 are like old paint: they can be removed by anyone, anytime, for any reason. So by moving the kernel to GPLv3+DRM-exception the kernel developers would give blanket permission to anyone in essence to relicense the kernel to a license we dont agree with on many grounds. How is that fair in your opinion? Your suggestion that this is a "simple" solution acceptable to those who oppose the fallout of the GPLv3's DRM language on moral, practical and legal grounds is misguided at best. (And even if extra permissions survived modification and derivation, there would be other fundamental assymetries making GPLv3+DRM-permission works a second-class citizen. I dont want my GPL-ed work to be a second-class citizen, to be slowly assimilated into the "pure" GPLv3 codebase. I'd prefer a GPLv3 that is unconditionally acceptable to the overwhelming majority of contributors.)
in practice, you get what you want Posted Oct 6, 2006 9:44 UTC (Fri) by coriordan (guest, #7544) [Link] Lets look at how it works. There's me, the Linux devs, and Tivo.
The Linux devs accept GPLv3+DrmException code into their trees. I download a copy, make my improvements, and publish my version with the exception removed.
Enter Tivo. Tivo has the option of Linux under GPLv3+DrmException, or CiaranSuperLinux under GPLv3. They go for the former.
The only effect is that Tivo lose the benefit of the work of a guy who doesn't want his code to be incorporated into the software of hardware manufacturers who are trying to block users from running modified software.
The wishes of the Linux devs are respected, and my wishes are respected for my non-integrated patch.
Important point: the lack of an exception will only effect my modifications (because the vanilla version will be available elsewhere with the exception), and it will only affect my modifications if I don't want that exception on my modifications.
you are missing the whole point of the GPL! Posted Oct 6, 2006 13:06 UTC (Fri) by mingo (subscriber, #31122) [Link] Important point: the lack of an exception will only effect my modifications (because the vanilla version will be available elsewhere with the exception), and it will only affect my modifications if I don't want that exception on my modifications. What you suggest is absurd. So by your logic it would be acceptable to remove a "permission" from the GPLv2, and modify a GPLv2-ed work with that permission removed? I consider that permission an integral portion of the contribution that i do and did. I dont accept narrower nor broader terms. Your suggestion that our objection to the incorrectness of the DRM language can be rectified by making that language optional - but on the other hand can be removed by anyone, allows the co-opting of our code under conditions that we dont agree with! That's what the whole GPLv2 is about. You dont get to remove the permission of "allow all others you distribute this binary to to receive the source code too" either...
you are missing the whole point of the GPL! Posted Oct 6, 2006 14:31 UTC (Fri) by sepreece (subscriber, #19270) [Link] I agree with mingo. The current language is asymmetrical - it says, in effect, "restrictions are statements of deep philosophical import and must be retained; permissions are minor preferences that you can remove".
I don't see any reason why granting an extra permission should be considered less important to the author than making an extra restriction.
you are missing the whole point of the GPL! Posted Oct 6, 2006 15:05 UTC (Fri) by mingo (subscriber, #31122) [Link] I agree with mingo. The current language is asymmetrical - it says, in effect, "restrictions are statements of deep philosophical import and must be retained; permissions are minor preferences that you can remove". Yes. But the assymetry gets worse than that: there are permissions that are "more equal" than other permissions: the core permissions of the GPLv3 - which (of course) no-one is allowed to remove! All this plug-in language makes sense for small details that no-one cares deeply about but which have to be adhered to for legal reasons. It very much does not work for "details" that people feel strongly about and which details people want to survive in works that are based on theirs.
2 days later, the answer Posted Oct 8, 2006 14:42 UTC (Sun) by coriordan (guest, #7544) [Link] It was a good question, and it took me two days to think of the answer, but here it is.
Tivoisation _could_ be a global catastrophy for free software. If, in the future, the majority of personal computers adopt tivoisation, free software will be failing FSF's goal of giving people freedom, and it will be failing the collabration-of-many-tinkerers goal of the anti-GPLv3 Linux hackers.
(The Tivo doesn't allow tinkering, so Linux gains the Tivo employees as collaborators but loses the Tivo owners. Tivo on its own is no catastrophy, but the widespread implementation of tivoisation could be.)
The Linux kernel developers who wrote the anti-GPLv3 doc have disregarded FSF's position that users of Tivos should be free to modify the software and run the modified version on their Tivo. Similarly, they can disregard the catastrophy scenario I mention. They can say it's unlikely and they can point to economic or engineering reasons for why they believe it is unlikely. But, it is possible, and if the situation changes and that scenario seems more likely, the Linux kernel developers (whoever they are at the future point in time when the situation changes, if it changes) and the free software community must have an escape route. They must have a way to raise a protection against the problem.
Being able to remove that extra permission at a later date is an essential escape route.
(Also, the nice thing about having an escape route is that it makes it less likely that an escape will have to be made. When a threat sees that escape is easy, they are less likely to mount an attack. This thinking was the basis of the "liberty or death" clause of GPLv2)
Asymmetry Posted Oct 11, 2006 2:33 UTC (Wed) by sanjoy (subscriber, #5026) [Link] I don't see any reason why granting an extra permission should be considered less important to the author than making an extra restriction.The asymmetry is because the GPL is a copyleft license. The "you can remove them" aspect of permissions is not new to the GPLv3. Under the GPLv2, the result would be the same except handled less conveniently. And extra restrictions are forbidden by the GPLv2; the GPLv3 slightly weakens that requirement (and hence weakens the asymmetry). I'll discuss each aspect in turn. PermissionsLet's assume that the new contribution is itself not a derivative work or a 'covered work' (in the sense of the GPLv3). If it is, then the author probably cannot add permissions under the GPLv2 or GPLv3, so this discussion would be irrelevant. But even when the new contribution is not a covered work, the combination of new contribution and distributed work is a covered work and subject to the license. Under the GPLv2, an author would write his or her contribution, and could distribute it under the GPLv2 (by itself or combined with the original work) and also distribute it by itself under a GPLv2+permission license: a multiple-licensing privilege available to the copyright holder. Special cases of GPLv2+permission include distributing under a new-style BSD license or under a public-domain license. Recipients could use it under either license. If they incorporate it into the original work, they would use the vanilla GPLv2 (with no extra permissions). So, the permissions have just been removed. The contribution is still available from the author with the extra permissions, just not available with those permissions when combined with the original work. (Probably the notice of extra permissions, a "notice of licensing", would have to be retained in the combined source code, but the combined work would be distributed under the vanilla GPLv2, so the extra notice would have no effect.) The GPLv3 makes this process more convenient for the author and downstream recipients. The recipients can, if they want to, maintain the author's extra permission in the source file they distribute, and recipients farther downstream can extract it with those permissions. Whereas with the GPLv2 they would have to find the source distributed by the author. RestrictionsRestrictions are already (in the GPLv2) treated differently from the above permission scenario, in that the GPLv2 already forbids any restrictions. For example, it forbids a requirement that secondary downstream recipients pay the author $10/copy. The GPLv3 relaxes this asymmetry slightly by allowing a few specified restrictions. Thereby common, non-show-stopping restrictions, such as from the Apache License, do not make a work GPL incompatible.
Similar in spirit? Posted Oct 7, 2006 13:06 UTC (Sat) by stock (guest, #5849) [Link] I fear that the FSF is now behaving like RedHat and Fedora have beendoing over things like the NTFS filesystem driver ntfs.ko and the abandoning support of popular mainstream audio/video formats like mp3. Inside the USA this may seem necessary but overseas like in France, Mandriva has never excluded these. So the GPLv3 might seem a glove match on American soil, where things like the DRM legislation will be enforced, in other countries DRM issues will just be textbook legislative examples only. So my suggestion for Torvalds is to aim, point and identify which parts of the Linux kernel can remain under GPLv2, and make a separate additional part, like if you have linux-2.6.18.tar.bz2, you will now have linux-2.6.18-std.tar.bz2 + linux-2.6.18-gplv3.tar.bz2, where the latter is an extra tarball to be extracted over linux-2.6.18-std. Robert
Similar in spirit? Posted Oct 9, 2006 11:29 UTC (Mon) by nim-nim (subscriber, #34454) [Link] - ntfs: one problem company, already unpopular and watched by regulators wordwide, holding some patents that may not be enforceable in Europe, based on stuff it didn't originally develop, never actually threatened to enforce them
- mp3: a few problem companies, never made their mind if they actually wanted to enforce their patents or not, little global leverage
- DRM: a whole economic sector, with local branches worldwide (including some of the richest multinationals of the world), believing its future is at stake, controling in large part the "free" press, powerful enough to push international treaties and have the sole remaining global superpower enforce them.
1. does the scale of the problem seem even remotely similar?
Aside from that the discussion is not limited to the Linux kernel licensing (even Ingo acknowledged it) and your proposal is wrong both at the legal and at the logistical level.
Similar in spirit? Posted Oct 12, 2006 16:39 UTC (Thu) by alext (guest, #7589) [Link] Strikes me the voting machine and the medical equipment should still be free of DRM. The voting machine should have everything visible so that it can be verified and the medical machine likewise. With the health equipment it makes audits after incidents possible and also means that equipment from one provider can be examined and possibly serviced by another. I don't see any real reason anywhere so far posted to suggest DRM should be used anywhere.
|
|||||||||||||