Slashdot Mirror


Linux Kernel Developers' Position on GPLv3

diegocgteleline.es writes "A group of 29 Linux kernel developers have recently come together and produced a position statement on GPLv3 (PDF, txt) explaining why, essentially, they don't like it. 'The three key objections noted in section 5 are individually and collectively sufficient reason for us to reject the current license proposal ... we foresee the release of GPLv3 portends the Balkanization of the entire Open Source Universe upon which we rely'. They've also run a GPLv3 poll."

7 of 395 comments (clear)

  1. Notable names *not* on the list by Schraegstrichpunkt · · Score: 3, Interesting
    • Linus Torvalds
    • Alan Cox

    Anybody else?

  2. The resurgence of the BSD license? by Anonymous Coward · · Score: 4, Interesting

    All this debate over the GPLv3 has been quite useful. These are issues that the community needs to discuss and consider. One of the outcomes of this appears to be a resurgence of the BSD license. I have talked and written to many open source developers who have become quite disappointed with the FSF and its stance with regards to the GPLv3. Many developers consider it far too restrictive, uncertain, and overly complex. Most of the time, developers just don't want to get bogged down in unnecessary legalities.

    A good portion of those people I have talked to have said that they are seriously considering using the BSD license for future releases (if it's within their power to make the change), or otherwise using the BSD license for new developments. Many gave their reason as being a mix of licensing simplicity, and commmercial friendliness. While it was far more difficult to take a GPL'ed application commercial, it's much easier to do with BSD-licensed software. Aside from a very small group of ideological thinkers, many in the open source community would like to be able to make a solid living off of their efforts. The BSD license allows for that quite easily.

    Going with a license as simple and straightforward as the BSD license often helps everyone. The developer can just develop, without getting bogged down in answering questions about how their software may be used, or other license-related issues. Users understand what they can do with the software much easier. That likely won't be the case for the GPLv3, where even many developers are unsure as to what it will permit and not permit.

    1. Re:The resurgence of the BSD license? by IllForgetMyNickSoonA · · Score: 4, Interesting

      Imagine a situation where a group of people works hard for a few years on an OSS project, brings it out, do the "marketing", sweat blood fixing the bugs and problems which never occured in the lab, builds up the reputation, finally sees that their product is GOOD and that there is a certain market for it and decides to try and make a living out of it by offering a commercial support while still keeping the product development at the same high level as up till now. The product, of course, should remain OSS.

      Now imagine that at the same time, a mediocre closed source company with a competing but much worse product is also trying to make the living in the same area. They have a professionaly organized support, a great market presence due to being the only game in the town, but a bug-ridden, bloated and unstable product with horrible performance and unacceptable user interface. The only thing that keeps the company away from bankrupcy is that their project was first on the market and has some name recognition attached to it (it's not far fetched at all - just look at all the god-awful Rational products, and you'll know what I'm talking about).

      For the company with OSS product, the life starts looking good. They are not rich, but they make a good living off of the hard work they invested in the past 4-5 years.

      Now, if the OSS company went with the BSD licence, what would be there to keep the closed source company from fixing/improving their product by stealing parts of the OSS comany's work? By doing so, they might be able to improve their product up to a point where their customers stop running away to the OSS competition (more often than not, customers are quite shy of changing the software they use, even if the software sucks). Gradually, the image of the closed source product becomes better, and the market share starts increasing again. Due to the good work of our OSS heroes.

      Where does that leave the OSS guys? They have a great product into which they invested a great amount of their time and blood, they have a good support, they decided to bet their future onto success of that product. And then they just said "look, guys, if somebody wants it, well - just take it away, we don't care".

      Algorithms shall be as free as possible, of course. I could imagine accepting an idea of a *LIMITED* (say, 1-2, years AT MOST) software patents for REALLY new/innovative stuff, and only in the case the patent holder also has a product using that algorithm. The code, however, is what I want to keep as safe from leechers and competition as possible. You can take a look at it, you can learn from it, you can contribute to the code, but you can NOT steal it and close it.

      BSD license is "a true freedom, my friend" for leechers. It's not a freedom for the author(s) of the code or for the code itself.

  3. They are at least partly wrong, IMHO by YA_Python_dev · · Score: 4, Interesting
    IANAL, but reading the draft of the GPLv3 (which is IMO pretty clear and easy to understand for a legal document) I think those kernel developers are wrong on at least two points:
    • "The additional restrictions clause will be a licensing headache for distributors and may cause splintering among the community depending on what restrictions are included."
      AFAICT all different customizations of the GPLv3 and LGPLv3 will always be compatible, no matter what restrictions you choose, so I can't see how this can be a problem for distributors;
    • in the article they say that "defining what constitutes DRM abuse is essentially political in nature"; but the draft never uses the acronym DRM or anything else ambiguos: the draft has a section titled "No Denying Users' Rights through Technical Measures." and I can't see how this (and the actual content of the section) can be ambigous or political.
    Everything is IMVHO, of course. And different opinions on something as important as the next GPL are extremely useful: the FSF has already demonstrated to be able to listen and change their opinion (see the changes between the first and the second draft).
    --
    There's a hidden treasure in Python 3.x: __prepare__()
  4. Waffle? I'd like some details. by twitter · · Score: 4, Interesting

    The use of GPLv3 as a tool against DRM co-opts the work of thousands of people for the FSF's political ends, which they consider a violation of said trust (they do consider DRM a bad thing, they just don't want to be pulled into the FSF's war against it).

    No one can make them change their license, can they?

    Interestingly enough, your summary contains almost all of the information in the article itself, and that's dissapointing. I'd at least have liked to see links to some of the supposed problems with encryption they claim has caused so many rewrites. Just the same, I'll quote what I think is the heart of what they say:

    ... section 3 forbids us from ever accepting any licence which contains end use restrictions. The existence of DRM abuse is no excuse for curtailing freedoms.

    Curtail who's freedom? Mine? No thanks and I'll see you later.

    DRM is something none of us should contribute to. Restricting user rights to use and modify and change software goes against everything that made the GPL a success in the first place. One of the reasons BSD is not as used is because software licensed that way could easily be used by those who are working against everyone's freedom. When you consider something wrong but don't do anything yourself and help others who would do the wrong thing, you are waffling. The poll, if it really reflects the opinions of those listed, is disturbing. Still, it does not matter unless someone can explain how they will be prohibited from continuing to use GPL2. If they really don't mind people Tivoising their work, why don't they just BSD it and let everyone bork the user straight up?

    --

    Friends don't help friends install M$ junk.

  5. RMS didn't change by nuggz · · Score: 3, Interesting

    This is just unfair to RMS his objectives haven't changed.

    GNU the GPL and the FSF exist because he wanted software to be distributed and used in that way, so he did it and encouraged wider participation.
    The Free software movement has been very successful.

    Now what is happening is some loopholes in the implementation of RMSs vision have been exploited, he obviously wants to correct this.

    The only reason these people worked together is that the different visions could agree on a single implementation at that time. That time is past and the different visions no longer agree on the correct implementation.

    For RMS to move forward in accordance with his vision he will have to create a new implementation that won't have the large mass of current users. He doesn't want to do this because many won't move, but he will have to in order to move forward.

  6. It's not that simple by YA_Python_dev · · Score: 3, Interesting
    Because of this we will see a lot of projects stay on v2, with a few (and maybe an increasing number) go to v3. But why is this a problem? I think split licences are a good thing in this context, because I support freedom of choice. That's what we're here for in the first place isn't it? More choice is better.

    Unfortunately it's not that simple. If I write a program and release it under GPLv2-only (which is probably a bad idea in the first place IMO, but it's what Linus did) and I use a library released under the "GPLv2 or any later version" and the new version of the library is released under the GPLv3 ("or any later version"), then I have to make a choice because the GPLv2-only is incompatible with the GPLv3:

    • I can stop entirely using that library (this requires writing new code);
    • I can continue using the old version of the library (this may requires duplicate work to fix bugs which are already fixed in the new version);
    • I can change my license from GPLv2-only to "GPLv2 or any later version" or "GPLv3 or any later version" (this is the most logical solution, that's why everyone want to make sure that the GPLv3 is very good or is not released at all: if it's released everyone will probably have a lot of reasons/pressure to switch).

    Disclaimer: I really like the GPLv3 because it garantees (even better than the GPLv2 that had some loopholes) that my software will be Free for everyone to modify and reuse, forever.

    --
    There's a hidden treasure in Python 3.x: __prepare__()