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 level.

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.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

FSF should also look at other holes

Anonymous's picture

I see the FSF hurriedly trying to fix the Tivoisation bug, which is a good thing but i would like the FSF to look at all other corners where this type of thing could creep up from. we don't want a situation where theres GPL v4 shortly then GPL v5 then GPL v6.

People, Tivoisation is a serious bug and i commend the actions of the FSF in trying to protect users and developers of OSS. However, don't be in a big hurry. Look at all other ways this type of thing may happen then address them all in GPL v3.

Thanks FSF

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState