Community Rights and Community Wrongs

 Have you discovered The Alexandria Project?

 
Wikibook Header, public domain, courtesy of WikiCommons at http://commons.wikimedia.org/wiki/File:Copyright_%28Simple_English%29_Wikibook_header.pngAlthough the continuing debate over the future of Java and OpenOffice should not surprise, the fact that developers have allowed themselves to be caught in this position to begin with should. The reason?   The community has overestimated the power of software licenses – even FOSS licenses – to protect their rights, and opted not to take advantage of other tools that could.
 
Yes, today’s restrictive licenses embody powerful rights, but those rights are no stronger than the ability of their owners to assert them. Placing all one’s defensive reliance on a single legal tool can make no more sense than relying on a single weapons system.  Why?  Because it’s all too easy to be outflanked by an enemy with a more diverse armament.  And ever since Oracle's acquisition of Sun, the traditional defenses of open source developers have been about as effective as France's post-World War I Maginot Line.
 

As recent events have demonstrated, the powers of developers are limited when compared to the power of a Fortune 500 company, like Oracle, if that company does not care whether independent developers continue to support the projects that it acquired. What developers are now realizing is that the license-based action options of large and diverse pools of code contributors are difficult to pursue, and not necessarily very attractive.

This realization was summed up well a few days ago in a comment posted by Bob Lee to a blog post at Stephen Coleburne’s Weblog relating to nominations to the Java Community Process (JCP) Executive Committee, which controls what can and cannot become part of future releases of Java. While the JCP hosts an open process, the Executive Committee must approve changes to the definition of Java and new features added to it, and Oracle has the right to control three out of the five Executive Committee seats.   Bob wrote in part:
 
They closed Java and prohibited independent implementations. They had their cake and ate it, too. Java wouldn’t be as successful as it is today if it weren’t an open standard. I certainly wouldn’t have contributed. Now, I’m in this awkward position where I have too much invested to just leave. I have to sit around and hope Oracle does the right thing. I blame myself.
 
For purposes of my argument (and Bob’s), it’s beside the point whether Oracle’s actual nominees to the JCP Executive Committee will be sincere and independent, unconsciously affected by commercial self interest, or overtly operating at Oracle’s beck and call. The central point is that Oracle has the right to choose among those alternatives, either now or in the future.
 
Today, developers have only two defenses: to fork a project, or, if a corporation controlling a project oversteps its bounds, asserting their legal rights under the license under which the developers made their code contributions.
 
But forking a project entails effort, uncertainty, delay and risk (as contributors to OpenOffice.org are now experiencing). And if a FOSS license has been violated, where are the resources to come from to assert a developer’s rights? True, there are several non-profits willing to assert those rights. But a company like Oracle has the resources to outspend them all in court, absent public or behind the scenes contributions from other major corporations.
 
At the end of the day, the only sensible defense for developers against abandonment or subversion of a project is not to become vulnerable to those risks to begin with.  The irony is that the means to do so are readily available, and it’s time that developers started taking advantage of them.
 
I outlined those means a few weeks ago, when a group of OpenOffice developers split off to form the Open Document Foundation. The core lesson is that open source developers, like open standard developers, should insist that a corporate sponsor set up an independent legal entity to host a project (or find an existing, independent foundation to host the project) if they want community members to contribute their time and their code. That entity should be governed by a Board of Directors or other body that is not controlled by the corporate sponsor (see my critiques and recommendations here on how not to set up such an organization).
 
An independent project host should not only own the right to control the future direction of the project code, but also the trademark in the name of that code. That way, if the sponsor decides to exercise its right to fork the project code, it must do so under a different name. Richard Stallman realized the power of ownership decades ago, when he formed the Free Software Foundation to own the copyright and the trademark in GNU software, providing a single control point to assert the rights of all code contributors in the event that the terms of the GPL under which it was licensed were violated.
 
Securing these defenses is simple, cheap and quick to accomplish. My suggestion to the community is to insist that corporate sponsors either set up a project as an independent legal entity, or launch a new project (with its own governing board) under the legal wing of an existing independent entity, before they agree to participate. Otherwise, community rights holders will continue to be vulnerable to wrongs they never anticipated, and that could have been easily avoided.