The Great Software Schism
Following Nicholas Petreley's discussion of the GNU GPLv3 debate from one angle, I'd like to look at it from another - that of the cultures of the two groups involved - and what this implies for the future.
The constant bickering between those who talk of "free software" and those who prefer the term "open source" is hard to avoid in the computing world. You only have to look at discussion threads on sites like Slashdot, Digg, Linux Journal or LWN.net to see the two camps rehearsing familiar themes. This eternal disagreement can be invigorating entertainment at best, or, if you're not in the mood, enervating in its tediousness. But this fundamental difference of viewpoint has not really been a serious danger to the overall free software/open source movement. Until now.
For with the recent publication of the white paper The Dangers and Problems with GPLv3 - and note that to emphasise its earnestness it is framed like an academic paper complete with alphabetical listing of authors and opening abstract - the background skirmishes threaten to escalate into a full-blown war.
On its own, the paper would have been bad enough. But matters have been exacerbated by the publication of a poll of top kernel coders. On a scale from 3 ("I wouldn't want to use v2") to -3 ("I wouldn't want to use v3"), 29 of the top kernel hackers were asked which version of the GNU GPL they would prefer to use. The average was an unequivocal -2.0: "I think v3 is much worse than v2". But what makes this "informal" poll all the more damaging is that both it and the white paper were instigated by Linus himself:
The reason the poll and the whitepaper got started was that I've obviously not been all that happy with the GPLv3
It wasn't meant to be really "definitive" - the poll was literally meant to get _some_ kind of view into how the top developers feel. I think the end result ended up being more definitive (just thanks to the very clear voting pattern) than we migth have expected.
So this is no mere rumbling in the ranks, but discontent at the very highest
Some of the problems outlined in the white paper seem to be down to misunderstandings of what the GNU GPL v3 is trying to achieve. To correct these misunderstandings, the FSF has released its own "clarification." But even allowing for these, there remains a key issue over which the two sides differ fundamentally in their views.
This concerns the use of DRM - traditionally "Digital Rights Management", but in FSF-speak "Digital Restrictions Management". For the FSF - and hence the GNU GPLv3 - the matter is simple:
Some computers are designed to deny users access to install or run modified versions of the software inside them. This is fundamentally incompatible with the purpose of the GPL, which is to protect users' freedom to change the software. Therefore, the GPL ensures that the software it covers will not be restricted in this way.
That is, DRM or similar is fundamentally antithetical to users' freedom, and therefore cannot be countenanced. But the authors of the white paper see things differently:
While we find the use of DRM by media companies in their attempts to reach into user owned devices to control content deeply disturbing, our belief in the essential freedoms of section 3 [of the white paper] forbids us from ever accepting any licence which contains end use restrictions. The existence of DRM abuse is no excuse for curtailing freedoms.
And what exactly is the essential freedom they are most worried about?
the freedom from binding the end use of the project. Without this freedom, it would be much more difficult to satisfy the objectives of the contributors, since those objectives often have expression in terms of the end use to which they wish to put the particular project. Therefore, in order to maintain the essential development synergy and consequent innovation stream it provides to Linux, we could not countenance any change to the GPL which would jeopardise this fundamental freedom.
That is, it is a freedom not so much for the users, but for the programmers. The white paper explains why its authors believe this is so important:
individuals with disparate (and sometimes even competing) objectives can still march together a considerable distance to their mutual benefit. This synergy of effort, while not compromising dissimilar aims, is one of the reasons Linux manages to harness the efforts of not only motivated developers but also corporate and commercial interests.
So, according to this view, kernel programmers must have the freedom from end use restrictions on the project or else this "synergy of effort" that has made Linux so successful will be lost. In other words, at the core of the kernel hackers' argument is a pragmatic concern: GNU GPL v2 is better because it will allow Linux to be more successful. This emphasis on success is made quite clear from the very first sentence of the white paper:
Over the past decade, the Linux Operating System has shown itself to be far and away the most successful Open Source operating system in history.
Linus, in his self-described "ode to GPLv2", underlines the pragmatic viewpoint with a telling parenthetical remark. He says:
You can use the end result any way you want (and if you want to use it for "bad" things, be my guest), but we ask the same exact thing of everybody - give your modifications back.
That's true grace. Realizing that the petty concerns don't matter, whether they are money or DRM, or patents, or anything else.
This is the heart of the difference between the free software and open source worlds. For the latter, GPLv2 is a highly-efficient licence because it works incredibly well as a way of getting the largest number of people working together to write great code, whatever their own particular interests or agendas - that's "true grace". But for the free software camp, using it for "bad" things is anything but "true grace" - quite the opposite, in fact; for RMS and his followers "petty concerns" like DRM or patents do matter - in fact, they matter far more than whether a project is successful. They matter because they negate the whole point of the GNU GPL, as stated right at the start of the licence:
the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users.
Or, as RMS said when I interviewed him in 1999:
The overall purpose is to give the users freedom, by giving them free software they can use, and to extend the boundaries of what you can do with entirely free software as far as possible. Because the idea of GNU is to make it possible for people to do things with their computers without accepting domination of somebody else. Without letting some owner of software say, I won't let you understand how this works, I'm going to keep you helplessly dependent on me and if you share with your friends I'll call you a pirate and put you in jail. I consider that immoral, and I'm working to put an end to that way of life.
There is no room for compromise in this purist world-view. As RMS emphasised in 1999:
the only reason we have a wholly free operating system is because of the movement that said we want an operating system that's wholly free, not just 90% free.
Hitherto those in the open source world have been able to let RMS live his uncompromising life because his system has worked amazingly well, and because they are pragmatists: they didn't really care about the politics implicit in the GNU GPL provided it didn't get in the way. But with GPLv3, it does get in the way, and the publication of the white paper and poll seems to mark an end to the truce that has existed between the two sides for nearly a decade.
The white paper ends with a plea:
we implore the FSF to re-examine the consequences of its actions and to abandon the current GPLv3 process before it becomes too late.
But as its authors surely know, there is no hope that the GPLv3 will be abandoned - not after the 16,000 emails or so that RMS and Eben Moglen, the FSF's General Counsel, have exchanged on the subject. Modified slightly, perhaps, but not in its substance, for example to weaken the clause aimed at DRM schemes: for purists, there can be no dilution of their basic beliefs - no "90%" solutions. Unfortunately, the pragmatists too seem to be painting themselves into a corner with their definitive rejection of the DRM clauses.
There is no obvious way out of this situation. The kernel coders will presumably stick with GNU GPLv2, as will others who are focused on programming efficiency and success; meanwhile, the GNU project and those programmers who agree with its unbending ethical viewpoint will adopt GPLv3. As a result, some code will be forked, with dual GPLv2 and GPLv3 licensing, and there will be growing confusion in the world of code.
The Great Software Schism will have begun.
Glyn Moody writes about free software and open source at opendotdotdot.
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
- SUSE LLC's SUSE Manager
- Non-Linux FOSS: Caffeine!
- 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