login
Search
The following editorial was contributed by Ciarán O'Riordan of FSFE. Working for FSFE since April 2005, Ciarán has been raising public awareness and participating in public discussion on GPLv3 since the launch in January 2006 and contributes heavily to FSFE's GPLv3 project.
Discussion draft 3 of GPLv3 is due in early November, approximately. Before that is finalised, I'd like to review the debate over DRM and the Linux kernel developers. Discussion draft 3 may be the final discussion draft, so I'd like to encourage discussion of this issue so that people can make comments now (via gplv3.fsf.org) which can be taken into account for draft 3.
GNU GPL version 2 is a great licence. It's an amazing licence when we remember that Richard Stallman wrote it pretty much on his own with some legal counsel. This year, the community's input is solicited and four teams comprising 130 people have been formed to research each issue raised by the community. With fifteen years of hindsight, and will brains from around the World, I think we can write an even better licence.
The decision for whether the Linux kernel will relicense to GPLv3 can really be made when the official GPLv3 is published in early 2007. Relicensing Linux will not be simple, due to it's hundreds or thousands of copyright holders, but it can be done if there is a will. (I previously wrote about how this works in "Can the Linux Kernel Relicense?") Right now is the time for debating what the licence can do, should do, and what options it should leave open. In this article, I'll focus on DRM.
What GPLv3 says about drm:
About DRM, draft 2 says you may distribute the software:
...provided you also distribute any encryption or authorization keys necessary to install and/or execute modified versions...
(From Section 1, paragraph 4)
For the vast majority of distributors of GPL software, this requirement has zero impact because in normal circumstances, no keys are necessary to install and/or execute the distributed software. The rare special case that will be impacted by this clause is where software is being distributed as a software+device bundle and the Device is Rigged to Malfunction if it detects any software that hasn't been somehow authorised by the hardware distributor.
From following the debate over GPLv3 and DRM, I think the requirements are quite a bit smaller than one would imagine if they read only second-hand sources. There are some more DRM-related words in GPLv3 draft 2, but I think the above quote is the bulk of the substance.
Why is the drm stuff there?
For three reasons:
(A) Freedom. The philosophy of the Free Software movement is that computer users should be free to help themselves by modifying the software on their computer. If running a modified version requires a password, then the recipient of the software must be given the password so that they can make use of this freedom to help themself.
Since the start, this has been offered as the reason to support the DRM clause. In hindsight, that was probably a mistake. Freedom is the reason for the Free Software movement, but it is not the beginning and end of why combating DRM in our licences is a good idea - just as freedom isn't the only reason why people used GPL version 2. On to the other two...
(B) Developer community. This can be summarised as: More tinker-proof boxes = fewer tinkerers. Hacking the Tivo is pointless because the computer won't boot if the software is modified. In this way, Tivo computers are tinker-proof. The GPLv3 prohibits distributing the software in a system that uses DRM to prevent tinkering.
Tivo are not the only ones making tinker-proof boxes, but Tivo are the only ones I can see that are likely to walk away if Linux moves to GPLv3. This is because Tivo are the only distributors of tinker-proof boxes whose business model rests on controlling their users.
The other distributors of tinker-proof boxes fall into two categories. One is a subset of router manufacturers. I don't believe they have a deep interest in preventing tinkering. If they are have to allow tinkering in return for getting continued software updates, I don't think they will walk away. That way, we gain more co-developers. The second category is makers of devices which are regulated by government or standards bodies, and for these there are still the options of putting it in ROM or putting it behind a locked door. (See: Preventing modification: put it in ROM?)
(C) Catastrophe prevention. If the current trend of general purpose computers were replaced en masse by tinker-proof computers, this could be a catastrophe for Free Software. I've no idea how likely this scenario is, but it is obviously possible. There are at least three ways that it can happen:
Where do we go from here?
Reasons (A) and (C) are why the final version of GPLv3 will retain some clause to preserve the freedom to modify software and run it on the computer that the original software was intended to run on.
Many Linux kernel developers have rejected reason (A), but I haven't seen substantial discussion about reasons (B) or (C). There's plenty more time for discussing these points.
If the Linux kernel developers decide that none of those three reasons are agreeable, there is another option. Draft 2 of GPLv3 provides infrastructure for adding exceptions (called "additional permissions" in section 7a) to the licence.
The Linux kernel developers might add an exception saying that distributors don't have to pass on to recipients any required keys or passwords.
All such exceptions can be removed by others, but simply removing the exception only makes an irrelevent copy. If I offer to distribute a copy of their software with the exception removed, Tivo will simply ignore my version and use the version from the Linux kernel developers.
The only possible conflict that could still remain is that I can take Linux, remove the exception and additionally make my adjustments, and distribute my modified version under pure GPLv3. So my intent is respected for my version, and the Linux developers' intent is respected for their version. The Linux developers may not like that I can do this, but the impact of my version will limited by the fact that my code won't be accepted into the main kernel tree.
In this GPLv3+DrmException scenario, Linux will miss out on the advantages I see with reasons (A) and (B) above, but it would still retain much of the value of reason (C). This is because while there is no catastrophe imminent, being able to remove the exception later means that if a catastrophe ever looks imminent, and it looks like GPLv3's protections against DRM might be useful, then the Linux kernel developers have the option of removing the exception and using vanilla GPLv3.
So for reasons (A) to (C), I think something like the vanilla GPLv3 would be best, but GPLv3+DrmException also has advantages over GPL version 2 - one of which is that it means having an escape route. Having an escape route is valuable not only because you might need it, but also because the existence of an escape route reduces the chance that you will ever need it - people don't invest in an attack that is easily escaped from.
End notes:
(For ease of linking, each paragraph in this article has a html anchor.)
(c) FSFE 2006. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
Your idea that Linux can be r
Your idea that Linux can be relicensed under the GPLv3 is naive at best. Even if you ignore the fact that there's many past contributors who have disappeared and cannot easily be reached anymore, and even if you also ignore the fact that you'll never be able to get thousands (yes, thousands) of contributors to all agree on something (especially a license change, which is a political issue rather than a technical one), the fact remains that several high-profile developers - including Linus himself - have come out and said that Linux will never be relicensed in any way, period.
I'm amazed how you (and by "you", I mean not just you personally, but also RMS, the FSF, the FSFE etc.) manage to completely screen that out. But like all fundamentalists, you're being unrealistic: you want to achieve something, but instead of looking at the facts in a rational way and attempting to figure out whether it's realistic or not, you simply declare it realistic based only on your own wishes.
On a side note, you keep on saying that Linus and others who object to the GPLv3's current draft(s) should participate in the GPLv3 process to get it changed. But outside of the fact that the FSF (Eben, IIRC?) already said that the key provisions that Linus, for example, has problems with won't be removed, you're also ignoring another fact: Linux (and Linus) has no need for the GPLv3. Rather, it's the other way around; the FSF needs Linux for the GPLv3. If Linux is relicensed under the GPLv3, you obviously win a lot - publicity, trust, recognition and so on. And similarly, if the GPLv3 is rejected, then this will have negative consequences both for the GPLv3 and the FSF in general; you'll lose influence and status, at least in the eyes of the press and the general (IT) public.
Given that, it would make more sense for you to go and try to understand Linus' and the kernel developers' position. It's you who want them to join the party; but if your conditions aren't acceptable to them, it won't help to say "we're willing to negotiate" if they don't have an a priori reason for wanting to join. You obviously aren't able to use the stick, so maybe you should think about using the carrot instead.
That being said, BTW, don't get me wrong - I personally think the GPLv3 is a great license, and assuming there won't be any radical changes in the final version compared to the current draft, I will certainly adopt it for my projects. But I think that your handling of the interaction with Linus and the other kernel developers is poor at best, and your idea that Linux will somehow be relicensed under the GPLv3 in the future after all is outright barmy. You'd better wake up and smell the roses, since until you do, you just won't get anywhere with this.
Nice try to divert the discus
Nice try to divert the discussion to a trolling one about feasability to relicense, that's not what this article is about.
I'd like Kernel Devs to discuss if they would find acceptable to adopt a GPLv3 + DRM Permission. GPLv3 has many key advantages, and I think the kernel devs would profit a lot from using it.
If the DRM Provision is the only one they don't swallow, the GPLv3 + DRM Permission seem a very good compromise.
What does Linus & Co. think about this?
I'm not trying to rant here -
I'm not trying to rant here - but how is the post above trolling? He actually laid out many facts you can read about on lkml.
> What does Linus & Co. think about this?
There was a veeery long thread on lkml about this, and their position is quite clear: They _want_ the GPL2, and they don't want the DRM provisions. They also have stated why. Why didn't you read that?
I'm not trying to rant here -
I'm not trying to rant here - but how is the post above trolling?
Well, I stopped reading it at the phrase "But like all fundamentalists, you're...". It seems pretty trollish to me, too.
Caustic, definately, but cert
Caustic, definately, but certainly not trollish. Trollish implies a lack of useful or insightful content. While the grandparent poster was caustic in his remarks he did, however, raise valid questions. Therefore he's a dick, not a troll.
It is not trollish. FSF and R
It is not trollish. FSF and RMS _are_ fundamentalists. And RMS is an idiot (I have no other word for person who calls "fools" the people who do not share his view of "freedom"). As a philosophical statement, I refuse to contribute to any GPL'd project in any way.
If Linux switched to GPLv3, manufacturers of tinker-proof devices would just switch to some BSD. Actually, switching Linux to GPL3 might be a good way to put more life into BSDs. Go Linux, go for GPL3!
RMS
Mmm. Well, I am not sure what quote you are using from RMS, but fools is as fools are so they say.
Critical thoughts withstanding RMS as an individual is not an idiot.
I have seen the code he writes, I have seen him talk and until you design a license that quite literally has saved the world from crappy software design techniques, I don't think you are qualified to say RMS is an idiot.
Sounds like your envious about a man who has accomplished quite a lot.
Finally, let me state I am all for GPL v3.
We need a license to protect us from greedy information controlling types who like to use BSD style licenses as free slave labor or who want to foreever remove the right of any individual to own anything using DRM.
GPL v3: Down with BSD style licensing and the slave labor practicies it promotes, down with DRM and the sickos who use it to prevent ownership of any and all information.
I say Up with forcing people to contribute changes back to others who labor on software and wish to sell said software and source code to make a living, in complete freedom!
Hurray!
Freedom to OWN your own source code!
Hurray!
Freedom to look at ALL source code and modify it for any business or personal use before OR after purchase!
Hurray!
Then of course, hurray for RMS. We have a lot we owe to the man and I hope he continues his great work bringing source code to the masses and freeing it from bondage of the greedy, power hungry information controlling types.
Hurray!
-Hack
Envious? Hardly. I've heard c
Envious? Hardly. I've heard comments from people having the opportunity to meet RMS in real life. They left his company on the first opportunity.
As for "saving the world" from crappy SW design practices -- GPL'd code has the worst quality I've seen. Just compare Linux kernel, gcc, gpg.. internals with some of BSD, Apache, etc. code.
And how do you explain that non-GPL'd projects (such as Apache, Perl, etc.) are doing quite well w/o forcing people to share?
RMS's ONLY real contribution are emacs and gcc. And gcc has since long being developed by others than him.
GPL helps the big players to
GPL helps the big players to work together.
HP, IBM, Sun, SGI, Intel, AMD, and so on. This companies do not usaly work together. GPL forces them and they like that. Why? They trust the GPL to force their competition to do the same.
It makes it easier to work together with someone they do not trust. GPL is made for enforcing sharing betwen untrusted participants. And it works fine for just that.
It is a pitty that Novell and Tivo managed to find some holes.
>As a philosophical statement
>As a philosophical statement, I refuse to contribute to any GPL'd project in any way.
You are also a fundamentalist, a BSD one.
If you weren't a fundamentalist, you would chose software you use based on it's technical merit, not it's license. (People usually contribute to software they use.)
By the way don't get me wrong, BSDs (well, Free and DragonFly) are more advanced in some areas than Linux...
...And in fact maybe the BSD's are more cmitd to opn stds thn lx
Good.
Frankly I think OpenBSD is more commited to Open Standards than Linux
and Linus's bunch.
If that's the case I'd prefer the BSD's to succeed.
Bullshit. His comments are NO
Bullshit. His comments are NOT trolling.
The one who is NOW trolling is YOU.
He very well placed opinions.
Instead of referring to them as troll-opinion,
address his points.
Period.
Based on the language of the
Based on the language of the current draft trying to remove the DRM clause could fall under Additional Permissions or be null and voided under the Additional Requirements section. This can raise a problem. It only takes one copyright holder in the Linux Kernel to sue and claim the DRM exception is invalid.
copyright doesn't work that way
Even under GPLv2, there's a lot of software licensed with GPLv2 plus a special exception. The GNU C++ library, libstdc++, is licensed that way. You are misinformed if you think that anything in GPLv3 prevents the copyright holder from granting additional permissions, or that any copyright-based license could do that.
Sorta
What this guy is worried about is that one couldn't distribute something under the GPL plus the requirement that one *couldn't* share the source code. In other words in order to license something under the GPL it MUST be possible to distribute that software in a GPL compliant fashion.
You are right that one can always give *additional* rights to copy the code over and above the GPL. I agree with you that his worry is probably not well founded because one would liscensced the kernel under GPL or (GPL-DRM provisions) so you have no logical conflict.
re: "nice try...
re: "nice try... trolling..."
this comment typifies the lack of class and integrity FSF supporters display in forums such as this.
Any argument that challenges you on a factual, practical, or philosophical basis is ignored and deflected: instead, it is called FUD, trolling, or the person is simply confused, if they really understood the argument they would probably agree.
This is why the FSF/GNU/GPLv3 movement died this year. You showed your true colors, and people stayed away.
I am wondering if the GPLv3 s
I am wondering if the GPLv3 stuff could be viable if the kernel is not relicended concerning DRM.
I mean:
-Put the key in hardware: so every body have it, no problem with redistribution
-Put in a signed kernel enforcing execution of signed binaries, but under GPL v2:
That means you have a kernel that you cannot change, and you have all the GPL v3 stack above with the key and everything
BUT you cannot install recompiled GPLv3 softs
The point is: if the whole stack is not GPLv3, I fear that you cannot enforced anti DRM properties, just like without a complete DRM closed chain you cannot enforce DRM.
Last but not least:
what about changes to the compilers used that does not have to be distributed? The encryption, keys, etc.. is a very narrow part of the problem...
With GPLv2 you have the right to fork or to Tivo-ize your code, but the two options cut your momentum: they are doomed by essence, providing that you provide quality.
> The point is: if the whole
> The point is: if the whole stack is not GPLv3, I fear that you cannot enforced anti DRM properties
Yes, and it works in reverse too. Even if the OS kernel is GPLv3, Tivo can just put all the keychecking logic in their closed-source application. I don't see GPLv3 being any serious impediment to "tivoization".
Additionnal permission
I don't understand why the DRM-friendly devs don't just add additionnal permissions for that to their GPLv3. So they can get all of the internationalisation, patents, etc benefits of the GPLv3. While still permitting tivo-izsation
Additional permission
Because any extra permissions can be stripped out at will, and so don't really mean anything?
Because the very idea of GPLv3 with all kinds of extra permissions will create hundreds of (possibly incompatible) licenses?
Kernel folks misgivings...
They are emphatically not "pro DRM" or anything like that. They just believe that GPLv2 is fine, and that trying to stem DRM via a license for software (that could easily be replaced with a lot of alternatives at not too significant cost) makes absolutely no sense.
Problem is, GPLv3 will fracture the developer communities, and make GPLed code incompatible with GPLed code. The current pain caused by license proliferation is quite real, and this will only make it worse. For no real gain.
Kernel devs short-sigthed (on porpuse?)
In long term, if they do not aim for a relicense, the Linux kernel will be replaced by something initially uglier, but working, and really free. GPL v2 software is really open/free aslong as you run it in certain kind of general purpose machines.
This will NOT be true in the future. Graphics cards drivers are almost all closed, almost all wifi drivers are closed, almost all wimax drivers will be closed. EV-DO- HSPA, etc. drivers are/will be closed. Everything will be closed. If Linus or Theo complain, they will still be closed, or move "signed drivers" (hardware/driver combo), just like TIVO, but for the HW parts. Everything interesting will be closed, Linux or not. So what's the point of a GPLd Linux in the first place? How long untill anything interesting (including the CPU) is closed?
Kernel programing will bmeam doing ONLY the boring parts, financed by the "combo profiting (hw+sw)" companies. The likes of TIVO will pay kernel programmer to keep things this way. And the GPL would have served large corporations to save on common code, achieving economies of scale to make sure the basic infrastructure is not owned by any single entity (such as MS), and leaving the end user not much better than before, because if you want to use any interesting tech, you'll have to buy the locked-down version that can be tinkered/modified/freed-up.
Nicely put. Now, instead of
Nicely put.
Now, instead of labeling the Linux Kernel as "insufficient",ie. cuz the evil corporations lock out everyone (well i guess they do if it gives them an advantage) - please write your own Kernel, or support GNU
Hurd.
Then you can use the GPL 3, and lets see if it will be a success or not. (I am not saying it will be, or wont be, but I will say that
its a lot easier to write down success in a license, than force it on the real world in REALITY via a license....)
See it from the other side, Linux as Kernel was a success.
The devs wont be stupid and let their successful Kernel die.
Looking forward to GPLv3
Looking forward to GPLv3. I personally don't want anyone taking my software putting a hardware lock in place and keeping my users from being able to enjoy the freedoms I guranteed them when I first licensed the software GPL. Glad to know that the FSF are working on a solution to this.
If in the future all CPUs are
If in the future all CPUs are locked down as you say, how could any theoretical RMSware ever function? Basically, if DRM is necesary to operate your computer, and GPLv3 programs can't be run on DRM'ed hardware, then GPLv3 programs are illegal.
The GPLv3 can't stop DRM. This is the simple point that nobody from the FSF seems to get. It's like they have some kind of mental block. The only thing that the GPLv3 can do is fragment the community and waste people's time in pointless arguments. Which is something that it's done quite well at.
The kernel folks enjoy programming, and that's why they do it. FSF people see it only as a radical political statement. That's why I very much doubt that HURD will ever be finished, or that the Linux kernel will be forked, despite all the impotent threats. Engineers will always be better developers than politicans.
The GPLv3 can create an excep
The GPLv3 can create an exception to DRMd software, just like the GPL v2 was the an exception to closed source software. We ony need some "Linuses" upset with having software but not interesting HW to try it on. It may never happen, but it might.
Who woult have thought Linux would someday exist and be as sucessfull, thanks in great part to a license? The license made Linux possible BEFORE DRM existed. But of course, DRM leechers will not be supporting the new alternative (Hurd or whatever).
And to answer the other post, yes I will be trying Hurd, even if worst as an aternative, along with other free OSs as Linux. I means something and brings some of the fun back.
Mobile phones need to be tinker proof
There are terrifying scenarios for trojans and worms on mobile phones since there are so many different communication methods that are open to exploit. It's not trivial to to patch phone software (just beginning to happen for Nokia but you can still easily "brick" your phone).
Symbian 9 uses keys and signing to control the level of "trust" given to each binary (can it use the network, access the filesystem etc). It stops a trusted DLL from being used by a less trusted application, for example. So, for example, an unsigned hack-attempt will not be allowed to load the DLL which provides telephony services or connect to the socket server because it's trust level is too low compared to theirs.
This provides a considerably better level of safety than most operating systems and it is likely to be of great importance.
I am not sure how GPL software would ever work in this world because if a user can modify an executable then it can never be given permission use those APIs of the operating system that can be considered "useful to trojans and worms".
It is possible modify free software and have it resigned but the keys are never handed out.
Mobile devices are a big part of our future, even though Americans might not realise it yet, so this license could cause free software to miss it's greatest ever opportunity to reach people. Perhaps the demand that resigning of free software should be possible an non-discriminatory rather than that keys should be required.
"Mobile phones need to be tinker proof" - I disagree
It sounds like you are advocating DRM because of security issues.
"There are terrifying scenarios for trojans and worms on mobile phones since there are so many different communication methods that are open to exploit."
This is scary reasoning - if you believe this - you can use the exact same argument for regular computers (as opposed to simply mobile phones). There are many security measures that can be taken without incorporating DRM. Especially on embedded devices where the uses are more focused.
Your reasoning is more anti-FOSS than necessarily pro-DRM. EI has been using this "signed" goes through, "unsigned" ask the user - with mixed results (this is the security of Symbian 9 - AFAIK). While security on mobile phones is important DRM is more of a secondary issue - not related to security.
There are a number of Linux-based phones on the market (especially in China), they don't need DRM.
Of course it can be relicense
Of course it can be relicensed. What is so "funamentalist" or "impractical"?
It doesn't require anyone's permission. The relicensing will have to include additional permissions, as allowed under GPL v2 and v3.
What's the big deal?
The much more interesting question is what would the kernel developers want to see in the license in order for them to adopt it. You've sidestepped that discussion completely.
What's with all the "you, your, you're"? The FSF has given Linus and others many opportunities to give their input, but they haven't accepted, preferring to post their opinions (often tinged with minor and major misunderstandings) as opinion pieces, or worse, sound bites to reporters. Not the way to convice the FSF to change -- it's absolutely true they are stubborn, but this is one time they really are trying to listen to everyone and yet only corporations seem to be taking advantage of it.
Rediculous Comment
Your comment stating that "Your idea that Linux can be relicensed under the GPLv3 is naive at best" is rediculous at best.
Contributers have the right to chose any GPL license they like, and
often this has been "GPLv2 or later".
Neither Linus nor anyone else has the right to speak on behalf of all
of these users. While Linus is making rediculous comments finding the
right in himself to speak on behalf of these contributers without
asking, he is at the same time hypocritically saying that pro-GPLv3 are trying to do the same.
I'm looking forward to the forking of the Linux Kernel for a GPLv3
version. Although Linux was Linus's project to begin with it frankly
no longer is his, it belongs to the community of contributers. There
are far too many contributers for him to be able to speak on behalf of
anyone or to dictate anything.
Actually, and better yet, I'm looking forward to the development of
Microkernels, even be it under the BSD license (Minix 4). There are
many good alternatives and it takes something likes this to increase
interest in those projects.
"ridiculous", it's "ridiculou
"ridiculous", it's "ridiculous", not "rediculous"
Perhaps not so Amazed
"I'm amazed how you (and by "you", I mean not just you personally, but also RMS, the FSF, the FSFE etc.) manage to completely screen..."
Perhaps you will not feel so amazed when one day GNU/Linux gets effectively made useless by the twisting of the law and other maneuvers compliments of some of the mega-corporations that don't like competing with free. However you may become re-amazed at the realization that the world isn't as sweet and nice as the non-GPL3'ers thought it was.
One thing that the whole GNU/Linux community needs to take into account is the fact that if the software license leaves open ANY holes that can be used to diminish or kill GNU/Linux, sooner or later it WILL happen. And at that point a big bad restrictive GPLv3 will never have looked so good.
Never seen the kernel develop
Never seen the kernel developers address reason B? I think that's the major one that they have addressed. They want vendors to be able to lock out tinkerers on devices if that's a business need. I think you vastly underestimate the support tail of product development if you think that hardware manufacturers (who just happen to have software on their hardware) are opposed to modification. Even if there is a warrenty breach, there's a huge cost to supporting people who broke their own hardware. Just lock them out at the start.
It's a simple cost benefit analysis. In the Tivo argument, the consumer is not the user of the linux kernel. The consumer is the user of a black box that records television. Tivo is the user of the kernel. Why would anyone choose to switch to GPLv3 if they're going to have to work around the license to give the users freedom and the GPLv2 does the job just fine?
Whenever I have purchased a c
Whenever I have purchased a computer from someone and then broken the software component, because of tinkering, registry corruption, or generally overloading the system, the device manufacturer's response has always been "reinstall from the system disk". Generally, it works wonderfully.
My mother doesn't run into nearly as many situations like that, mostly because she regards her laptop as a black box for writing email and playing solitare, so she's not digging around trying to get things /just/ right the way that I am. The thing is, her lack of knowledge about, or interest in, how the software on her computer works doesn't mean it's not /her/ computer, or that it really is the incomprehensible black box that she currently thinks it is.
Now, if I buy a Tivo I will not be buying a black box, I will be buying a computer with a nice hardware and software package for recording TV and I will pay extra for the continuing service of having Tivo send me program guides.
Am /I/ a consumer of the linux kernel? I very much am. For all you know I could be a developer of the kernel and I could be interested in developing features that will work on that hardware. Tivo is not the "consumer" of the kernel, they are a distributer of the kernel, just like every distributer and everyone they distribute to becomes a user of the kernel.
The strength of /both/ the free and opensource software movements is the ability of users to become developers. When you start distributing free software in a way that prevents modification, you cut an arbitrary line between users and developers. You take a project that relies on communal development and you say "No, no. /This/ part of the community will not be allowed to develop on their hardware. They will simply give us money and we will give them software"
I'm pretty sure that preventing just this situation is where the GPL differs from BSD.
If you want your own PVR, why
If you want your own PVR, why not build your own PVR using an off-the-shelf computer?
And use the GPLv2 software Tivo released.
I did.
Why not roll your own
Their are lots of reason why buying a pre-built computer might make more sense than building your own from individual components: you know that the machine will do the task you bought it for right out of the box, there's a single point of contact for faulty parts or assembly, and the manufacturer may be able to optimize the case size/design for the parts you are putting into it, to name a few. You may also not know enough to put together your own yet.
The issue is not that Tivo is the only game in town for PVRs, it is that Tivo is able to offer a compelling product at a reasonable pricepoint to people because they built their busines around freely shared, community developed, tested, and distributed software. It is just a shame that no Tivo users after the first few boxes have the ability to join into that development community. That's what the GPL was meant to ensure people would always be able to do.
Ok, but I didn't build my PVR
Ok, but I didn't build my PVR out of many different individual components. I used a regular PC with a video card that could do S-Video out.
What it comes down to is this: The GPLv3 can't stop media industries from pushing DRM, and it can't stop countries from instituting software patents. It's like saying "unless Bush pulls the USA out of Iraq, I'm going to take a lower paying job!" Bush doesn't care if you take the lower paying job. The only one you are hurting is yourself.
The big media companies who are pushing DRM and the big software companies who are pushing software patents don't care if Linux lives or dies. In fact, most of them probably would be happy to see it go. The only people who we are hurting with these new restrictive license clauses are the friends of Linux: companies like Red Hat, Tivo, MontaVista, and IBM. Without IBM in particular, perhaps SCO would have succeeded in crushing Linux under a wave of lawsuits.
If you want to fight DRM and software patents, then do what you can to raise people's awareness, and maybe even get out the vote when necessary. But adding onerous clauses to the licenses of programs which more than 95% of Americans have never even heard of won't hurt anybody except the program authors.
Raising Awareness
I agree that raising awareness about DRM, software patents, etc, and the problems they cause isa important; it is a large part of the EFF's work. That's not work you can do with copyright law let alone a single software license.
The GPLv3 is not trying to stop /all/ DRM or to nullify the patent system. If countries want to issue patents on software, there's nothing the GPL can do about it. If media companies want to ship their disks with CSS, or rootkits, the GPL's silent there too.
All the DRM provision are seeking to do is ensure that everyone who wants to distribute free software has to pass on the same rights to view and modify the software that the distributer got from the community in the first place.
If Tivo had tried to put the same restrictions on its customers, that they can't modify the software on their own machines, with a contract rather than a protected boot loader, it would clearly be a violation of the GPL.
the same is true for patents. If a company tried to prevent you from making and distributing modified versions of a GPL'd program with a contract, they would be in clear violation of the GPL. When they do it by patenting portions of the program before they distribute it, somehow that is different.
Both of these situations developed as posibilities after the last version of the GPL, and both prevent users from having the freedoms necessary to build free software going forward. All the new provisions seek to do is say you cannot stop anyone from tinkering with Free Software on machines they own, not through additional contract agreements, not through technical measures, and not throug hthe threat of patent litigation. If you want to stop people from doing development on the software you ship them, don't use Free Software, that's how its built.
Raising Awarenesshere
How do the DRM provisions ensure that the software is distributed with source? That is exactly what GPLv2 demands, I see no change there.
Nowhere does the GPLv2 say something like that... if it did, the whole "GPLv3 or else" push would be (even more) pointless.
Source alone is not enough
Microsoft will give you source as well, under certain conditions, but without any permission to make modifications. The point of the DRM issue is to make sure it is possible to modify the program and run the modified version.
I fear that with or without the DRM clause, in a few years computers will be sold pre-loaded both with a Microsoft OS, and hardware to prevent the loading of any operating system kernel not signed with a Microsoft key. You'll have to get a custom computer built out of parts if you want to run Linux, and you'll pay more if you can't exploit economies of scale. Some countries might outlaw such machines, especially if they want to put a government bug on all computers.
MSFT gives source?
I've talked to someone who has "access" to the code. It means:
No browsing. You can't compile it yourself. Just look at selected parts. Is it what is running on your machine? No way to know...
Sure, DRM-locked code in a device is less than ideal, but at least you get to see it all if GPLv2-ed, and can use it (or parts of it) elsewhere, no questions asked. But there are very real scenarios where you want the code tightly controlled by someone responsible. In medical equipment, you want the manufacturer be responsible, not a random employee who happened to hack the machine "because I can make it work better". Yes, you might think of ways of distributing keys to the software signing to each buyer. And pray how do you start making sure none of those tens of thousands handles the keys carelessly? How do you make sure none of the buyers is malicious, and uses the keys to sabotage equipment elsewhere? Having each machine get its own key makes the updating of software a nightmare (and very costly!). How does the user know the update they are downloading is the real McCoy and not a fake, as package signing keys will have to be handed out (else no random buyer can create a modified version that "works as the original", in this case, its installation is not refused by the system)?
Legitimately Locked Devices
The point that there are many legitimate reasons for locking down a device gets brought up a lot in DRM discussions. Medical devices and voting machines are the most comon examples cited. What these examples miss is that DRM is not what administrators use when restricting users, DRM is what distributers use when restricting administrators.
Dave Miller, one of the kernel maintainers has the best reply to these examples I've seen. He says:
"In most examples I've ever been shown where this kind of lockdown is supposedly "legitimate", the owner of the device is effectively making this lockdown decision. For example I'm OK with electronic voting machines used in real elections having their software locked down. The government owns those machines, and is well within their rights to lock down that hardware in order to ensure a proper and fair election to the public by preventing software tampering.
But if I purchase an electronic voting machine of my own, and it uses the Linux kernel, I very much want to tinker with it, build my own kernels, and try to poke holes in the device. How else could we validate that electronic voting machines are safe if the public has no way to test these claims out for themselves, in particular when such devices use open technologies such as the Linux kernel?"
But there are very real scena
That control does not have to be technical: nothing prevents the employee from replacing parts of the medical device, so why should it be different for its software? Such situations have always be handled by a clause like "opening the machine will void the warranty" and that has worked just fine, thank you.
It's just like DRM: until recently, there was no technical way to prevent users from making copies, so the industry relied on the law instead. It turns out that the law is a better solution than any technical means, because the law cannot be abused nearly as easily.
MSFT Source Code Access
That sounds like a lot of hyperbole. MSFT gives out quite a bit of source code to academia and "industry partners". Exactly what I don't know but your scenario seems unlikely to be the only one.
Talking specifically about embedded, MSFT announced:
http://msdn.microsoft.com/embedded/usewinemb/ce/sharedsrccode/default.aspx
Again, not using it I don't know what the levels, et al, are, but source is essentially a requirement for embedded systems and it explicitly states the ability to modify.
"Without IBM in particular, p
"Without IBM in particular, perhaps SCO would have succeeded in crushing Linux under a wave of lawsuits."
No. SCO was supported financially by other corporations who had interests in having a role model case against Linux, even if it was only for the FUD gained publicity.
There WASNT an attempt to sue individual developers, they wanted to get their role model case.
Unfortunately, their Troll-cases were no success, and most corporations stopped funding them.
Good argument, but...
That is a powerful argument. But, you don't address the main point of Linus' opinion (as I understand it). That DRM and the like, should not be fought with copyright. Why is that never addressed? Instead, lately when I read an article proclaiming the virtues of GPL V3, they never fail to paint Linus and the kernel developers as some sort of pro-tivoization, lock up the code, anti-free software, people who will not listen to reason.
you're right, I was mainly tr
you're right, I was mainly trying to respond to the poster above, not to Linus's position.
If you look at Linus's position on the matter, http://www.forbes.com/technology/2006/03/09/torvalds-linux-licensing-cz_... is a good source, you'll see that it goes beyond whether copyright is the right way to address DRM, he doesn't think DRM needs to be addressed at all.
For Linus, he just wants the source code back, that is the only goal. If you modify something in the kernel and distribute that to others, he wants those changes.
What bothers me is that, because he is not interested in the machine enough, he just blithly grants Tivo ownership of the box. since it's "their box" (see article) he thinks it's perfectly alright for them to control the software.
Its his computer, he purchased it.
What if I am a kernel developer and I want to develop new features to work with the Tivo box in my living room? I'm more interested in TV than Linus and adding new networking or time sync capabilities to the Tivo would be useful to me. Maybe I just want to use this living room computer of mine in ways not anticipated by the people who sold it to me, run a VoIP system or traffic shape my house broadband connection. This is how Free Software gets built and the GPL is entirelly about making sure anyone who gets free software can participate in this activity. That's what Ciarán O'Riordan talks about in reasons (b) and (c), the proliferation of tinker-proof boxes kills the software by preventing new developers from joining the old.
Is the only point of the GPL that whoever originally developed a program is sure of getting back the changes needed to run their program on a closed platform? So great, now you know a little more about the motherboard of my router. there's a checksum on ROM that will prevent you from ever /doing/ anything with that, but hey, 'the more you know' right? Or is the point of the GPL to ensure that everyone who uses software should be able to change how it works, share those changes with others, and come up with new uses for hardware, at least on their own machines?
If you don't like Tivo's hard
If you don't like Tivo's hardware, then don't friggin buy Tivo hardware! It's easy enough to build your own. This isn't rocket science, you know.
The problem is there will be
The problem is there will be zero incentive for an open machine. Open machines will always be inferior to TIVO like ones, because content will be more controled. So you end up not having the option you mentioned.
The only thing that Linux can leverage is that if you want to use a wonderfull kernel to start a content business, that would take you years and hundreds of million dollards to develop, you'll need to allow developers and users to run modified software.
That incentive is now gone, and the kernel developers apperently seem to love "that feature". Woah, but they still get the source back!
The point of the GPL
Or is the point of the GPL to ensure that everyone who uses software should be able to change how it works, share those changes with others, and come up with new uses for hardware, at least on their own machines?
Apparently the point of the GPL is to ram the FSF's anti-DRM agenda down everybody's throats? That's sure what it's sounding like.