Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

Chapter 4. The Magic Cauldron > Why Sale Value is Problematic

4.8. Why Sale Value is Problematic

Open source makes it rather difficult to capture direct sale value from software. The difficulty is not technical; source code is no more nor less easily copied than binaries, and the enforcement of copyright and license laws permitting capture of sale value would not by necessity be any more difficult for open-source products than it is for closed.

The difficulty lies rather with the nature of the social contract that supports open-source development. For three mutually reinforcing reasons, the major open-source licenses prohibit most of the sort of restrictions on use, redistribution and modification that would facilitate direct-sale revenue capture. To understand these reasons, we must examine the social context within which the licenses evolved; the Internet hacker (http://www.tuxedo.org/~esr/faqs/hacker-howto.html) culture.

Despite myths about the hacker culture still too widely believed outside it, none of these reasons has to do with hostility to the market. While a minority of hackers does indeed remain hostile to the profit motive, the general willingness of the community to cooperate with for-profit Linux packagers like Red Hat, SuSE, and Caldera demonstrates that most hackers will happily work with the corporate world when it serves their ends. The real reasons hackers frown on direct-revenue-capture licenses are more subtle and interesting.

One reason has to do with symmetry. While most open-source developers do not intrinsically object to others profiting from their gifts, most also demand that no party (with the possible exception of the originator of a piece of code) be in a privileged position to extract profits. J. Random Hacker is willing for Fubarco to profit by selling his software or patches, but only so long as JRH himself could also potentially do so.

Another has to do with unintended consequences. Hackers have observed that licenses that include restrictions on and fees for commercial use or sale (the most common form of attempt to recapture direct sale value, and not at first blush an unreasonable one) have serious chilling effects. A specific one is to cast a legal shadow on activities like redistribution in inexpensive CD-ROM anthologies, which we would ideally like to encourage. More generally, restrictions on use/sale/modification/distribution (and other complications in licensing) exact an overhead for conformance tracking and (as the number of packages people deal with rises) a combinatorial explosion of perceived uncertainty and potential legal risk. This outcome is considered harmful, and there is therefore strong social pressure to keep licenses simple and free of restrictions.

The final and most critical reason has to do with preserving the peer-review, gift-culture dynamic described in Chapter 3. License restrictions designed to protect intellectual property or capture direct sale value often have the effect of making it legally impossible to fork the project. This is the case, for example, with Sun's so-called "Community Source" licenses for Jini and Java. While forking is frowned upon and considered a last resort (for reasons discussed at length in Chapter 3), it's considered critically important that that last resort be present in case of maintainer incompetence or defection (e.g., to a more closed license).Section C.4.1.4

The hacker community has some give on the symmetry reason; thus, it tolerates licenses like the Netscape Public License (NPL) that give some profit privileges to the originators of the code (specifically in the NPL case, the exclusive right to use the open-source Mozilla code in derivative products including closed source). It has less give on the unintended-consequences reason, and none at all on preserving the option to fork (which is why Sun's Java and Jini Sun Community Source License schemes have been largely rejected by the community).

(It bears repeating here that nobody in the hacker community wants projects to split into competing development lines; indeed (as I observed in Chapter 3) there is very strong social pressure against forking, for good reasons. Nobody wants to be on a picket line, in court, or in a firefight either. But the right to fork is like the right to strike, the right to sue, or the right to bear arms—you don't want to have to exercise any of these rights, but it's a signal of serious danger when anyone tries to take them away.)

These reasons explain the clauses of the Open Source Definition, which was written to express the consensus of the hacker community regarding the critical features of the standard licenses (the GPL, the BSD license, the MIT License, and the Artistic License). These clauses have the effect (though not the intention) of making direct sale value very hard to capture.

  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint