what fsf got wrong

Posted on by Luis Villa

The FSF got some things wrong in this process as well. (But I had dinner in between posts.)

  • The FSF has failed to convince people that patents are a threat. The FSF folks apparently believe (1) that patents are a threat to free software projects and (2) that patents are immoral. These are distinct issues. I think if they’d focused on (1) they’d be ahead. Clearly the kernel guys think the best way to cope with the patent threat is to ignore it. The FSF has not effectively countered that argument, and so the kernel folks (and lots of other people) think that v3’s patent clauses are unnecessary and political, instead of a necessary defense against a dire threat.
  • The FSF has failed to convince people that DRM is a taking of freedom. For the kernel folks (and a lot of other people) DRM is just a choice programmers have made on top of their stack. I tend to disagree (for reasons I’ll probably make clear in perhaps another post this weekend) but however you slice it, the FSF has clearly failed in convincing people that DRM built on top of Linux is the equivalent of shackles built on top of their code, and hence, that the DRM clauses in v3 are necessary.
  • I’m not sure if this is a failure or not, but it was pretty clear from the beginning that the consultation was going to be an open way to get feedback, but that Richard was going to make the final calls. Given how famously difficult he is to convince of anything, and how the big problems to be solved by the license were apparently chosen before any open consultation, it is pretty understandable that some people (like the l-k guys) were turned off, and have chosen to act outside the system instead of within it.

These are not minor problems, but I should note that these should not completely blot out all the good the FSF has done within the process. The committee process has been a very open one, where just about anyone can contribute in a meaningful way. (Hell, they let me on one of them.) The software used to track and collate comments has overall worked well, and made it easy to spot problem areas quickly. (Sadly, it was not used on a mission statement.) So overall, despite the big-picture PR mistakes made above, the process has been very good and very smooth so far. CC, and any other community pondering license changes, should be following along to learn how to conduct a license review process.

Published by Luis Villa

18 thoughts on “what fsf got wrong”

  1. Which of course raises the question: if I can see that, if others like Luis, Dalibor and Mark can see it, why can’t the kernel developers see it? Update: One more post on the subject from Luis, What FSF Got Wrong, has an extremely interesting comment from an OSDL employee that says “The kernel developers did not directly particpate in the GPLv3 review process because it was clear from the beginning that any direct comments would not cause change.” Nice excuse.

  2. What’s the Best Part About Open Source Analysis? We don’t have to do all the analysis. There are plenty of very smart people providing that every day. Witness Luis’ (of GNOME fame, and one of my favorite RedMonk commenters) excellent three part series on the recent GPLv3 flareup. Insightful, articulate, and best of all – very rational. I don’t agree with *everything* Luis says, but close to it. As a result, it would seem redundant for me to rehash this for you; just about everything I’d say on the

  3. I read the phrase “the Balkanisation of the entire Open Source Universe” in that piece. Kudos to Luis for separating the content from the rest in his blogs and hitting the nails on the heads regarding the concerns and mistakes of kernel developers and those of the FSF. At least judging by reactions of people on those licensing committees, like Luis, or Simon, the FSF is far from being the manipulative, scheming masterminds of the genocide on Open Source, or whatever highly questionable analogy goes along

  6. First let me say thank you for your really great blog entries about this topic.

    I think the FSF hasn’t failed to convince people that patents are a threat. I think every Free Software and Open Source Hacker know that patents are a threat, even the kernel Hackers have fighted (successfully) in Europe against software patents.

    Maybe with point two you are right. DRM is a relatively new topic and maybe it needs some time of talking and watching to recognize the over-all danger of DRM.

    But than i think the GPLv3 covers DRM only on one specific point, the point where DRM is used to remove users freedom to exercise the freedom given by the license (GPLv2). The “problem” is that there are people out there which have chosen GPLv2 not because of the idea of the GPL but because of the wording of the GPLv2. That’s nothing bad, but it explains their angry about the GPLv3 which will change in the wording.
    But the wording only changes because the world around have changed. The idea of the GPL is still the same. I think this is the big problem, the people who have picked GPLv2 because of the wording and not because of the idea are now derive the idea of the GPL from the wording of the GPLv2 and say that GPLv3 is completely different. But you can’t go from the wording of GPLv2 to the idea of the GPL and the FSF. You can only generate from the idea a license, 15 years ago this license become the GPLv2 because of the world of ~1991 and today this license will become GPLv3 because of the world (of DRM and software patents) in which we live today. It’s not the idea which has changed it’s the world and therefore the wording has to be adapted.

    I think point three is not a failure. It was always clear that the GPL is the license of the FSF and the author is RMS. So they should decide what the license should say. But the discussion process gives all people in the Free Software community a great possibility to participate in this process and to make sure that GPLv3 will have no bugs. That’s something which until now no other Free Software license has allowed.

  7. Thanks for the comment, BeS.
    (1) Everyone (or most, at least) believes that patents are evil; not everyone is convinced that they need to be fought in the license. That’s what I was trying to get at in the distinction between immoral and a threat- if they are immoral, you attack them in the legislature (which has been done); if they are a threat, you protect yourself in the license. That second part is what v3 is trying to do.
    (2) As you say, this is about user freedom, and people have not come to broad consensus on that.
    (3) Yeah, not sure it was a failure, but it at least turned some people off, perhaps prematurely and unnecessarily. Certainly the kernel guys have rejected all participation in the process- I can only assume because of their dislike of RMS. I can’t see any other sane reason to not participate. Thankfully the companies that pay most of them have not seen it the same way :)

  8. Mind you, the kernel hackers can more or less ignore patent threats. For one thing, they have a lot of contributors from industry, so they would have powerful backing in any case. For another, the rights to their codebase is spread over thousands of contributors, so any patent attack on the kernel would punch water. They simply don’t have a lot to worry about.

    Small projects run by just a handful of developers without corporate backing (ie. the majority of free software) are under much bigger threat from patent claims.

  10. The kernel developers did not directly particpate in the GPLv3 review process because it was clear from the beginning that any direct comments would not cause change. After the first draft, Linus and others made it clear what they thought of the “DRM” clauses. But Eban/Richard did not change their position one bit; they just clarified it and made it stronger. Why would any group of people who disagree want to particpate in a process where their input is ignored, they are belittled (see Eban’s comments about Linus), and it was never a consensus process at all? The members of Committee B, which is the only group that seems to not contain all yes people, is well aware of the kernel communities opinions. In fact, at the last meeting Committee B was surprised to find out that
    the concerns and opinions of the kernel community matched those of the Commitee.

  11. I’ve taken the liberty of editing that last post to point out that it came from an OSDL employee. I might note that it would also have had more credibility if it spelled ‘Eben’ correctly. :)

    Sch: Linus has been just as aggressive and belittling, if not more so- go see some of his posts on groklaw, for example. He’s been incredibly rude to PJ.

    More relevantly than any personal attacks one way or the other, I object to your characterization of the other commitees as yes men- you clearly clearly missed the point of my first essay. Most of us feel that (1) this is RMS’s process, and we’re helping fix the license as best we can within that framework, whether or not we use it later and more importantly (2) most of us feel that patents and DRM are substantial and important threats and abuses which must be dealt with. So if agreeing about freedom and wanting to make the best possible license within the constraints offered makes us yes men… well, then, I guess we’re yes men. But I think that’s a broken and bogus characterization, and I hope most people see through that if that is the tack OSDL and the embedded vendors are going to take.

  12. And I might add that the kernel guys could clearly have raised these objections within the system first. They’d come off less as whiny children and more as reasonable adults if they’d done that. Even if you think Eben and RMS are total jackasses, there is something to be said for holding the moral high ground- which frankly no party does at this point.

  13. The problem with the Kernel Developers position on DRM (and this can be seen in Debian-Legal’s attitude to the Creative Commons anti-DRM language as well) is that they view DRM as a technology, not as an extension of copyright law. DRM has power only through law: it would not be illegal to remove or reverse-engineer DRM otherwise. But too many hackers idealise DRM systems as code and DRM-laden files as data. They ignore the legal dimension, and this leads to confused reasoning.

    To cite the FSD or DFSG freedom to modify code in support of this new excess of copyright law is an example of that confused reasoning. You cannot modify BSD-licensed code to remove the copyright header for example, and you cannot add the string “all rights reserved” to the top of a GPL-2-licensed file, yet despite restricting your freedom in this way neither license breaks the FSD or the DFSG. If the BSD license said “you may not write a script to remove this header”, would that break the DFSG?

    DRM is an extension of copyright law that can prevent computer users from exercising their freedoms. Those who support DRM seem to view code, rather than human beings, as the subject of Free Software’s freedoms. This is an impoverished understanding of freedom. But if you must write DRM code, the GPL-3 will not prevent you. It just removes the legal privileges that such code would otherwise have to remove users’ freedom.

  14. I am puzzled by the view that patents are immoral. Copyrights and patents are simply laws that are designed to encourage certain economic behaviour (although the French/German approach to copyrights are more based on personal right). If you couch the discussion as one about morality, you will lose a large portion of your audience, because these decisions are clearly so economic in character. That said, complaints about the patent system have been common throughout US history and the system has been modified to deal with the problems (see the change to eliminate “submarine patents”). Similarly, I think that the kernal guys have missed a major chance to try to persuade Eben and Richard. In fairness, I am running one of the committees so I have made my decision to participate, but I think that they are open to persuasion on many issues. Frankly, DRM does not appear to be an issue in which they are willing to compromise, but you will never know if you are outside of the process.

  16. GNU/Solaris and GPLv3…

    I found an interesting article at The Register yesterday, “Is ‘GNU/Solaris’ emerging from the Microsoft-Novell deal?” It would be awesome if Sun released the Solaris kernel under the GPLv3, because I think that would be a chan…

Comments are closed.