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."
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.
Notable names not on the list
Yes, they are:
Name Vote
Linus Torvalds -2.5
Alan Cox -2.0
Live today, because you never know what tomorrow brings
Good job Linus deleted the 'or a later version at your discretion' clause really, isn't it?
Otherwise in 10 years time it would be licensed under a GPLv10 license, where contributors have to give up their paid jobs, move to Stallman's compound in Waco and donate all their cheetos to the communal food store next to his Sparc station.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
By summer it was all gone...now shesmovedon. --
"Linux kernel developers have always been shortsighted when it comes to freedom."
Forcing a specific morality is not freedom any more than overthrowing one tyrant and replacing it with another is introducing democracy.
Then again, I love BSD licensing because in my opinion it is the free-est. It doesn't try to force a specific belief onto anyone, yet I haven't seen anyone hobbled by its lack of forward thinking yet. Freedom isn't demanding a social utopia, it is showing the light and the right way to go about things and hope others come to the same conclusion. Not everyone will -- it is human nature. However, there is less potential for the leaders to become corrupt when they cannot force the belief.
Ultimately, I think RMS has become corrupt with his own beliefs and if offered the power, would force others to follow his thinking. This is the case with v3. And this is where the most forward thinking is to take away the freedom from choice and demand people be allowed to make mistakes. V3 demands 100% adherence to the faith. V2 asks kindly that you remain faithful. BSD tells you that the faithful will remain devout but the choice is entirely yours.
What Stallman is trying to do is to prevent hardware from running GPL'd software if the hardware prevents its owner from running versions of the software that have been modified. Although I'm for free software as in speech, I think trying to use the software license to control what a hardware manufacturer does is inappropriate and overstepping.
If a manufacturer creates hardware that limits a person's ability to modify the software that runs on it then let the market forces apply pressure. There won't be the plethora of open source software from the community to run on it and that will give an advantage to products that do allow the community to add to the product's value.
The race isn't always to the swift... but that's the way to bet!
- "The additional restrictions clause will be a licensing headache for distributors and may cause splintering among the community depending on what restrictions are included."
- 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).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;
There's a hidden treasure in Python 3.x: __prepare__()
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:
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.
"Why fix it then?"
It is getting broken. The current actions of certain companies to use the freedom of GPL code without passing on that same freedom to recepients of that code, through the use of, for example, DRM hardware detecting and preventing modification of the code, essentially is an example of 'broken'.
Anyone vaguely familiar with the history of the FSF and RMS can recall one of the origin stories of the FSF, involving RMS recieving a buggy printer driver he wasnt allowed to fix due to its proprietary nature and closed source. Had he recieved the source, but then the printer had refused to use the updated drivers, nobody can reasonably come to any other conclusion than that DRM restrictions on the running of GPL code would be just as disallowed in GPL v2.
The changes are exactly in line with the FSF reasoning, like it or not, and a natural evolution of the GPL to cope with new issues. Anyone more concerned with the freedom of those wanting to restrict others has a perfectly good selection of BSD type licenses to use. For those deliberatly and knowingly placing code under GPL these updates come as no surprise, and are not at all unwelcome.
"Those of us who care will probably fork Linux (which *can* be done, dispite Linus' incorrect claims to the contrary)."
That all depends on what you mean by "Linux." If you are talking about the kernel then no, you CAN NOT unilaterally put it under a different license. Not under the BSD license, not under the GPL 3 license and not under any a proprietary license.
The race isn't always to the swift... but that's the way to bet!
Yeah well many of us don't like BSD licensing, not because it's not free (it is), but because it doesn't guarantee that source code will be made available. Personally, I like the LGPL best. That's the ideal license in my mind. Use it in your closed app if you like, but if you change anything in the supplied code, you have to show what you changed. No "forced" opening, but a guarantee that improvements make their way back to the project.
Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
They list three primary reasons for not wanting to use GPL 3:
1. They are against the DRM clause because they believe it is an "end use restriction". The DRM clause prevents distributors from calling the program a 'technological "protection" measure' which ensures that others are free to distribute it. Perhaps it's redundant, but it adds no restrictions on end-use.
2. They are against the "Additional Restrictions Clause". This is one of the most sorely needed updates to the license. It helps make it compatible with other free software licenses. They're afraid that this will encourage too many alternative licensing usages. Unfortunately, reality is that there are already too many licenses out there now and this clause is trying to be as useful as possible in the current environment. If everyone agreed with and used GPL2 this clause would be unnecessary.
3. They are against the patent clause because they are afraid it will scare away corporate help. Here they may be right. However, the GPL is intended to be for "free software", not for general "open source software". This clause is certainly in the spirit of the GPL although it might make it harder for some projects to get help. Support for this clause will vary depending on how one falls on the practicality/idealism spectrum.
In summary, their reasons seem based primarily on a desire to see their work disseminated as widely as possible and not to keep the software free. I'm disappointed in them.
That's what the GPLv3 attempts to ensure: that for example the master keys controlling which programs can run on a computer are given to the owner of that computer, as opposed to preventing the owner from modifying the computer or its programs, or running other programs on the computer. It puts decision-making in the hands of the owner of the computer, where it belongs.
That is YOUR morality. How dare you impose your morality on someone else?
It's easy, really, I'm not going to use DRM infected stuff. I don't have to tell you about your licenses. I don't have to tell the FSF about GPL V3. I don't have to tell anyone how to do anything, and no one would listen anyway, but I won't be told what I'm going to run. If you don't fix DRM problems and all your work gets sucked up by greedy DRM publishers, you will soon be without users and none of them will be free. Do as you will, but don't blame me when your branch of code ends up, abused and stagnant. I promise, "experiments" into DRM will be avoided.
"preserving freedom" by removing freedom is hypocritical of the FSF.
The freedom preserved has always been that of the user. To preserve that freedom, developers of GPL'd code gave up the "freedom" to be anti-social and prevent the user from being able to use, modify and share their changes. Tivo has shown how GPL'd code can keep users from doing those things. Change is required and I've yet to see anything positive from anyone but the FSF.
Friends don't help friends install M$ junk.
You mentioned a lot of licenses, but GPL is the main one causing problems. BSD, Apache, LGPL, etc. can be used in pretty much anything. GPL takes the position that only when Richard Stallman controls your licensing is your software truly free.
Stupidity is like nuclear power, it can be used for good or evil. And you don't want to get any on you.
This follows on from my last post on here, and it was something I was thinking about only a few moments before I saw the article.
AFAIK, Autoconf's version number hasn't changed in at least two years. I can also remember looking into it a few months back and discovering that at the time anyway, GNU Make only had two maintainers.
The FSF has completely lost focus, IMHO. Core elements of the toolchain are not being actively maintained, and several of the people who were maintaining them have been employed by Red Hat, causing a conflict of interest which cannot be conducive to Linux's long-term wellbeing...or at least that of the GNU project, for those of you who like to split hairs.
I've had FSF advocates reply to me before and talk about how the anti-DRM crusade is important...fine and good, but let me mention something which I think is even more important.
For all that Stallman has written and said, and continues to say, about software freedom, said freedom isn't going to matter much if the software itself ceases to exist. I'm also not talking about KDE or anything on the surface, either...I'm talking about the core knowledge behind how to assemble a Linux system, and the tools themselves which are used to do that. Yes, I know the Linux From Scratch project will immediately be pointed to, perhaps...but aside from them and perhaps Gentoo, who else is there?
Aside from Debian, Gentoo, and Slackware, the rest of the major distributions are corporate, and created by people with far more interest in imitating Windows as closely as possible than in technical integrity. You only need to visit their forums or look at the track record for security of some of them to know that. Red Hat began Linux's decomposition process, but the other companies are continuing it. It's happened quietly, but on a number of levels, I honestly believe that Linux's roots are seriously endangered, currently...and as any botanist will be able to tell you, if the roots are compromised, although it won't happen overnight, there's a very good chance that the entire tree will eventually die.
I'd ask anyone who reads this and who cares about Linux's future to go and build Linux From Scratch at least once...as that information will only survive if it exists within a large enough group of people. I've heard about the concepts of installfests, which are great...but if it could be arranged, I think source installfests, or "compilefests" could be fantastic as well. I feel that on a technical level, rather than on a political one, there needs to be a return to some core principles:-
a) Compilation from source, so that we're actually *using* source code rather than just talking about it. Source code availability is Linux's fundamental strength...there are any number of people in the corporate world who'd love a scenario where Linux was purely binary only, a la Windows, because they know how much that would disempower Linux users if they could bring it about. For all the talk about the convenience of binary rpms and debs, use of these is actually "helping" Linux to death. Whining about binary drivers on the one hand and using apt on the other is simply rank hypocrisy, IMHO...and it also doesn't genuinely solve either problem.
b) Individuals with sufficient technical ability once more creating their own systems on a wide basis, and not merely relying on predigested, corporate distributions which are often severely crippled for the purposes of compiling source, use deeply unreliable and broken package management systems, and which do not adhere to standards. Decentralisation used to be another of Linux's major strengths...again, something else which we're losing. The ability to "roll your own," is still there, but if we don't keep using it, we *will* lose it...there are a lot of people out there who as I said are waiting for any opportunity they can get to take such an ability away from us.
c) A commitment as individuals to the adherence to such basic things a
The issue is that technically while GPLv2 code can be incorperated into GPLv3 code, the reverse is not nescisarily true.
Under GPLv2, I can write a security library that touches the TPM chip on a PC, verifies that the programs you are running are what they are reporting to be and reports back with the results. The obvious first step is that my library has to verify that it is itself uncompromised if my library can't verify it's integrity, no programmer can rely on the results of my library's responces.
If my library uses other GPLv2 libraries in the compile, I can verify & lock to specific versions I trust, that's fine. However, GPLv3 requires that I accept and allow any changes to the supporting libraries to be incorperated into my code - thus negating my ability to fully trust my own code.
I am aware that people have issues with trusted computing, DRM, etc. However they each have thier place in the world. I don't agree with Tivo's decision to incorperate a lockout into thier system, but given the position they are in between providing the features customers want and being sued by the owners of the content that the people want, I can understand it. I certainly think that trusted computing and DRM have places where they are important - medical, financial, and security environments come to mind immediately. The GPLv2 allows Linux and GNU software to be constructed & run in these environments. The GPLv3 does not.
RMS' take on this is 'tough, don't use our stuff if you're going to work in those environments', Linus' and these developers is "use the code, give us your improvements back, and we'll take it from there." Personnally I am in the camp with Linus, the overall codebase is what is important. As long as companies are developing applications and giving us back the improved code, the GNU/Linux project get's better - everyone wins in the long run. The individual embeded items don't matter. So Tivo created a device that you can't upgrade yourself. [shrug] You wouldn't have been able to if they put in a ROM instead of FLASH memory anyway. However, I can take that code they returned to the community, redirect the driver interfaces for it & make a DVR out of my PC, or even my Lynksys router if I package the videostream from a PC with a tuner card. The device Tivo made is almost irrelivant in the grand scheme of things, it'll sell for what 2 years? maybe 3? 50 years from now, I can take thier code and make it work.
Think about it this way, who do you want scrutenizing Linux for security flaws? My answer is everyone. My reality is that it's usually done by 2 camps - malware writers (both for real use & theoretical exploration) and corperate employees who are paid to do it. I know I hate reviewing code looking for tiny errors that don't normally effect it's operation. I would rather run off to a dozen new projects than spend a month looking for why the function foo() screws up when you pass it numbers that factor into a prime > 2^64 but not less than that. Most people are the same way. With that in mind, if I want security improvements, I want guys from a security company working on my code not on their proprietary code. If in order to get them to do that for me, I have to allow them to use my code in a proprietary device that only runs versions of my code that they have verified as meeting their standards, that's a tradeoff I'm willing to make. I get code improvements I can use in this project and the next, they get to market their system as secure.
For me it's interesting to note that RMS has said that there would have been no issues with TIVO if they had used ROM instead of FLASH to store the software. Because TIVO gave thier customers a means of updating their system without having to send it back to the factory, he feels it's a violation of the principles of the GPLv2. To me, that's where GPLv3 crosses the line from a software liscense into the realm of technical mandating.
That company could take a GPL program and use it and then claim "no, it's something we wrote ourselves" just as easily, or even easier.
If you assumme the company is going to lie and get away with it, then it does not matter if it is LGPL or GPL or if it is commercial software that they are supposed to buy a license for.