The FSF, GPLv3 and DRM

whats-life-without-gpl writes "FSF has a thing against DRM. This article tries to explain why RMS isn't a DRM (Note that NewsForge is also owned by OSTG) fan and how GPLv3 is gearing up to protect against it. "

Comments

Of course RMS is not a DRM!

[Abreu]

One is a person, the other an ill conceived business plan...

Re:Of course RMS is not a DRM!

[vertinox]

And again, RMS is not something you just dump DRM on. It's not an ill conceived business plan...

It's a series of tubes. ;)

Re:Of course RMS is not a DRM!

[Chris Pimlott]

The summary actually says he's not a "DRM fan" but it's interrupted by the awkwardly placed "potential bias" disclaimer. Editors, you can just put that at the end of the summary, no need to jam it in the middle of a sentence where it destroys the flow.

Re:Of course RMS is not a DRM!

[bohemian72]

You left off a couple airports:

RMS: Ramstein, Germany
DRM: Drama, Greece

Re:Of course RMS is not a DRM!

[jeroendekkers]

Are you sure? According to Microsoft, RMS is a DRM system.

Re:Of course RMS is not a DRM!

[DittoBox]

I wish another stupid politcian would come up with another retarded description for something technical so all these no-so-funny anymore tubes jokes would rot in the bowels of internets history.

Oh look, another joke that wasn't funny.

The problem with signing

[Anonymous Coward]

Linus Torvalds, has a problem with this. He says that he himself signs the Linux kernel, and that that's his way of telling everyone, "You can trust this, it's from me." In an email message to the Linux Kernel Mailing List (LKML) on 23 April, he says that there are two types of keys: "One is an external key that is applied _to_ the kernel (OK, and outside the license), and the other one is embedding a key _into_ the kernel."

GPLv3 says that if any GPLed software carries an embedded key, this key should me made available to the users, but it makes no demands on the first kind of key. Linus has said that he would never distribute his signing keys, but the GPLv3 does not require him to release them. The key he talks about only describe the trustworthiness of the kernel. It in no way affects the freedoms of copyleft. It's only the embedded keys, which can be used to nullify the freedoms offered by copyleft, that need to be released.

Re:The problem with signing

[ichin4]

It's not quite so simple. Suppose a manufacturer were to build a computer that would only run an OS signed with Linus's key. That turns his "signing key" into an "embedded key". The problem here is that there is no fundamental distinction between the two kinds of keys; it's just a question of how they are used.

Re:The problem with signing

[AuMatar]

Its not the same at all. I buy Tivo hardware. I have the right to use it as I wish, since I own the hardware. A hardware mechanism that stops it from booting if unsigned prevents me from utilizing my rights as an owner. If the code Tivo uses is GPLed I'm being denied my rights twice- not only my rights as a hardware owner, but my rights under the GPL.

Linux signing the key is different because its unenforced. Its a way of recognizing that Linux blesses this version of the kernel, but it doesn't stop you from running any other version of the kernel.

Re:The problem with signing

[mrchaotica]

The detail is that the Tivo hardware enforces the authenticity of Tivo's signing key, whereas it's up to the user to enforce the Linus key.

But the effect is the same.

If a company, for example, edicts as policy that they won't accept any kernel save that signed by Linus, then that pretty much leaves everyone else out of the picture for Linux kernels, doesn't it? GPL or no, that company can't get a kernel from anyone else.

The difference is that the same entity is both the one releasing the code and enforcing the key. Linus doesn't have to release his key because he is not requiring it to run the code on anything (therefore, he isn't violating the license). Some company can create hardware that will only accept kernels signed with some particular key only if it doesn't actually distribute a modified and signed kernel itself (because it wouldn't be bound by the license in the first place).

This does bring up a flaw in the idea, though: what stops a company like TiVo from creating "unrelated" shell organizations so as to separate the kernel development and hardware development in order to get around this?

(note: I used the kernel merely as an example; there's no need to inform me about issues related to the lack of the "or any later version" clause)

Re:The problem with signing

[sumdumass]

so, suppose Tivo leases the hardware instead of letting you buy it. Then everything would be ok right?

You rights under the gpl require them to let you have the source code for GPLed software they distribute and possibly change it if that is your wish. Nothing in the GPL makes a claim that you are entitled to run that code on any specific hardware, is there? Not any provision that i know of.

Having hardware and not being able to run whatever you want on it is a different story. If you want to do something the manufacturer didn't intend, then you are going to have to work around the limitations of the hardware. This includes limitations purposly implanted by the manufactuer. But, unless the hardware is GPLed, I don't see anything in the GPL guarenteeing this ability.

This is a key example of why manufacturers don't want to provide GPLed drivers. It will be construed before the day is out that there is some fundelmental rights here and assure microsofts possition on the GPL being viral. Stop and really think about it from an angle outside the everything should be free attitude and look for the real issue.

Re:The problem with signing

[Great_Geek]

It seems to me this loophole is already closed by (all of) the drafts of GPLv3. It does not matter which key owned by whom, the KEY TEST (sorry, can't resist) is whether a modified version will run. If TivoV3 uses Linus' signature as DRM, then TivoV3 must give the user a way to sign using Linus' key; which means TivoV3 would be stuck.

The second draft is very explicit and well thought-out; the question is whether you agree with the intent. On the one side, RMS (and an all-star cast) with a strong philosophical position supported by well thought-out arguments. On the other hand, Linus with some spur of the moment comments opposing RMS (at least I hope Linus' comments are spur of the moment because his position is not well articulated).

Re:The problem with signing

[Hope Thelps]

Stop and really think about it from an angle outside the everything should be free attitude and look for the real issue.

The sensible angle to look at it from is "what am I trying to achieve in licensing my software?"

If you want users of your software to receive the right to modify it then these terms are likely to suit your aims.

If you want manufacturers to be able to limit the ability of recipients to modify your code then the GPL is probably not a good license for you, and never was.

Re:The problem with signing

[DShard]

Even if they lease the hardware to you, they still are distributing licensed software for your use. They can't change the GPL with another licenses agreement. Anyone implementing this scheme is getting away with it do to lack of attention from users. So that ISP who has a DSL modem running linux who isn't offering you the source code is breaking contract law with their vendors, namely the copyright holders.

It doesn't matter what manufactures want. They aren't obligated to support linux. They aren't forced to use linux in their closed embedded systems. But if they do use it, since it means less cost, easier maintenance and higher quality, they are agreeing to the contract under which that code may be distributed. In the case of Windows CE, there is a definite cost and an onerous contract you need to agree to. Linux to has a cost too. You need to offer the source to anyone you give the software to. Leased, bought or free, you still need to offer them that.

Re:The problem with signing

[AuMatar]

Not unless Linus creates the hardware. If he did not, he would be a third party and not in violation of the GPL. In that case it would be the person making the hardware who violated the GPL, and they would have to change their hardware (or get Linux to give out his key, but most likely change their hardware).

Re:The problem with signing

[AJWM]

I buy Tivo hardware. I have the right to use it as I wish, since I own the hardware. A hardware mechanism that stops it from booting if unsigned prevents me from utilizing my rights as an owner.

Uh, no, it's just that the hardware you bought was damaged by design when you bought it. Tough, you should have bought something else. If I bought a PPC Mac would the fact that it won't boot Windows be violating my rights as an owner? No. (Of course, some of us would see that as a feature rather than a bug.)

Re:The problem with signing

[AuMatar]

THere's a difference between having to make my code work and them preventing any code not coming from them from working. In the first case I know the risks, and if I fuck up the hardware its my fault. In the second, my rights as owner of the hardware are being removed.

And the GPL can easily be extended to hardware- thats what the GPLv3 does. It ensures that if you use GPLed code in your hardware product, that the user must maintain the right to modify the code. It protects the principles of Free Software that the GPL was created for. If the hardware maker wants to take away my rights as a user, they can write their own damn software to do it with.

Re:The problem with signing

[Chops]

It's not quite so simple. Suppose a manufacturer were to build a computer that would only run an OS signed with Linus's key. That turns his "signing key" into an "embedded key". The problem here is that there is no fundamental distinction between the two kinds of keys; it's just a question of how they are used.

The manufacturer building that computer is perfectly legal. Linus continuing to develop Linux and sign his copies of it afterwards is perfectly legal.

The illegal act -- and the signifier of the "fundamental distinction" you're after -- is when the manufacturer copies Linux in order to sell it to someone on his special computer. He may only make that copy if he's complying with the terms of the GPL, the same as it ever was, and in order to comply with the GPL, he must ensure that the people receiving software from him receive the same rights he had when he received it -- the rights to modify it for any purpose that suits them. Since he want to deny his customers that right (at least when running on the computer he sold them), the GPL v3 will (correctly IMHO) deny him the right to sell Linus's software along with his shiny new computer.

If he made that computer, and required that his end users download a kernel.org kernel signed by Linus in order for his computer to operate, he would be in the clear, as would his end users (since they aren't copying any GPLed work, the provisions don't have to apply). This situation would make RMS slightly unhappy, since the end user isn't free to modify his computer's software, but it's perfectly legal according to the terms of the GPL v3.

Of course, the DRM provisions aren't designed to attack that farfetched example; they're designed to counter the much more plausible example of Tivo-style DRMization of GPLed works, letting Tivo profit from hundreds of millions of dollars worth of community research without compensating the community in kind.

Re:The problem with signing

[Chops]

This does bring up a flaw in the idea, though: what stops a company like TiVo from creating "unrelated" shell organizations so as to separate the kernel development and hardware development in order to get around this?

I thought of this same thing after I wrote an earlier post in this thread, and when I checked out the GPLv3 draft, I saw that it was very cleverly handled even in that case:

The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances. (For instance, if the work is a DVD player and can play certain DVDs, it must be possible for modified versions to play those DVDs. If the work communicates with an online service, it must be possible for modified versions to communicate with the same online service in the same way such that the service cannot distinguish.) A key need not be included in cases where use of the work normally implies the user already has the key and can read and copy it, as in privacy applications where users generate their own keys. However, the fact that a key is generated based on the object code of the work or is present in hardware that limits its use does not alter the requirement to include it in the Corresponding Source.

So it doesn't force Redhat to give away their private signing keys, unless RHEL _refuses_ to install a non-signed binary (as opposed to merely complaining about it) -- the keys must be "necessary to install and/or execute" the resulting binary. It does cover a situtation where Tivo makes the hardware and the "Ovit" company makes a software image which runs on the Tivo:

• If Ovit's software runs only on the Tivo hardware, then the signing key is "necessary to ... execute modified versions in the ... recommended or principle context of use," and Ovit is guilty of copyright infringement (since the GPLv3 does not apply to their redistribution).
  
• If Ovit's software runs on other hardware than the Tivo (with "all the same functionality"), then their software is legal by the terms of the GPLv3, which is correct, because they really are making general-purpose media center software, and the lack of freedom on Tivo hardware is merely an irritation rather than a menace.
  

It's really slick. It's almost like they thought about it for a while before they wrote it :-).

Re:The problem with signing

[AJWM]

Looks like overall you're agreeing with my point.

But an otherwise general purpose computer that will only load specially signed binaries is "damaged by design" in the same way that a 6-slot motherboard that has had two slots filled with glue and sold (cheaper) as a 4-slot mobo is damaged by design. (And before you scoff at this example, review the history of some of the old DEC Q-Bus and VAX systems.) Another example would be a car inherently capable of 120MPH with a manufacturer-installed governor to limit it to 70 MPH.

"Damaged by design" implies adding something extra to limit the hardware's capabilities. Sure, it's the manufacturer's right to do so, and your problem if you're silly enough to buy it.

Re:The problem with signing

[MadEE]

That is right but you do not own the code or the schematics for the design. You have ever right to unsolder the chips and sell them on ebay if you wish or to beat the hardware with a hammer. Your rights end at the hardware; decisions in design belong to the makers of the hardware no matter how entitled you believe yourself to be to it. Your ownership rights end at what you can do with the device you own once it is in your hands it does not force manufacturers to accommodate your whims.

Re:The problem with signing

[sumdumass]

Sure it is yours, and if you bought something that will only boot to a signed binary program then thats what you own. You will have to either get around it on your own (maybe with other helping) or buy something else if you want to run your own software. There is nothing in the GPL that stops this. Also there should be nothign in it ever to stop this.

GPL or not, there is not and should not be any obligation for a vender to allow you to use the equiptment they are selling any differently then thier intended purpose. The GPLv3 will probably end up with hardware venders looking elswere for thier software. It will be a step or two back in getting vender supported drivers for linux or other hardware that can even run for that matter.

I'm starting to see the value of the BSD license at this point.

Re:The problem with signing

[Arker]

Actually the GPL was explicitly designed to make this sort of usage illegal, and arguably already does so. The problem is, this precise method of taking away the users rights was not anticipated when the GPL v2 was written, so there's too much ambiguity and room to argue it. Hence the 'bug-fix' in version 3.

The GPL was always, explicitly, designed to allow free usage of GPL code only to those who are willing to also allow that same freedom to those downstream of them.

Why you think that people "should" be able to strip those downstream of their freedom is a mystery, since you don't support the absurd assertion in any way.

Your assertion that hardware vendors will decline to use GPL v3, to the extent it's to be interpreted as meaning a significant portion of them will do this, is argued against by history. People claimed the same sort of thing about earlier versions of the GPL, but in fact, commercial vendors that are willing to return value have gravitated overwhelmingly to GPL vs BSD projects. And for good reason. BSD is only 'business friendly' to businesses that return nothing, as it allows that, but to anyone that returns value to the community, GPL is much more 'business friendly' as it prevents competitors from taking that work without returning value in turn. If, for instance, IBM contributes code to a GPL project, they can have some confidence that they aren't strengthening their competitors by doing so. The competitors can use the code, certainly, but they are in turn obligated to 'play nice' and return their additions to the community, so IBM as well as everyone else gets value returned. Licensing under BSD, on the other hand, is a black-hole: your competitors can take your contributions, leverage them to create a product that competes with you, and give you nothing back at all.

Companies that view BSD as being more friendly to their interests do exist, of course, but they're the companies we don't want using our code anyway. They're the ones intent on taking our code, tweaking it slightly, and then using it against us. They would never contribute anything back anyway, so who cares whether they like it? They're to be avoided, not helped.

The rest of the companies, the ones that understand that business is about creating value, appreciate the GPL, once they understand it. I see no reason to think that won't be even more true of v3 than it has been of v2.

Lay off the acronyms?

[megaditto]

The FSF, GPLv3 and DRM, WTF, STFU, and RTFM

There, fixed it for you

I think...

[badasscat]

FSF has a thing against DRM. This article tries to explain why RMS isn't a DRM (Note that NewsForge is also owned by OSTG)

We'd better get the CIA and FBI involved, along with the RIAA, NTSB, MPAA, ABC, CBS, CNN, AOL, MSN, and NBC. Oh, and be sure to alert the EFF and NRA while you're at it. Note that I am not affiliated with the RNC or DNC, although I am a FOB.

Of course RMS is not DRM!

[Anonymous Coward]

One of them tries to control what you can do by enforcing a system of burdensome legal restrictions, and the other is a system for managing digital rights.

Could we use a few more acronyms?

[eck011219]

FYI, that article really ID's the SNAFUs with DRM and OSS as pertaining to the GPL. I was KO'd when I read it - IANAL, but I wonder if it's BS or OK. Maybe I'll keep it on the QT until I know. Gotta run - I need to have a BM so I can leave for my AA meeting ASAP.

Preaching to the choir?

[Anonymous Coward]

Hardly. Slashdot features some of the most anti-GPL trolls around =- they can put the Microsoft Marketing department to shame on occasion.

*waves to the trolls* Hi! This is for you!

1) The GPL is only ever a problem for you if you want to distribute someone else's work that they already let you use for free.

2) See point 1.

Gift horse, mouth, examination via the anus... all those are things that spring to mind when I hear complaints about how restrictive the GPL is.

Re:Preaching to the choir?

[AuMatar]

THe only restriction is to make sure that the code stays free and ensure the rights of the truely important person- the user- for eternity. If you pro-BSD zealots can't understand that, we give up.

Re:Preaching to the choir?

[Millenniumman]

No it can't. It will always be free. The difference is that it can be used in proprietary software, and there is nothing wrong with allowing people that freedom.

OSS is properly a development model, not a philosophy.

DRM isn't the problem

[gr8_phk]

Suppose MS wanted to run Free Software on the next XBOX and didn't want people to mess around with it. They could have Intel modify a processor any number of ways (change the opcodes for a SIMPLE example) and provide a proprietary tool chain to compile the code. No DRM, yet the users have no way to modify and run the code on that hardware. Does GPL need to require a complete tool chain be provided when binaries are provided? It seems overkill, but custom (closed) hardware running free software defeats the GPL in the same way as DRM. I need to read the new draft, but I think it suggests the broader concept of denying freedom more than DRM in particular. Thoughts?

Linus needs to join the party

[Bryansix]

But Linus Torvalds, the creator of Linux, has a problem with this. He says that he himself signs the Linux kernel, and that that's his way of telling everyone, "You can trust this, it's from me." In an email message to the Linux Kernel Mailing List (LKML) on 23 April, he says that there are two types of keys: "One is an external key that is applied _to_ the kernel (OK, and outside the license), and the other one is embedding a key _into_ the kernel."

GPLv3 says that if any GPLed software carries an embedded key, this key should me made available to the users, but it makes no demands on the first kind of key. Linus has said that he would never distribute his signing keys, but the GPLv3 does not require him to release them. The key he talks about only describe the trustworthiness of the kernel. It in no way affects the freedoms of copyleft. It's only the embedded keys, which can be used to nullify the freedoms offered by copyleft, that need to be released.

Linus has repeatedly claimed that it is not for a license to decide how a manufacturer uses digital keys. He says the key are firmware, and therefore a software license has no scope or reason for controlling this.

Linus, the license has all kinds of business specifically prohibiting DRM on hardware that runs GPL licensed software and requiring internal keys. The reason they have to do this is because people like to ignore the GPL while using GPL software. These people should be sued. Changing the license to specifically prohibit certain illegal actions will make it easier to sue these violators later.

I hope that Tivo get's taken to court. It would be a triumph for open source efforts.

Re:Linus needs to join the party

[Decameron81]

The reason they have to do this is because people like to ignore the GPL while using GPL software.

Technically speaking they are not ignoring the GPL.

The purpose of the GPLv2 was never to force all hardware to run your custom software, it was to force other developers to publish their own changes to your code (please note that I am talking about the intents of the GPLv2, not the intents of the FSF). In other words: feel free to modify the software... just don't expect it to run in my hardware. And Linus simply chose the GPLv2 to distribute the kernel based on its intents, and not on the FSF's agenda (ie: the "quid pro quo" argument made by Linus demonstrates this point).

I realize that there's a lot of people here that think this is wrong, and I respect that choice. But why can't Linus make his own choice? Isn't him in his full right to do so?

WSE

[szembek]

Worst Summary Ever

He is against DRM, but that's not the point

[Ed Avis]

TFA gets it wrong. Richard Stallman is opposed to DRM; look at the 'Defective By Design' real-world protests of earlier this year. But that's not the point here.

Since the beginning the idea of free software (as rms sees it) is that if you use a program, you should have the freedom to modify it, among other freedoms. So if you have a Tivo, you should have the freedom to modify the software that runs on your Tivo. If Linux is GPLed, then it's clearly not allowed for the Tivo manufacturers to ship it with a label saying 'we forbid modifying the software'. It's also not allowed under the GPL for them to try blocking your freedom another way by withholding the source code. But under GPLv2 your freedom to change the program can still be taken away, by the manufacturer making the device only execute signed binaries (for which nobody but the manufacturer has the signing key). GPLv3 as proposed is about making sure your freedom to change the software running on your computer (or Tivo) isn't taken away like this.

Of course anyone can write GPLed software that has DRM restrictions. But if you use it, you should have the right to modify it, and remove the DRM if you don't want DRM on your computer. That is the important point.

Analogously: there is nothing in the GPL against charging a sum of money for the software. You can sell it for as much as you like. But if you do, the person who receives it still gets all the freedoms to use, share and change the program.

Re:He is against DRM, but that's not the point

[tchuladdiass]

Um, nothing that Tivo does prevents you from modifying the source for the GPL'd software they ship. You just can't run the modified version on the hardware they sold you. This is no different then if they put the binary on a non-flash chip, or some other read-only media.

So fundimentally, what's the difference between hardware only running signed code, and having the code on a PROM chip? Is the GPL V4 going to end up banning the use of read-only memory?

What's wrong with TiVo?

[Chris Pimlott]

I hope that Tivo get's taken to court. It would be a triumph for open source efforts.

Er, TiVo's one of the good guys, they release their source in compliance with the GPL.

Re:What's wrong with TiVo?

[Bryansix]

Because if you RTFA you will see that TiVo makes it impossible to run modified code on it's hardware which effectively makes the source code useless to anybody.

Re:What's wrong with TiVo?

[SpaceLifeForm]

Yeah, but.

They don't make it easy to hack the box and put fixes or
enhancements of GPLed software on the box.

Tivo went overboard, and locked down the entire box when
they could have done the following alternative:

Provide the source (as they do).
Provide a build environment so you can make enhancements
or install bug fixes to the GPLed software (they don't).
Provide a method to update the box (reflash if needed) (they don't).
Make sure the box will boot any kernel with GPLed userland (they don't).

Tivo could do the above, and provide their signed proprietary
binaries, and everyone would be happy.

Because of Tivo, RMS has been gamed, and he and Eben have
come up with a more complicated 'solution' to the problem.

All the GPLv3 has to do (with regard to DRM), is to require
that distributors provide the source, provide the build environment,
provide their proprietary binaries, provide a method to update
the box, and make sure the box will boot even if you change the GPLed software.

Everyone will be happy, and the spirit of GPL will be preserved.

Re:What's wrong with TiVo?

[MojoRilla]

The irony here is that by requiring signed binaries, TiVO is both restricting and protecting users.

Sure, by requiring signed binaries, you are restricted to run code only from TiVO. This restricts what users can do with their own hardware.

At the same time, since these devices are now on networks, there is a real possibility of them getting hacked. If TiVO ran untrusted binaries, this probably would have already happened. Of course, this happens now with Series 1 TiVO's, but you can't put them on the net without hacking, and if you are smart enough to do that, you probably have a firewall. So in some ways TiVO is doing a good thing by only running trusted code.

It is an interesting tradeoff.

Re:What's wrong with TiVo?

[metamatic]

At the same time, since these devices are now on networks, there is a real possibility of them getting hacked.

Well, first off my DirecTiVo has no network option, and it's still crippled.

Secondly, there's a simple solution which would enable them to comply with the letter and spirit of the GPL: Put a DIP switch inside the unit that turned off the signature verification.

And thirdly, yesterday I had a successful Denial of Service attack perpetrated against my TiVo by TiVo/DirecTV themselves, who somehow screwed up a bunch of people's boxes by sending an erroneous "You are no longer authorized" message.

I fear a repeat of the Bison fiasco...

[nweaver]

Bison (GNU's version of YACC) used to have the restriction that the output of Bison, since it was a large amount of code, was GPL. As a result, nobody used Bison except for GCC, because the liscence was untenible.

I fear that GPLv3, by trying to force RMS's notion of "Liberty" more strongly (anti-DRM provisions, anti-closed-hardware provisions) will be a repeat: GPLv3 based software will only be used by the real FSF zealots. Everyone else will avoid it.

Let us be thankful that Linus Torvald has more of a "tit for tat" notion rather than a liberty notion, and thus selected GPLv2 only.

Re:I fear a repeat of the Bison fiasco...

[noidentity]

I haven't heard the Bison story before, so I'll go by what you wrote. The difference is that the proposed GPL v3 restrictions will only affect those wanting to make closed hardware that runs a particular binary built from GPL software, while the Bison example affects anyone not wanting to use the GPL on the output. Unless I'm missing something, these differences are vast.

How would the proposed GPL v3 affect average programmers in a negative way, other than denying us pieces of hardware that come with GPL binaries and source code but which we can't use with modified versions of the source?

Re:I fear a repeat of the Bison fiasco...

[mpcooke3]

DRM will be used to attempt to restrict users rights to read documents, share documents, listen to music, watch films and possibly connect to other systems.

Microsoft, the RIAA and the MPAA have wanted to be able to do this for a long time.

We will then need a blessed versions of Linux that has been signed by a major financial backer like IBM who could give kickbacks to the right cartels just to be able to access the content we can currenly use and to read files sent to us from Microsoft machines.

I don't know if Richard Stallman stands much chance against the tide of monopolies and cartels that want to use DRM to restrict our rights(RIAA/MPAA) and kill competition (Microsoft).

But I'm glad someones trying.

Re:I fear a repeat of the Bison fiasco...

[Chops]

Bison (GNU's version of YACC) used to have the restriction that the output of Bison, since it was a large amount of code, was GPL. As a result, nobody used Bison except for GCC, because the liscence was untenible.

Correction: Bison used to have the restriction that the output of Bison was GPL, because nobody (including the FSF) had noticed that that was true. As soon as somebody did (in 1996 or so), the FSF put in a special exception and life went on pretty much as normal.

I fear that GPLv3, by trying to force RMS's notion of "Liberty" more strongly (anti-DRM provisions, anti-closed-hardware provisions) will be a repeat: GPLv3 based software will only be used by the real FSF zealots. Everyone else will avoid it.

Yes, the popularity of Bison has certainly suffered a staggering defeat; the Debian popularity contest, to pick a random example, shows it slightly less popular than X Windows, but slightly more popular than the ftp client. Doubtless we should heed your example and run screaming from the GPLv3 lest we, like it, and like Bison, become...

(shudder)

unpopular.

Nice use of the word "zealot" to describe harmless nerds who like to share their software, also.

GPL 2 vs. GPL 3

[toriver]

"You may not impose any further restrictions on the recipients' exercise of the rights granted herein."

Doesn't this mean that - since GPL 3 is more restrictive - that already GPL'ed software cannot be distributed under GPL 3?

Re:Help a clueless newbie out?

[brainnolo]

Don't know if you are just kidding (because this question has been answered many times). Basically, the output of GCC (the compiler) is not automatically GPL'ed and linking to glibc (the GNU C Library) and STL does not make your program GPL. If you use other GPL (not LGPL) libraries then you can't release your program under licenses other than the GPL. So, basically, linking to "system stuff" is ok, but if you have any doubt over a library you are using just check its license.

Re:Help a clueless newbie out?

[AuMatar]

Yes, if the libraries are GPLed. If you mean glibc, that library is released under the LGPL, so no your program would not.

Can I buy a vowel?

[Anonymous Coward]

So the FSF is GPLv3 and DRM with the RMS and what now? I'm in the military and therefore quite good at decoding stupid acronyms, but this is pushing it. . .

Re:Why does everyone keep quoting Linus?

[stratjakt]

More correctly, he can't make it GPL3. It's already been released, and he can't add restrictions to it after the fact, I don't see how he could make it GPL3 any more than he could decide to close the source and charge 699 bucks per CPU to use it.

Unless he wanted to write a brand new kernel from scratch, which would be a kick-ass idea. I wouldn't miss linux' monolithic dinkerishisness.

Violates SPIRIT of GPL.

[mrchaotica]

Complying with the letter of the license is not the same thing as complying with the spirit and intent of it. The GPL is designed to ensure that the user always has control over his hardware; since the TiVo won't run modified code, the user does not have this control. QED.

RMS?

[slapout]

Now they're even using Root-Mean-Square against us? Is nothing sacred? Next they'll be taking away our sine waves!

Acronyms

[ericlondaits]

FSF: Free Software Foundation
DRM: Digital Rights Management
RMS: Richard M. Stallman (founder of the free software movement, the GNU Project, the Free Software Foundation, and the League for Programming Freedom).
OSTG: The Open Source Technology Group.
GPLv3: GNU Public License version 3.

Re:Summus interruptus

[bradkittenbrink]

I don't think the disclaimer is awkwardly placed, I think the link text was chosen poorly. I think the slashdot editor was right in placing the disclaimer directly following the link (I'm assuming the editor had to do that). Whoever thought it was a good idea to say

<a href="http://trends.newsforge.com/trends/06/08/02/ 2210213.shtml?tid=147">why RMS isn't a DRM</a> fan

instead of

<a href="http://trends.newsforge.com/trends/06/08/02/ 2210213.shtml?tid=147">why RMS isn't a DRM fan</a>

is the one at fault here.

Calling a spade a spade.

[mikeal]

Let's just site down and admit it. Linus does not now, and probably never has, believed completely in the mission of the FSF or the freedoms given by the GPL.

He is a very smart guy, and knows that his argument doesn't hold water which is why he is declining to speak about it further. The truth is that Linus is buddying up with lots of companies, he's part of the corporate side of open source now not the community side. The relationship between money and open source has been great until now, when the needs of freedom are now coming in opposition to some of the buisness needs of open source money.

Linus didn't build the entire Linux kernel, a community did. If he is unwilling, or the companies supporting him are unwilling, to move the license forward in the interest and popular support of the linux community then we can branch the code now and start extending and reworking the linux kernel under the GPLv3. They know that, and they don't want to loose the communities support so they are trying to make it sound like the FSF is imposing their will on the community, rather than Linus and a hand full of companies imposing their will on the community that builds their product.

The provision in GPLv3 that Linus opposes refernces "Tivoization" in it's text, and if you look back Linus and others he's worked for and with have never viewed Tivo's products as a negative imposition on the rights of software and software developers.

DRM isn't necessarily evil.

[Anonymous Coward]

I don't understand. One side says "DRM is EVIL! We hate the RIAA!" and "If you don't support GPLv3, MS will lock your machine out of Linux!" (which they could do anyone regardless of what the GPL says) This is absurd.

DRM can be used for good. Let's say you want to build an electronic voting machine properly. You use entirely GPL source code. All parts are off-the-shelf and well known. Everything is open to public review. However, when you actually go to send the machines out, you want to be damn sure those machines are running the same code you put on them at the factory. That means locked and tagged boxes, and that also means DRM. Under the GPLv3 draft, you'd have to publish the secret key to the world, making that security worthless.

Another case: Let's say I make a system that monitors building security. I want to be open about how it all works, so I use GPL'd hardware. However, even my customers want to make sure that the software isn't tampered with. That means DRM. Again, if I have to publish the secret key, someone could write a modified version, sign it with my key, and get it on the machine.

The GPLv3 draft makes it impossible to create tamper-resistant software. (Note, I didn't say tamper-proof, there would still be ways around it, but as part of a layered security, it is necessary.)

Re:DRM isn't necessarily evil.

[Anonymous Coward]

You can see the source code yourself and be certain it doesn't contain any underhanded vote tampering. You could even use the GPL'd software to make your own voting machines, that could even be signed by you. You just couldn't sell voting machines that appeared to be signed by me, which is what the draft gplv3 would require I let you do.

The only time the DRM comes into effect is in those individual machines that are sent out to vote with. They'll contain a signed version of the software that will refuse to run if it is tampered with. The source code would be fully available and the machines themselves are standard hardware with just an extra drm chip in them. If you wanted, you could just run an unsigned version of the voting software on a normal PC.

The point of the DRM is to help make sure the devices are safe from tampering. This is not just for voting machines, but anywhere you need a device to be tamper-resistant. From voting machines to security servers to ATMs to who knows what. There are plenty of appliace-style devices that are running computer code that could benefit from being tamper-resistant. Currently, most of them are pretty basic and use more of what we'd call electronics, rather than computers, but that's changing. How about a computer that controls a building's elevators? Air traffic control, heck, in the future we might have ground traffic controls. The GPLv3 draft completely cuts off this entire line of legitimate use out of ideological hatred of one possible use of this tool.

If they put something like "If you sell drm'd hardware, then you also have to sell a version of the hardware, at no extra cost, that does not contain the drm restriction", this entire problem would go away. People could have their secure machines, Linus could sign his kernel without having to give up his key, and everyone comes out happy.

Bison fiasco? Numerous GPLv2 forks are unlikely.

[jetxee]

Most of GPL software will easily become GPLv3, thanks to this clause:

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

So if developers support it (I expect they will do), a lot of software will turn to explicit GPLv3.

Of course, one could always make a fork of some particular project and allow GPLv2 only. Yet starting from this point it is impossible to reuse any GPLv3 code in it. Whole libraries might become not suitable for this GPLv2 fork, at least the new versions of these libraries. Maintaining such GPLv2 forks may become really difficult. Linux kernel is probably one of few projects which may stay with GPLv2 for a long time. Most small projects are likely to make a transition to GPLv3, either willingly or by using some GPLv3 code.

What's wrong with that?

[Dr_Marvin_Monroe]

As long as they provide the source that they used before they signed, I think that's fair enough.

I'm with Linus, I don't think the license should be used as a "crowbar" into the hardware too. The GPL3 sounds like it places even MORE restrictions on what the user and/or developer and/or companies may do, not less... I'm against how they went about it too... it doesn't sound like the FSF even took anyone's opinions into account, RS and the rest just created an even more onerous license than the original. I don't see too many companies adopting it....

Take for instance, the following possible situation.... As a developer and small business man, this type of situation entirely possible, I've run up against this using GPL code. Company X developes a brand new, extra-cool heart monitor and defibulator widget based upon embedded linux. The product has been carefully tested at the factory, with good records kept, etc. The product uses a signed image to verify that it's the same image that went through tests and hasn't been modified. Product is FDA accepted and on the market, the company that developed the product feels fine taking the responsibility for the code. I know the license doesn't confer responsibility to the other developers, but the company has tested this particular image and they assume liability.

Now, some fool at the calibration outlet decides he's going to load some updated packages into the image, without telling anyone and without proper testing. He's creating a dangerous situation by running software that wasn't tested for it's particular use. According to the GPL3, he can resign the binaries and create a potentially injurious product, exposing company X to VERY SERIOUS liability that they had no part in.... Remember that company X did NOT want to release the signing keys, did NOT load the untested software on, but they will be held liable for any injury that results from it's being ABLE to be loaded. Company X here also may become the "deep pockets" defendant in this case, with the repair guy skating away....

No, this is totally wrong.... GPL3 should NOT be able to force this situation.

I don't like what TIVO is doing, and I sure don't like DRM, but I like what the FSF is doing even less. How about an open comment period. How about querying the free software developer as to what they want. I didn't receive any survey, I didn't find any place where I could provide feedback or vote either. They propose to speak for me, but I have not found any way to tell them what I want. People using stuff that I write will find the "either version 2, or (at your option)any later version" missing from any of my new works.

@*&% the GPL3!

Re:What's wrong with that?

[numatrix]

The license isn't a crowbar, it's a shield. It's a shield for YOUR code you're writing, a shield for the ideal that you don't want your code used unless others can modify it and use it. If someone's use of your code is limited by hardware restrictions and you want to further strengthen that shield by V3, then go for it. If you as an author don't like carrying the ideal that far and you think access to the source is enough, don't use V3 (as you seem to suggest you won't be). There's room for more than one OSS license.

The example you site has nothing to do with the GPLV3. The fault is either with:

1) The company who released hardware built on code that allowed others to change the code in an environment where that's a bad idea. (ie, build your own fricking code, don't rely on others who want their code to be modifiable, not just easy to print out and stare at)

or

2) The moron who loaded code onto a machine that could cause problems, probably violating federal law in using a non-FDA approved device (since I imagine the FDA approval only covers the device with specific code).

The GPLV3 is not evil and didn't cause anyone's heart monitor problems, the above did.

As for a comment period, check out:

http://www.fsf.org/news/gpl3.html

Scroll to the bottom, specifically the section near: "The Foundation will, before it emits a first discussion draft, publicize the process by which it intends to gather opinion and suggestions. The Free Software Foundation recognizes that the reversioning of the GPL is a crucial moment in the evolution of the free software community, and the Foundation intends to meet its responsibilities to the makers, distributors and users of free software. In doing so, we hope to hear all relevant points of view, and to make decisions that reflect the many disparate purposes that the license must serve."

Re:What's wrong with that?

[Arker]

Your example is clearly misinformed.

The only reason they would have to provide that signing key would be if they rig the hardware so that it is NOT possible to run modified binaries in any other way. This would be silly.

Instead, what they should do, is include a documented, warranty-voiding method to turn off the circuit that refuses to load unsigned binaries. As an example - you have a locked, tamper proof box (like all medical equipment) and the purchaser receives a key. They may, at their discrection, use that key, unlock the box, and change a jumper on the main board. Then replace and relock the case, reboot, and answer 'yes' to a confirmation dialogue with GIANT WARNING TEXT all over it. At this point, they can load whatever kernel they want. They've also voided the warranty and any and all FDA certifications of the box, so it's now illegal to use it for its original purpose. There could also be a permanently visible tamper indicator, I would suggest a red and green light placed prominently for all to see, clearly labeled, that would switch from green to red if the box was even opened.

There's no need to distribute any signing keys here, as the ability to run modified binaries is preserved without doing that. And legal liabilities are clearly shifted from the manufacturer in the event that a customer chooses to do that.

Get a grip.

[Corngood]

They can't stop you legally from doing anything you want with the device (or let's assume that for now), but there's no reason for you to expect that it is capable of anything other than what the manufacturer intended. They are perfectly free to cripple their product for whatever reason they like, so long as it is sold as such.

The real problem with trusted computing

[graf0z]

is not keeping secret keys secret. It's the missing possibility to edit the list of pubkeys which the trusted computing (TC) mechanism acccepts!

1. bad thing:
   1. Tivo sign their kernels using their secret key.
   2. Tivo's bootloader refuses to boot any kernel not signed by tivo
2. good thing (prevents trojan LKMs):
   1. RH sign their LKMs using their secret key.
   2. A RH kernel binary refuses to load any LKM not signed by RH.

As far as i understood the discussion, GPLv3 thinks that (1.1) is the problem, so it demands publishing the secret key. But that's wrong and renders (2) useless.

Instead, the problem is (1.2): i cannot append my own pubkey to the bootloaders list of approved binary signing keys, although i "own" that bootloader. Instead with (2.2), i can build and run my own kernel image embedding a different list of acceptable LKM signing keys.

So if one wants to prevent such a mess like tivo, (s)he should use a licence that demands that the software is not run on devices with a write protected TC pubkey list. I'd perfectly happy with TC if i could enter the fingerprints of valid TC-pubkeys into the BIOS.

Just my 2ct, m.