On forking and contributor agreements

On forking and contributor agreements

Summary: Paula Rooney has written an excellent article on a dispute in the Open Office developer community that could possibly lead to a fork of the free office suite. A fork occurs when someone puts out their own version of a piece of software that is separate from the "mainline" or "generally accepted as official" version.

SHARE:

On forking and contributor agreementsPaula Rooney has written an excellent article on a dispute in the Open Office developer community that could possibly lead to a fork of the free office suite. A fork occurs when someone puts out their own version of a piece of software that is separate from the "mainline" or "generally accepted as official" version. The dividing issue in the case of Open Office is the contributor agreement that Sun requires all developers to sign before any code they create can become a part of the project. Somebody didn't want to sign it, and the disagreement escalated to the point that a fork is being considered.

Forks, and threats of forks, are natural parts of the open source paradigm. Since, by definition, anyone can get the source code and redistribute their own version of the code, one might wonder why forks don't happen more often. One big reason is that the free/open source model requires a community to function well. "It takes a village," is nowhere more true than open source. And, communities don't just spring up overnight. They gradually build and gather momentum and strength over time.

For this and other reasons, forks generally don't happen unless the participants are highly motivated. Maybe they don't like the way the project is heading, or maybe they think they can do a better job writing the code or setting the priorities of the project (project governance, licensing, etc.). Sometimes forks go nowhere, sometimes the two versions get merged back together later, and occasionally the forked version becomes the de-facto "official" version while the original withers away. Natural selection weeds out the winners from the losers in the competition for developer mindshare and end users. It's messy and inefficient, but to paraphrase Winston Churchill, "it may be the worst system except all the other systems that have been tried from time to time".

As I've mentioned before, contributor agreements give the project stewards considerable leeway in deciding on which license to use when they distribute the software. Without a central copyright holder (or co-holder) it's very difficult to change the license, for example to move from LGPLv2 to LGPLv3.

On the other hand, a central authority has what some might consider to be an unfair advantage under some licenses such as GPL. They can make proprietary versions (like Star Office), but others cannot. Thus they're in a unique position to satisfy the desire of many customers (esp. the ones with deep pockets) that prefer the perceived safety of proprietary licenses and don't mind paying for it.

Non-proprietary developers might find this hard to understand, but having worked on both sides of the fence I've seen it in action. Take my next-door neighbor for example. He's a VP at a major pharmaceutical company, and we've had many conversations about open source over the years. His company is very reluctant to use free and open source because of stringent validation requirements that their tools have to pass. But if you were to wrap up that same code in a proprietary solution, validate it, stand behind it, support it, and charge big bucks for it (sometimes millions), they wouldn't blink an eye.

When an extremely non-permissive copy-left license like GPL or, to a lesser extent, LGPL, is involved, contributor agreements are almost necessary to play in this space. Sure, there are exceptions (*cough* Linux *cough*) but this hybrid model seems to me to be a nice bridge between the pure-proprietary mode these big software vendors have operated under in the past and the purely free and open modes of the utopian future. Especially if you're lucky enough to be the holder of that copyright and the steward of that project.

If you're not so lucky and you find yourself a competitor to the steward (for example Novell or IBM vs. Sun) you have a harder decision to make. Do you go to all the trouble of making your own version of the software, either a fork or a complete rewrite (ala Harmony) just to wrest control from the current steward? You better have a darned good reason, and be willing to stick with it for the long haul. Right now the dispute over one minor component of Open Office (the author didn't want to sign the contributor agreement) does not seem to rise to that level.

Topics: Collaboration, Open Source, Software

Ed Burnette

About Ed Burnette

Ed Burnette is a software industry veteran with more than 25 years of experience as a programmer, author, and speaker. He has written numerous technical articles and books, most recently "Hello, Android: Introducing Google's Mobile Development Platform" from the Pragmatic Programmers.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

1 comment
Log in or register to join the discussion
  • A brief history of wasting time.

    FireFox is an example of a successful fork. The story is indicative of both what makes for a successful fork and the underlying principles of open source.

    Once upon a time, Netscape was in severe financial difficulty, and could not afford to create a new version of its browser. So the company made a typical desperation move and released the code, hoping to obtain volunteer labor to replace paid staff.

    The project attempted to improve Netscape's code for a long time and found it could not make progress. And so the participants decided to start from the beginning.

    Netscape couldn't wait, and died. The remains were bought by AOL Time Warner, as it was, probably with the expectation of regaining the company's money by suing Microsoft. The eventual settlement was $900 million.

    The effort to write a new browser continued, lengthily. AOL Timne Warner made an arrangement to obtain and adapt the product, reminiscent of Sun and OpenOffice, gave the project some money and resources, wished it luck, and turned it loose.

    The project began to run out of resources and withered. But then Nokia returned the project to its roots by offering a contribution if it would produce a small browser that would allow Nokia to reduce payments to Opera and to its own staff.

    A browser was finally produced, but it was bloated. FireFox was a fork intended to remove all the connections to other software functionality, to take on IE only, rather than all of Office. The fork soon proved so popular that it was able to eliminate Opera's chances of holding a significant share of the overall browser market.

    FireFox may not have had a benign effect on employment in the software industry, and the hopes of both Netscape and Time Warner have long been extinguished, but FireFox does exist as the foremost example of the project's efforts.

    So concludes the tale of an exemplary fork.
    Anton Philidor