GPLv3: What the Hackers Said (Update)
When I wrote about the wrangling over the GNU GPLv3 licence a month back, it provoked a lively conversation in the comments. Given this evident passion among readers, I thought it would be interesting to ask the top hackers - the ones actually involved in the discussions - for their thoughts on the matter. So I contacted Richard Stallman for the FSF angle, and a bunch of the top kernel hackers - Linus, Alan Cox, Greg Kroah-Hartman, Andrew Morton and Dave Miller - for their view.
Since these people are all pretty busy, I didn't expect much of a response - the odd line here or there if I was lucky. But I was wrong: they all responded generously, with fascinating comments and insights into the GPLv3 and related issues. In fact, their replies were so detailed that they are too long to print here in full. Instead, I've pulled out what seemed to me some of the key points each was making (for the kernel coders, I've followed the order adopted in the GPLv3 poll). If you want the full story, I've put Richard Stallman's detailed thoughts, and the collected wisdom of the Linux hackers, online elsewhere, with individual links in each section below.
The purpose of the GNU GPL is to defend for all users the freedoms that define free software. It doesn't make sense in terms of open source. It's the result of implementing the philosophy of free software in the most strong way that we can. So all the version of the GPL have prevented middlemen from restricting subsequent users by changing the licence. Some free software licences permit that, for example the X11 licence permits that. The various BSD licences permit that. But the GPL was specifically designed not to permit that - you cannot add restrictions making the program non free.
Now, what we didn't have 15 years ago was the threat of making the program effectively non free by technical restrictions placed around it. That's what Tivoisation is. Tivoisation means taking a free program and distributing a binary of it, and also providing the source, because the GPL requires that. But when the user changes the source code and compiles it and then tries to install the changed program he discovers that that's impossible because the machine is designed not to let him.
The result of this is that freedom number 1, the freedom to study the source code and change it so the program does what you want, has become a sham. Tivoisation is essentially a way to formally comply with the requirement, but not in substance.
So we've come to the conclusion that this is more than just a minor issue. That this will be common, probably the usual case, if we don't do something to stop it. And therefore we've decided to do what is necessary so that our software will not be Tivoised. Our purpose is to deliver freedom to the user. (more)
I don't think there will necessarily be a lot of _practical_ fallout from it, so in that sense it probably doesn't matter all that much. It's not like we haven't had license "discussions" before (the whole BSD vs GPL flame-war seemed to go on for years back in the early nineties). And in many ways, it's not like the actual split between the "Open Source" and the "Free Software" mentality is in any way new, or even brought about by the GPLv3 license.
So while I think there is still a (admittedly pretty remote) chance of some kind of agreement, I don't think that it's a disaster if we end up with a GPLv2 and a new and incompatible GPLv3. It's not like we haven't had licenses before either, and most of them haven't been compatible.
In some ways, I can even hope that it clears the air for all the stupid tensions to just admit that there are differences of opinion, and that the FSF might even just stop using the name "GNU/Linux", finally admitting that Linux never was a GNU project in the first place.
The real downside, I suspect, is just the confusion by yet another incompatible license - and one that shares the same name (licenses such as OSL and GPL were both open source licenses and they were incompatible with each other, but at least they had clear differentiation in their names). (more)
There is no such thing as GNU/Linux. For an article like this it's really important to understand and clarify that (and from the US view also as a trademark matter).
I mean there is no abstract entity even that is properly called "GNU/Linux". It's a bit of spin-doctoring by the FSF to try and link themselves to Linux. Normally its just one of those things they do and people sigh about, but when you look at the licensing debate the distinction is vital. (its also increasingly true that FSF owned code is a minority part of Linux)
Linux is not and never has been an FSF project. I would say the majority of the kernel developers don't buy the FSF political agenda. Linus likewise chose the license for the pragmatic reason it was a good license for the OS, not because he supported the GNU manifesto.
Thus this isn't about the Linux people splitting from the FSF, its a separate project that happens to have been consulted as to whether it would like to use a new, allegedly better, variant of the license it chose.
Linux does use FSF tools but that doesn't make it a GNU project any more than this article will be an IBM project because it was typed on a PC, or a BT project because it used an ADSL line.
The Linux kernel being GPLv2 isn't a problem we can see for the future. It is a distinct work to the applications that run on it, just as Windows kernel is to Windows applications. The more awkward corner cases will be LGPL and similar licenses where you want the benefits and flexibility. The FSF have indicated they understand that and will ensure it works out. The licenses are about having barriers to abuse, not barriers to use. (more)
The process is not over, and we still hope to influence things. We would not have written that letter otherwise. The main reason it was not done earlier is that we just did not think it was going to be a problem, as the kernel was not going to change licenses. But the more that we realized this was going to have a problem outside of just the kernel, and affect the whole community, we felt that we should at least voice our opinions.
Also, please note that the DRM issues have changed over time from being very broad (which was at least admirable), to being explicitly targeted at only the Linux kernel. Now the license is worded to try to stop the "tivoization" issue.
This is the where a bootloader or bios determines if the crypto signature of the kernel is acceptable or not before it decides to run it or not. This means that only "approved" kernels that come from the company will run properly on the hardware.
Now this kind of restriction pretty much _only_ affects the kernel, not any other type of program. This is because only if you can control the kernel can you ensure that the system is "secure".
So it seems that the FSF is only targeting the Tivo issue, which us kernel developers have explicitly stated in public that it is acceptable to use _our_ code in this manner. So they are now trying to tell another group (us) what we should do to our code.
As the FSF has no contribution in the Linux kernel, and has nothing to do with it in general, we kernel developers are now a bit upset that someone else is trying to tell us that something we explicitly stated was acceptable use of our code, is suddenly bad and wrong. (more)
Well gee. We're programmers and we spend our time programming, not swanning around at meetings talking about legal matters and playing politics. We find things like licensing to be rather a distraction, and dull. So most people largely ignored it all.
It was only later in the process when the thing started to take shape, when we saw where it was headed and when we began to hear the concerns of various affected parties that there was sufficient motivation to get involved.
In fact this points at a broad problem with the existing process: I'm sure that a large majority of the people who actually write this code haven't made their opinions felt to the FSF. Yet the FSF presumes to speak for them, and proposes to use their work as ammunition in the FSF's campaigns.
And why haven't these programmers made their opinions known? Some are busy. Many work for overlawyered companies and are afraid that they might be seen to be speaking for their companies. Some don't speak English very well. Almost all of them find it to be rather dull and a distraction. (more)
For the kernel I'm pretty sure things will go on as they have before.
The problems are most likely for the projects under the GNU Project umbrella. All the copyrights to those projects, such as GCC, Binutils, etc. are all assigned to the GNU Project. So the FSF could, and almost certainly will, make all of those projects use the GPL v3.
As an aside, I will note that originally the FSF used to say that they wanted copyright assigned to them "to make it easier to enforce the GPL in court for software projects under the GNU Project umbrella." But as is clear today, it's also a power thing, in that having all the copyrights assigned to them allows the FSF to choose the licensing of the code as they see fit since they are the copyright holder of the complete work.
At the point of a relicense to GPL v3 for these GNU Project source trees one of two things could happen. Either the developers are OK with this, even if to simply "grin and bear it" and things go on under GPL v3. Or, the developers are unhappy with this, and fork off a GPL v2 copy of the tree and do development there.
In the end, even though they've assigned their copyrights to the FSF, the developers do control the ultimate licensing of these GNU projects. If they don't like GPL v3 and work on the GPL v2 fork instead, the FSF is at a loss because while they can mandate whatever they like such mandates are useless if the developers don't want to contribute to the GPL v3 variant.
So being the ones who do the development work is actually a kind of power which permeates through all of the politics. If the political folks do something stupid, the developers can just take their talent and efforts elsewhere.
I'm more than familiar with this process, since I was part of the group that forked the GCC compiler project many years ago because the majority of the GCC developers found the head maintainer (Richard Kenner) impossible to work with. Although he was quite upset about it, there wasn't much that Richard Stallman and the FSF could do about it. In the end the fork became the "real GCC" under GNU Project umbrella once more.
So the opinion of the developers matters a lot, especially when it comes to licensing. It could get messy is a lot of these projects fork, but the GPL v3 isn't a done deal yet so the FSF still has time to fix things up and make it more palatable to people. (more)
Glyn Moody writes about free software and open source at opendotdotdot.
Further to the interview I conducted with him, Richard Stallman has offered the following comment.
While I addressed the topic you proposed--version 3 of the GNU General Public License--Alan Cox chose instead to present a misleading picture of the history of GNU and Linux.
The GNU/Linux system comes out of the effort that I began in 1983 to develop a complete free Unix-like system called GNU. GNU is the only operating system that was developed specifically to respect computer users' freedom. Since our goal was to achieve freedom as soon as possible, we utilized the scattered existing free software packages that would fit. That still left most of the components for us to write. In those years, we of the GNU Project systematically developed the essential components of this system, plus many other desirable components, ranging from libraries to text editors to games.
In 1991, Linus Torvalds developed a kernel called Linux--initially not free software, but he freed it in 1992. At that time, the GNU system was complete except for a kernel. The combination of Linux and the GNU system was the first complete free operating system. That combination is GNU/Linux.
Cox says that Linux is not part of the GNU Project. That is true--of the kernel, Linux, that he and Torvalds have worked on. But the combined system that Cox calls "Linux" is more our work than his.
When Cox says that "FSF-copyrighted code is a minority in [GNU/Linux]", that too is misleading; he knows that just a fraction of the GNU packages' code is copyright FSF. What part do GNU packages compose in the whole system? Many are just as essential as Linux is.
In 1995, GNU packages were 28% of the system, while Linux was 3%. 28% is less than half, so that was a minority; but it is a lot more than 3%. Nowadays, after thousands of other groups have added to the system, both the GNU and Linux percentages are smaller than before; but no other project has contributed as much as the GNU Project.
Calling the combined system GNU/Linux is right because it gives the GNU Project credit for its work, but there are things more important than credit -- your freedom, for example. It is no accident that the GNU GPL existed before Linux was begun. We wrote the GPL to protect the freedom of the users of GNU, and we are revising it today so that it will protect against newer technical methods of denying that freedom. When you think about GPL issues, this is the background for them.
If the developers of Linux disagree with that goal, they are entitled to their views. They are entitled to cite their important work--Linux, the kernel--to be listened to more, but they should respect our right to cite the GNU system in the same way.
See http://www.gnu.org/gnu/gnu-linux-faq.html for more explanation.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide