One of the most controversial freedoms of free software is the right to simply take the code and go make your own competing project -- what is popularly called a "fork". It's controversial because it seems like a betrayal of the original developer; because it distributes resources into competing groups, which may waste effort; and because it may create confusion in the marketplace of ideas that is free software distribution. But it is a critical freedom to have, and the recent fork of LibreOffice from OpenOffice.org, like the fork of X.org from Xfree86 years ago, shows why it's so important.
In the free software community, there's a pretty big fear of "forks". After all, if the project is free-licensed, there's nothing preventing any one developer from taking the whole project and developing their own version, maintained on another site.
Revolution is bad, but oppression can be worse
We fear this, because it's wasteful. If it happened all the time, free software development would disintegrate into zillions of tiny pockets with no room for large organized projects -- it's kind of like the fear that absolute democracy will result in "mob rule."
Others fear that competing projects will create a situation of "too much choice" which will confuse users with a plethora of nearly-identical offerings.
However, by and large, everyone involved appreciates this, and so even though it isn't forbidden by the licenses, it rarely happens. So why don't we just write the licenses such that they do forbid this kind of anti-social behavior?
One could make an abstract ethical argument for why this shouldn't be attempted. Or one could attempt to show that there's no legal way to do it without unintentionally affecting "legitimate" freedom to modify the software.
Or one could point to some high-profile examples of why the freedom to fork is a critical assurance that governance in the free software community is truly "by the consent of the governed." Revolution is bad, but oppression can be worse.
The "Benevolent Dictator" and the "Consent of the Governed"
There's a popular mental model that people like to raise about how a free software project should be run by a "benevolent dictator." That is to say, there should be one person with the vision for the project who gets to say where it should go and how it should get there -- a gatekeeper to control what is acceptable for the development trunk and what isn't. It's felt that this kind of strong leadership will keep the product from becoming diluted or bogged down in unnecessary complexity.
There's a popular mental model that people like to raise about how a free software project should be run by a "benevolent dictator"
But I've always distrusted the "benevolent dictator" concept, because I've always wondered what that "benevolent" part means. Benevolent to whom, I wonder? Isn't that supposed to be determined by the consensus of the group? And how do we measure that? What can a truly benevolent dictator do that an efficient democracy can't?
Fortunately, the benevolent dictator is a fiction. Real dictators rule by might and their subjects have no freedom to resist. But while it may occasionally feel that way on a free software project, for those too lazy to take action, the reality is that there's absolutely nothing stopping you from walking away with the whole project on your own -- you can always create a fork.
But of course, you'll have to have a pretty good reason if you want all those other folks on the project to follow you, instead of the existing project leader. That may involve any number of factors, from technical competence to that indefinable quality of charisma.
But there is one other way too -- the "dictator" can give into the power and do something the community collectively regards as phenomenally stupid or unethical (they can break the unwritten rules of free software communities), or, when the dictator is appointed by some outside authority, they can be succeeded by someone the community doesn't trust.
And that's where the freedom to fork gets it's real importance: it is an ultimate sanction, the realpolitik that ensures that free software communities really are governed by the consent of the governed.
LibreOffice and X.org
That's what just happened with Oracle and OpenOffice.org. Sun got bought out by an entity who is simply not trusted by the free software community. Moreover, that company is in fact taking steps to attack the central values of the free software community; and it is not taking the steps to further the best interests of the OpenOffice.org project (a project which has long suffered from bureaucratic ossification and slow response to developers, even under Sun).
Apparently the management of the company has learned their strategy from proprietary software, where a political executive decision can kill a project, regardless of developer or user interest. But with free software, the power lies with the people who make it and use it, and the freedom to fork is the guarantee of that power.
I doubt seriously whether the original "OpenOffice.org" project will live much past this fork
I doubt seriously whether the original "OpenOffice.org" project (retained by Oracle because of the trademarks on the name -- which can be bought, sold, and licensed like other proprietary intangible properties) will live much past this fork. It's too obvious that the advantage lies with the developers, a more agile development environment, and freedom. Besides, the new brand identity, "LibreOffice" speaks much more directly to the interests of free software developers and users.
And Richard Stallman has already given his imprimatur on the project:
"I'm very pleased that the Document Foundation will not recommend non-free add-ons, since they are the main freedom problem of the current OpenOffice.org. I hope that the LibreOffice developers and the Oracle-employed developers of OpenOffice will be able to cooperate on development of the body of the code."
Make no mistake, LibreOffice is a popular revolt -- very much like the revolt a few years back when the XFree86 project decided to change to a less free "non-GPL-compatible" license by adding a more stringent advertising clause. That was certainly a mistake -- the whole developer community practically abandoned the project overnight and formed a new one (X.org) under the old license. Since then, X.org has quickly become the "real" X window system in GNU/Linux distributions.
Tools of Revolution
The situation reminds me of some other controversial freedoms in the real world: the freedom of expression, freedom of assembly, and right to bear arms guaranteed in the US Constitution's Bill of Rights, for example. Certainly these are not universally understood or agreed upon, but it is interesting to think about why they are there.
What they are, really, are tools of revolution, put in the public's hands as a guarantee against the worst excesses of government. 'After all,' we may imagine, 'if it gets too bad, we can just revolt.' Invariably, cooler heads prevail, but the virtual threat of such an action does keep government from getting too far outside of its democratic mandate.
Likewise, the freedom to fork a free software project is also a "tool of revolution" intended to safeguard the real freedoms in free software. Every once in awhile someone comes along who tries to abuse the illusory power over the community, and a little revolution has to occur (fortunately, in the case of software, this is almost always a bloodless revolution!). As such, it's a precious right that we should not give up.
This work may be distributed under the terms of the Creative Commons Attribution-ShareAlike License, version 3.0, with attribution to "Terry Hancock, first published in Free Software Magazine".