Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

The FSF, GPLv3 and DRM 388

Posted by CmdrTaco
from the preaching-to-the-choir dept.
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. "
This discussion has been archived. No new comments can be posted.

The FSF, GPLv3 and DRM

Comments Filter:
  • by Abreu (173023) on Thursday August 10, 2006 @03:41PM (#15884360)
    One is a person, the other an ill conceived business plan...
  • by Anonymous Coward on Thursday August 10, 2006 @03:42PM (#15884370)
    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.

    • 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.
      • That turns his "signing key" into an "embedded key".

        But it's not an embedded key of the software, it's an embedded key of the hardware. Modified software will run just fine... on any other equipment.

        Now, the real question is whether this kind of "entanglement" would require the hardware to be GPL'd itself, including that key, just like linking to a GPL program or library would require the software to be GPL'd.
      • 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
        • 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 on
        • by Arker (91948)
          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, us
      • by Chops (168851) on Thursday August 10, 2006 @07:20PM (#15885639)
        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 [dwheeler.com] worth of community research without compensating the community in kind.
    • This argument keeps surfacing even though it has been debunked time and again. The GPL v3 only requires you to provide the embedded key if it is necessary to run the software. That's the letter and the spirit of the GPL v3. The second discussion draft clearly words out: [fsf.org]

      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 funct

    • 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 prob

  • 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.

    I'm already busy gearing up to protect myself against acronyms overload, thank you.
  • by megaditto (982598) on Thursday August 10, 2006 @03:43PM (#15884375)
    The FSF, GPLv3 and DRM, WTF, STFU, and RTFM

    There, fixed it for you
  • I think... (Score:5, Funny)

    by badasscat (563442) <basscadet75NO@SPAMyahoo.com> on Thursday August 10, 2006 @03:43PM (#15884380)
    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.
  • by Anonymous Coward on Thursday August 10, 2006 @03:44PM (#15884389)
    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.
  • by eck011219 (851729) on Thursday August 10, 2006 @03:49PM (#15884417)
    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.
  • by Anonymous Coward on Thursday August 10, 2006 @03:49PM (#15884418)
    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.
    • 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.

      It is also a problem if I want to use their code in a project that is distributed under a license that is more free than the GPL. And I do.
  • by gr8_phk (621180) on Thursday August 10, 2006 @03:50PM (#15884436)
    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?
    • ... you hit the nail on the head. The problem here is that RMS and the FSF are trying to protect freedoms by placing restrictions on them. Kind of funny, if you think about it...
      • It's called Free as in Richard Stallman. As long as he has no problem with what you're doing, you're free to do it, If he doesn't like it, he'll demonize it and try to 'protect' the world from it.
      • The problem here is that RMS and the FSF are trying to protect freedoms by placing restrictions on them.

        Its kind of like a law that punishes people that kidknap you off the street and lock you in their basement.

        Sure that restricts the kidnapper's freedom from doing what they want, but the hostages in the basement would beg to differ.

        The point of these DRM restrictions allow the original author of the code to prevent people down the line from going against the spirit of the GPL by adding DRM to the code they
      • The problem here is that RMS and the FSF are trying to protect freedoms by placing restrictions on them.

        Yeah, F*** those guys. It's like trying to make laws to protect people from other people. They must be clueless...

    • Suppose MS wanted to run Free Software on the next XBOX and didn't want people to mess around with it.

      For starters, I don't think MS would ever do that and if they did they wouldn't use GPL but some other kind of license they came up with.
      • if they did they wouldn't use GPL but some other kind of license they came up with.

        If they did, then they might well want to run some existing piece of free software that was only released under the GPL.

      • For starters, I don't think MS would ever do that and if they did they wouldn't use GPL but some other kind of license they came up with.

        I switched to the XBOX instead of keeping with TiVo so people wouldn't chime in with "but TiVo doesn't have the volume to get a custom chip from Intel". Suppose Sony wanted to use a variant of VLC for a media player in the PS3 rather than write their own. The point was that you can TiVoize the software by running on custom hardware where the user can't recompile for that

    • Well, in that example, there would be nothing stopping the end users from reverse-engineering the hardware and duplicating the proprietary tool chain.

      • So what's to stop us from reverse-engineering the hardware and disabling signature checks, or simply stealing the keys?

        Personally, I have no problem with requiring an open tool chain. Really, why are compilers still being sold? Make your money with tools like Photoshop, or Lightwave, or whatever other tools are required to make the content. Or use LGPL'd stuff and sell a proprietary library. Or...

        People who call the GPL "viral" and such really need a little imagination.
  • by Bryansix (761547) on Thursday August 10, 2006 @03:51PM (#15884438) Homepage
    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.
    • 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 [tivo.com] in compliance with the GPL.
      • by Bryansix (761547) on Thursday August 10, 2006 @04:15PM (#15884627) Homepage
        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.
        • by MojoRilla (591502) on Thursday August 10, 2006 @04:29PM (#15884713)
          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.
          • Really, what you need is to be able to allow any arbitrary key to be the key. With my FC5 system, I have to add the Livna key to my list in order to use RPM's key verification functionality. Of course, this does weaken security in some ways, but it enables it in others. What if TiVo bit the big one? Then any holes in the signed binaries could never be fixed, as the hardware enforces a set trusted list of -- you guessed it -- one key. Code trust should be based on user decisions, not the decisions of hardwar
          • 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

        • ...which effectively makes the source code useless to anybody.

          Why, why, why?
          I mean, the whole point of the GPL(v2) is this, you can take my code and do with it whatever you want. And than I can take your modifications/additions and do with it whatever I want. And look, you can take the code used in the Tivo and you can do with it whatever you want. Nothing wrong there...

          And then there's the fact that some hardware will only run manufacturer approved software. If you don't like that, don't buy the hard
      • by SpaceLifeForm (228190) on Thursday August 10, 2006 @04:25PM (#15884688)
        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.

      • 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.

    • 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

      • please note that I am talking about the intents of the GPLv2, not the intents of the FSF

        The intents of the GPL v.2 and the intents of the FSF are exactly the same. The trouble is that the letter of the GPL v.2 fails to reflect that, which is why the FSF is coming out with the GPL v.3. It doesn't change the intent; it just fixes some bugs.

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

      Er, no it wouldn't. Here's why...

      The TiVo license applies to what can be run on the TiVo hardware device. You are free to download the TiVo source, modify it as you see fit and run it on any compatible device; the TiVo device itself just isn't one of these. You are also free to attempt to hack the TiVo hardware to allow non-signed software to run but this is a different problem (and probably voids the warranty).

  • WSE (Score:3, Funny)

    by szembek (948327) on Thursday August 10, 2006 @03:51PM (#15884439) Homepage
    Worst Summary Ever
  • by Ed Avis (5917) <ed@membled.com> on Thursday August 10, 2006 @03:52PM (#15884452) Homepage
    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.
    • 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?
  • by nweaver (113078) on Thursday August 10, 2006 @04:06PM (#15884551) Homepage
    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.
    • 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 bi
    • by mpcooke3 (306161) * on Thursday August 10, 2006 @06:50PM (#15885495) Homepage
      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.
    • by Chops (168851) on Thursday August 10, 2006 @08:00PM (#15885818)
      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 [gnu.org] 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 [debian.org], 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.
  • Verifying the code (the TiVo portion that RMS hates) is equivelent to verifying Linus's key: Is this code released by the entity you trust. The only major difference is TiVo is more concerned, so it only RUNS code that has been signed by the trusted entity.

  • GPL 2 vs. GPL 3 (Score:3, Interesting)

    by toriver (11308) on Thursday August 10, 2006 @04:16PM (#15884630)
    "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?
    • If it was released with the "or any future version" language in the GPL it used, there's no problem.

    • It would, except that the default boilerplate is that you license it under the GPL v.2 "or any later version." Because of that clause, the code is effectively dual-licensed.

      Aside from that, however, no, they're not compatible. This is why Linux kernel code (licensed without that clause) can't become GPL v.3 without the consent of every copyright holder.

  • by adavies42 (746183)
    Yet another TLA....
  • Can I buy a vowel? (Score:2, Interesting)

    by 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. . .
  • RMS? (Score:3, Funny)

    by slapout (93640) on Thursday August 10, 2006 @04:50PM (#15884841)
    Now they're even using Root-Mean-Square against us? Is nothing sacred? Next they'll be taking away our sine waves!
  • Acronyms (Score:2, Informative)

    by ericlondaits (32714)
    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.

"It's when they say 2 + 2 = 5 that I begin to argue." -- Eric Pepke

Working...