Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Softpanorama University Library

BSD vs. GPL:
A Framework for the Social Analysis

by Dr Nikolai Bezroukov

Chapter 1: Social Roots, Complexity and Never Ending Process of  Interpretation  of  GPL

Dr. Nikolai Bezroukov

this document is a chapter of the ebook
( the current version of the chapter is 0.97; if quoted please mention the version in your reference)

Copyright 1998-2004, Nikolai Bezroukov. This is a copyrighted unpublished work. All rights reserved.

Fair use:

Anyone is free to establish a link to the chapter using URL http://www.softpanorama.org/Copyright/License_classification/social_roots_of_GPL.shtml (but mirroring is explicitly prohibited, since that could lead to an undesirable proliferation of obsolete versions).

Disclaimers:

1. The statements, views and opinions presented in this chapter and the book as a whole are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with.
    

2. We do not warrant the correctness of the information provided or its fitness for any purpose.
    

3. In the current shape this chapter and the book as a whole might benefit from a better English. Readers with strong allergy to spelling and grammar errors are advised to avoid reading of this draft.

Contents

Abstract

Introduction

1.1. Free/Open Software Development and the Concept of "Programming Intelligentsia"

1.2. Anarchism, Stallmanism and "the Hacker Mentality"

1.3. GPL and Academic Ethics

1.3.1 Software License as a Social Contract

1.3.2. GPL and the Acknowledgement of  the Work of Others

1.3.3. Contradictory Interests of  Various Users Sub-groups as the Source of Internal Conflicts in Free/Open Software Licenses

1.4. Life Cycle of Software and the Dynamic of  License Requirements

1.5. Social Importance of the Level of Complexity of the License

1.6. GPL Interpretation as an Important Social Process

1.6.1. Twelve candidates for the inclusion into GPL FAQ

1.6.2. Fuzziness as an important social property of GPL

1.7. GPL and open standards

Acknowledgements

Summary

Abstract

In this chapter we will try to understand the social base of each license and their underlying philosophies, as well as introduce the concept of the metric for license complexity and discuss the role of the process of the interpretation of GPL as an important social process in free/open developers community.  We will view both licenses not as binding legal documents, but more like  "social contracts" that presuppose certain political philosophies behind them and attract people that belong to a certain social stratum. That brings us to the concept of programming intelligentsia from which we will start our exploration of this topic.

Introduction

This is the first chapter of this e-book. In this chapter we will attempt to establish a framework for the social analysis that might help to clarify issues for developers of free/open source products as well as the relative merits of each license.  This chapter is written from the software developer's point of view, not that of a lawyer. I would argue that such an approach makes sense because none of major open/free software licenses was ever tested in court.  And as such they can be viewed as a social contract, a mechanism for attracting users and co-developers and ensuring cooperation.

The chapter consists of  three semi-independent parts, and in each we will concentrate on a specific issue connected with the social properties of the BSD license (BSDL[BSD1979]) vs. similar properties of GPL[FSF1991].

BSD license was initially created in 1979 for the distribution of BSD system, the first free/open version of Unix in existence. It was created by the University of California at Berkley:  the home of BSD UNIX. The major points of the BSD license[BSD1979]:

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following acknowledgement:

   This product includes software developed by the University of California, Berkeley and its contributors.

4. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

Like BSD, GPL was created for a specific project -- so called GNU project: an attempt to create a free version of the Unix programming environment. GNU project and an umbrella organization called Free Software Foundation (FSF) were created by Richard Stallman ( RMS) in early 80th. The first important result of the project was free C compiler (gcc) with more or less stable release (1.17) released in January 9, 1988.

The creation of GPL was partially result of RMS' reaction to the inability to preserve Gosling Emacs code in GNU Emacs. In 1982 James Gosling (the creator of NeWs and the Java)  rewrote Emacs in C and created the first Unix version of the editor, considerably improving and expanding the functionality of the original Stallman's Emacs (the original 1975 version was written in TECO and did not use Lisp; contrary to the folklore the usage of Lisp as a macro language for Emacs was not Stallman's idea).

Initially Gosling Emacs was freely redistributable, but later Gosling sold rights to UniPress, and Gosling's Emacs became proprietary UniPress Emacs.  Stallman used Gosling Emacs in early 1985 as an initial codebase for the first version (15.34) version of GNU Emacs.  After Gosling Emacs was sold, Stallman was forced to re-implement parts of Gosling Emacs code, that actually gave him a chance to improve the quality of the product (at this point he implemented a complete Lisp interpreter borrowing an earlier idea of Bernie Greenberg, who was the first to use Lisp in Emacs[Zawinski1999]).

This experience served as a stimulus to create the GPL. GPL went though a couple of minor versions (the initial version was "package oriented", see Emacs General Public License, then it was generalized to be used with any package, see GPL 1.0). Version 2.0 which is commonly used today was published in June 1991. In all subsequent discussion when we talk about GPL without explicitly mentioning the version, we will mean version 2.0.  It is interesting to note that in 1991 when Linus Torvalds adopted GPL as a tool for the commercialization of the Linux kernel, GPL was pretty new and untested license. In a sense Linux was the major test of GPL 2.0.  

The major points of v.2.0 of the GPL include:

1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.

You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

• a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
• b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
• c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

The important thing to understand is that GPL interaction with the actual dynamic of  free software development is definitely more complex, and produces more unanticipated effects, especially in the later stages of program development, than one can guess from reading www.gnu.org. And free/open source development is more than just a set of  specific clauses in a license agreement. I will try to show the complexity of the GPL influence on the  legal, economic, and intellectual property landscape for software developed. Due to the nature of the topic, materials presented below contain a large number of carefully selected quotes that illustrate the attitudes of developers, and the subtle aspects of those licenses as well as their interaction with other licenses.

Despite the fact that both BSD and GPL licenses were formulated more then ten years ago, the view and interpretation of those licenses by the community of free/open software developers is still a highly dynamic process[Wikipedia] (See especially discussion about the article).  In a nutshell each major open source figure has its own interpretation of  GPL. In a sense the interpretation by GPL for, say, RMS and Linus Torvalds are pretty far apart and the rift changes with time: some years it's wider some years its more narrow.

Historic dynamics of GPL interpretation is pretty staggering: you simply cannot compare the views on GPL that were held in the early 90's with views that are currently held. The current picture is so much more complex and nuanced as if this is a new license. Also some initial aura of  "freedom loving" license  started dissipate after Linux's IPO gold rush in 1998-2000 and subsequent bust (with the associated financial scandals).

It's important to understand that each open/free license behaves differently, often unpredictably for everybody including their creators, and each provides a different set of advantages and drawbacks, depending of the stage of the lifecycle of the software project. This advocated in the chapter dynamic view logically leads to the idea that a free/open software product might benefit from adjustment or changing licenses as the project progresses through  the various stages of development.

1.1 Free/Open Software Development and the Concept of "Programming Intelligentsia"

At the beginning of the development of computer science all programs were considered free. This stage generally lasted until the late 60's and gave rise to the next stage in which dialectally opposite view prevail: commercial software development became a dominant force. As a reaction to this domination of commercial software, free software development that previously was mainly a form of research, a land of new science frontiers,  acquired a new form, the form of a social movement, which can be called a  "politically or socially motivated programming development". Now we are probably at the very beginning of the next stage, in which both forms of software will coexist on a new qualitative and quantitative level.  For the last three years this phenomenon has drawn great attention from mass media.

This rise of  "politically or socially motivated programming development" can be ascribed to a complex mosaic of political, social and economic factors, but it's clear that among economic factors probably the personal computer revolution and the Internet revolution were major factors that drove this movement into the mainstream. Two terms with slightly different meanings are often used to describe the movement: "free programming" and "open source". Both of them refer to the fact that a considerable number of  software developers became increasingly concerned with the social aspects of the software development and as a result started to develop software free of charge with source code freely available. Because, as we will see later, each of those terms is now associated with a specific ideological platform, we will use a neutral term free/open software development as an umbrella term.

The question about major social driving forces is too complex a question to answer in this chapter, but I think that the re-emergence free software development in a new form of free/open software movement is not only connected with negative factors like the complete domination of commercial software, but also with a certain level of maturity of programming as both a new type of social activity and a  profession.  I think that the fact that programming became a mass specialty raised the level of self-awareness of programmers and some internal self-organizing forces were activated by the achievement of critical mass of programmers. The latter led to the emergence of a special subgroup that we will call "politically or socially motivated programmer/developers" as opposed to the majority of purely "economically motivated developers."

While this may look like a return to the original roots (first programmers were mainly academic researchers and most software was free), these new developments occurred in a completely different technological base, and took the form of the Unix Renaissance.  Selected software developers, who can be classified as "politically or socially motivated", definitely existed among programmers all the time, especially in universities, but now with the emergence of the Internet and cheap immensely powerful PCs they have become a global force, the force self-organized around a Unix platform.

All-in-all this new social movement tends to oppose excessive commercialization of software development. Some go further than that and advocate restoring the "hacker culture" of  programming that supposedly existed at some previous stage, glorified in a utopian fashion as the "good old days of programming".  The latter subgroup also criticizes commercial programming as a deviation  from the "pure path" and is especially critical of Microsoft. Even further, they contend that Microsoft's domination laid the basis of programming development decay.

In Eastern Europe, and particularly in Russia, the term "intelligentsia" is usually interpreted as designating a certain community of people who are, for the most part, well-educated, are engaged in intellectual work, and instinctively follow a certain moral and ethical code.  Traditionally the intelligentsia place themselves in opposition to the powers that be and along with positive features mentioned above, shares some negative traits such as excessive love of  time-consuming discussions with low signal-to-noise ratio (this can be applied to Slashdot, Advogato, kuro5hin.org Technology and other free/open source media outlets),  the tendency to start a project and leave it unfinished (much like so many projects on www.freshmeat.org ), to substitute hard and exhausting work on implementation of the idea with fruitless but heated discussions ( remember famous Linus Torvalds quote "show me the code" -- this quote implicitly presuppose "programming intelligent" on the other end), etc. The interpretations of the term "intelligentsia" offered by popular English language dictionaries varies: 

• American Heritage Dictionary: "The intellectual elite of a society."
• The Longman Dictionary: “The people in society who are highly educated and often concern themselves with ideas and new developments, especially in art or politics.”
• The Oxford English Dictionary: “...The class of society regarded as possessing culture and political initiative.”
• Webster: “Intellectuals who form an artistic, social or political vanguard or elite.”

The Longman definition notes an important property: the intelligentsia are concerned with new ideas and new developments that often take shape through adopting a certain "opposition" ideology.  I think that the open source programming movement signified the creation of  a "programming intelligentsia" i.e. a social stratum of people who consider programming to be a culturally meaningful activity and were ready to advance their own (political/ideological) agenda in this area.

Whereas the concept of  a  “programming intelligentsia”, used as a description of a distinct social stratum with measurable characteristics, is somewhat problematic, the term “programming intelligentsia” can be a useful concept that encompasses the following: 

• Important aspects of  professional programmers social vision: attitudes, mentalités, cultural norms, and preferred media outlets (like Slashdot, Linux Today, etc)
• A set of technical beliefs about proper operating system design (and proper operating systems), dominant development languages, as well as proper ways to develop and license software.

Still, to me, the main aspect is a property that is hard to pinpoint, some indefinable academic aura connected with the term  "intelligentsia" and as I argued before [Bezroukov1999a ] the connection to the academic world probably can  better explain the whole free/open programming phenomena.  

I think that most developers who can be classified as "programming intelligentsia" share at least one of  two basic philosophies, even though their expression and means of applying those ideas to reality show many differences. These basic philosophies are intrinsically connected with two major "free/open software" licenses: BSDL and GPL. 

Thus there are two slightly different social forces behind the impressive achievements of  "programming intelligentsia" as exemplified by such projects as Apache, Bind, FreeBSD/NetBSD/OpenBSD, GCC, Gnome, KDE, Linux, Perl, PostgreSQL, Python, Samba, Sendmail, TCL  and TeX:

• The first was a heterogeneous group of  high-caliber professional programmers and academic researchers which already have impressive achievement and enjoy high social and professional status. The classic example of someone belonging to this group is Donald Knuth: the author of the world famous TeX. Academics like Donald Knuth can be dissatisfied with the quality of commercial offerings and try to offer a new, better way to solve the problem they face both for themselves and other people. Talented programmers working in the industry can often be dissatisfied with the corporate environment. For them  a contribution to an open source project can be a way to supersede the PHB-imposed limitations of a Dilbertesque atmosphere in some large corporations via the channeling of  the part of their creative energy, suppressed in the corporate domain, into a free software domain. This group generally favors the BSD license, shares the "academic solidarity" attitude, and usually believes that programmers should work together and take pride in the classic Unix heritage. At the same time the group is not limited to BSD licensing, for example this attitude is also largely shared Linux kernel developers, who use GPL license.  Linus Torvalds, a highly visible member of the latter group, expressed it this way: [Tolvalds2002a]

  Quite frankly, I don't _want_ people using Linux for ideological reasons. I think ideology sucks. This world would be a much better place if people had less ideology, and a whole lot more "I do this because it's FUN and because others might find it useful, not because I got religion".

  For many members of this social group the Unix heritage is culturally equivalent to the importance of  the culture of ancient Rome in art and architecture (classicism). As we know classicism remained very influential throughout the XIX century into the early XX century largely through the influence of universities.  Members of this group don't necessarily oppose alliances with commercial developers, nor do they necessarily favor the creation of  a separate "free" programming environment that excludes commercial software.   
   

• The second, even more heterogeneous group consists of entry-level academic researchers, entry and mid-range corporate developers, including students and amateur programmers with a considerable number of members, who still cannot find their place in the existing professional programming infrastructure,  need to prove themselves and are working in fringe jobs or living on some kind of  public support. Various subgroups of this group, sometimes hostile to each other, are held together mainly  by dissatisfaction with the status quo and the political demands for radical change in the current "overcommercialized" or "Microsoft-dominated" world of software development (along the lines of ABM - "anything but Microsoft" mentality that was discussed in [Bezroukov1999a]).  There are two important subgroups in this group:
  • Software Anarchists. This is one of the most visible, and most vocal radical subgroup associated with the GNU project (see below). Politically most of members of this group share an "oppressed minority" identity and generally believe that software ownership is oppressive and should be abolished; most of them are inclined to "software isolationism" and believe that that "free programmers" should have as little as possible to do with commercial programmers and even with the BSD community. They extol the virtues of "software freedom", which they understand not as "freedom for" but mainly as "freedom from".  The ideological platform of this part of the movement is called Stallmanism (the term was introduced by Eugene Kim, the president of Harvard Computer Society, in 1984[Kim1984]). See for example [Toderash2002]:

    Almost every discussion of RMS ends up being a contrast between him and Eric Raymond. I've been known to use the term "stallmanism" in the past, and sometimes just in contrast to the word "raymondism".

  • Software Libertarians. This is another important part of the movement, that is more profit oriented and generally associated with the term "open source", although the latter also is often used as an umbrella term (we use the term free/open software development instead). The philosophical foundation of this part of the movement is called Raymondism and was laid out  by Eric Raymond in his famous paper "The Cathedral and the Bazaar" (CatB)[Raymond1998a]. They also want to displace commercial software because they consider it to be a new and better software development paradigm[Bezroukov1999a]. Generally they share less radical views that are probably more close to the views  of BSD supporters than to views of "software anarchists". Some developers were attracted to the "software libertarians" agenda for the simple reason that they were not very successful in their current carriers and think of open source as an alternative more lucrative career path with higher financial rewards.
    
    For them "open source" agenda provides an important opportunity for an alternative career path, a way to improve their current social and, especially, financial position. In the latter case their goals were quite transparent --  those people were adamant in transforming Linux into a lucrative business via different IPOs and startups.
    
    In the last several years of the XX century the second group also gave a rise to a wave of  "Linux-profiteers", which from 1998 till 2001 dominated "open source" politics and contributed to the emergence of what is now called the "Linux IPO bubble" that was an important part of the Internet or dot-com bubble and the corresponding "Linux cash crowd" of newly minted millionaires. 

  Although formally "software anarchists" pledge to work with "software libertarians" (as Stallman put it "[w]e disagree on the basic principles, but agree more or less on the practical recommendations. So we can and do work together on many specific projects. We don't think of the Open Source movement as the enemy."[Stallman2001b]) substantial frictions do exist.

The creation of an  environment, that is completely free from commercial software, never was the central goal for projects like the FreeBSD/NetBSD/OpenBSD or Apache. Developers that participated in those projects just wanted an environment that better suited their goals and this happened to be a free software environment.

Still both supporters of BSDL and GPL belong to the same general socio-cultural strata that I defined as "programming intelligentsia" and have a lot in common. As we will see later that means that developers need not to be completely bound to a single license: they can choose one license in one project or in certain phases of the development of the project, and the then switch to another license or adopt a second license (dual licensing) as conditions change. There were several examples of such switches in the area  of scripting languages, which is the most innovative part of  the free/open software movement.

I think that the differences in political agendas of  subgroups constituting the "programming intelligentsia"  stratum objectively led to the variety of licenses adopted with BSDL and GPL as the major two. At the same time I would like to avoid a trap of calling one license bad and the other good and trying to prove this point with examples. The situation is more complex: both licenses have their strong and weak points and I will try to examine them "sine ira et studio." 

This is very important as Linux success demonstrated quite convincingly that media plays a crucial role in projecting images in technology[Priestley1999, Baoill2000].  What appears in media -- both print or Web-based -- is widely accepted by people as true. In his paper  "Honest News in the Slashdot Decade" Matthew Priestley aptly wrote [Priestley1999] (here and everywhere below bold italics are mine -- NNB):

That trust decisions are subject to predation should be apparent. The most evident form of bias is opinion pollution, in which the subjective feelings of a reporter taint the news. Such bias may [be] either systemic, or it may be the fault of "rogue" reporters, or both.

This form of bias, in both its conservative and liberal strains, is trivial to establish. In a July 8, 1999 article discussing a verdict against tobacco companies, the New York Times dwells on the volume of damning evidence presented by the plaintiffs. The deformities of the smokers are described, and the article drops a helpful tip about who is eligible to join the suit [4]. Covering the same event, the Wall Street Journal scrupulously avoids discussing the smokers, save to describe their organizers as 'flamboyant'. The title of the piece implies the status of the case as a class action is fraudulent, and the guilty verdict is categorized as a legal 'aberration' [5].

This form of trust violation can be characterized in two ways. If the tolerance for personal beliefs in the news is not widespread, but isolated to a few reporters, then officials of the corporation have delegated their authority unwisely. An organization that is otherwise trustworthy will eventually correct this error. If the corruption runs throughout, however, then the consumer's initial trust decision was poor. In either event, ongoing opinion pollution can only be sustained by broad organization-wide consensus on the value of certain ideas.

Opinion pollution is a trait of ideologically homogeneous groups.

Programmers are usually are too busy coding and unfortunately there are too few skeptical developers, who investigate the issue before subscribing to one license or another. The majority makes their favorite media outlets a decisive  opinion-making force ("a god") and usually adopt the licensing scheme that is supported by their favorite media outlet or that was adopted by the environment they are developing their program. For example, most Perl developers adopt dual licensing scheme "Artistic license + GPL".  Few users of BDS develop GPL-based software. The same is true about Linux users: they usually favorably predisposed toward GPL. 

In the past free/open source sympathetic media displayed a strong GPL bias in the BSDL vs. GPL debate. Of course, as with any political movement, there are communal media outfits of particular groups, which deliberately project distorted images of opponents like some kind of  "Commissariat for Programmers Enlightenment." But even more balanced sources, I think, did not always give the BSD license its due in the context of BSD vs. GPL debate.  I

 1.2. Anarchism, Stallmanism and "the Hacker Mentality"

If we try to understand the philosophical roots of the GPL license, it's clear that it is closely connected with the philosophy of Anarchism.  The latter is defined by The American Heritage College Dictionary as "The theory or doctrine that all forms of government are unnecessary, oppressive, and undesirable and should be abolished."  The first definition of Anarchism by Prince Kropotkin in the eleventh edition of the Encyclopedia Britannica(1910) stated: 

...the name given to a principle of theory of life and conduct under which society is conceived without government - harmony in such a society being obtained, not by submission to law, or by obedience to any authority, but by free agreements concluded between various groups, territorial and professional, freely constituted for the sake of production and consumption, as also for the satisfaction of the infinite variety of the needs and aspirations of a civilized being, In a society developed on these lines, the voluntary associations which already now begin to cover all fields of human activity would take a still greater extension so as to substitute themselves for the state of its functions.

Along with law anarchism also tries to abolish property rights which are understood as an instrument of oppression and exploitation (as opposed to personal belongings) [Anarchism_FAQ]:

"Property, in Proudhon's words, "excommunicates" the working class. The state enforces property rights in land, workplaces and so on, meaning that the owner can bar others from using them and enforce their rules on those they do let use "their" property."

Without ever mentioning the term "intellectual property" (he consciously avoids this term in his writings) Richard Stallman subscribes to the same idea that, as Proudhon put it long ago, "property is theft." The only difference is that Stallman tries to address the same old idea of  "excommunication by owners" just in a single technological domain of computer software and in his interpretation "proprietary software is theft" [Stallman1985].  That's why Stallmanism should be considered a specific brand of Anarchism: "software anarchism".

The fundamental postulates of Stallmanism are revolving around certain "unalienable rights" for software users. If we assume that the "right" in philosophical sense is a moral principle defining and sanctioning a man's freedom of action in a social context, then the concept of rights without property is somewhat questionable platform similar to other "collectivist" social utopias which historically provided the terrifying experience of human rights abuse.

History had shown that hypertrophy of collectivist rights makes an individual too dependent upon other people, especially leaders ("cult of personality"), including leaders wrongdoing, and thus implicitly undermines the right for individuality which is a fundamental contradiction because, in essence, all rights are individual rights. This hypertrophy also objectively leads to the despotism and corruption of the leaders and George Orwell coined the underling fundamental contradiction in his immortal quote "All pigs are equal, but some are more equal than others." 

It is interesting to note that in autumn 1996, the FSF experienced a full-scale staff defection, blamed in large part on Stallman. Brian Youmans, a FSF employee hired by Peter Salus just before the resignations, recalls the scene: "At one point, Peter [Salus] was the only staff member working in the office." [Williams2002]. Further discussion of philosophical issues of interconnections between notions of  "freedom" and "property" is beyond the scope of the chapter, but we will touch another side of the problem of interaction of individual rights with the collectivist vision later in this chapter when we will discuss the interaction of GPL with the acknowledgement of  the work of others.

What make Stallmanism a unique brand of anarchism is that along with limiting Anarchism to a single domain, Stallmanism also supports the hierarchical command structures with the Free Software Foundation (FSF) assuming the central role. Richard Stallman is the founder of the FSF and keeps tight control of the organization.

GPL supporters probably will be extremely puzzled and confused if they ever see Stallman's paper about the downsizing of the role of FSF or about the decision to dissolve FSF as an organization that had achieved its goal (after all the official goal of FSF and GNU project  was to create a free Unix-like OS and Linux is pretty much it). That fact was aptly reflected in special genre of "FSF shuts down" jokes like this April 1, 2002  joke [Softpanorama2002]:

April 1, 2002 Boston, Massachusetts. After 18 years of striving, FSF finally reached its long-stated goal to create free computer environment and Monday April 1, 2002 promptly ceased operations. "We achieved all our goals," founder Richard Stallman (RMS) said. "Back when I started GNU project and FSF, I vowed that I would not rest until we create a completely free Unix-like programming environment. Well, today such an environment is here. Thank you for your support of the GNU project. Bye..."

Such an approach has some connections to the views of the famous Ukrainian anarchist Nestor Makhno who unlike most Anarchists did not oppose to hierarchical command structures, although he condemned "oppressive centralism" of Bolsheviks (as the main alternative to Bolsheviks in 1918-1920 Makhno's militia controlled the most of Eastern Ukraine). In his "Open Letter to Spanish Anarchists" [Makhno1932] wrote:

The Spanish toilers - workers, peasants and working intelligentsia - must unite and display the utmost revolutionary energy so as to conjure into existence a situation whereby the bourgeoisie may be precluded from opposing the seizure of land, factories and full freedoms: a situation that would thus become more and more widespread and irreversible.

It is crucial that no effort be spared to get the Spanish toilers to grasp this and understand that to let this make-or-break moment slip by whilst remaining inactive and making do with the mere passing of splendid resolutions which come to nothing, would be tantamount to unwittingly playing into the hands of the revolution's enemies, allowing them to seize the initiative and giving them time to recover and then to snuff out the revolution that is underway.

To that end, there is a need for a union of libertarian forces, most especially in the shape of the foundation of a great peasant union that would federate with the CNT, and within which anarchists would beaver away indefatigably.

It is also vital that the workers get help to establish, on the spot, organs of economic and social self-direction - free soviets - as well as armed detachments for the defense of the revolutionary social measures that they will inevitably be imposing once they have come to their senses and broken all the chains of their slavish condition.

The implicit slogan of Stallmanism "The intellectual property be damned, long live GPL software" logically led to attempts to impose FSF as supreme license holder to the individual software authors. For Stallmanism it actually does not matter who is working on a particular GPLed programs, if the copyright was transferred to FSF. This attitude is very similar in spirit to famous Makhno quote "The practice of acting on one's personal responsibility should be decisively condemned and rejected in the ranks of the anarchist movement".  Stallmanism vision is that software developers (replaceable and anonymous "work bees") should just relentlessly work toward the grand goal of the movement -- software freedom for all. 

Due to it's domain-based limitations Stallmanism is internally inconsistent because it does not object to the existence of a private enterprise per se, but only proprietary software, as if  two things are not intrinsically connected. It's interesting to note that in response to Jim Allchin (a senior vice president at Microsoft) critique of GPL, Stallman had chosen to mention "free enterprise" along with "free speech" and "free software" [Stallman2001a]:

"The Free Software Movement was founded in 1984, but its inspiration comes from the ideals of 1776: freedom, community, and voluntary cooperation. This is what leads to free enterprise, to free speech, and to free software."

As we will see below this breakup with traditional Anarchist doctrine forces Stallmanism to invent ways of saying the same things that Anarchism used to say, but carefully avoiding any direct resemblance in terminology and inventing is own terminology (GNU-speak), like in the following example:

Extracting money from users of a program by restricting their use of it is destructive because the restrictions reduce the amount and the ways that the program can be used. This reduces the amount of wealth that humanity derives from the program.

Assuming that private enterprise is OK, but proprietary software development (which is a natural result of the existence of private enterprise) is not, puts Stallmanism on a rather shaky theoretical foundation, and creates the problem of  "where software anarchism actually stops." This problem is a fundamental internal contradiction of the GPL license that creates constant frictions inside the "GPL camp".  In this sense GPL is a license that suffers from the impossibility of the enforcement of Anarchism in the artificially isolated domain of computer software, the idea that is considered  "a principle and purpose" of the license [Stallman1999a] ):

In the GNU Project, discrimination against proprietary software is not just a policy--it's the principle and the purpose. Proprietary software is fundamentally unjust and wrong, so when we have the opportunity to place it at a disadvantage, that is a good thing.
 
The GNU Project policy, in GNOME as in the rest of the GNU Project, is to release libraries under the GPL, except when there's a special benefit *to our goal* from doing otherwise for some particular library.

Stallmanism ignores that fact that self-containment of software is relative and, as a social activity, software development interacts with the larger society in multiple ways. That means that a temptation to extent this approach beyond "software borders" is an intrinsic property of the movement.

An example of such an extension to the compensation area can be easily found on the FSF's Web site: "If we take away the possibility of great wealth, then after a while, when the people have readjusted their attitudes, they will once again be eager to work in the field for the joy of accomplishment." To avoid this temptation and the necessity of addressing complex social issues that inevitably arise, the "GPL camp" is predisposed to isolationist tendencies.

Therefore it's unsurprising that despite his support of "free enterprise" Stallman often attacks private software companies that made significant contributions to the pool of GPLed software, especially if they try to protect the interests of shareholders, for example by making source available for a fee, using trademarks to prevent free copying or by the introduction of  per-seat licensing  [Stallman2002b]:

Of cause in best traditions of Anarchism, in the absence of laws the final judgment of what constitute a socially acceptable behavior and what is not is bestowed on the Great Fearless Leader. Here is a typical complain of a director of  a software company that uses GPL [Gordon2002]: 

We sell one product that is GPL. On at least a weekly basis we get someone telling us that we have to give them the source code because it is GPL. Some of them become verbally violent and abusive when I point out that the GPL provides for us to charge for the source code, we just have to make it available, and this we have done. Some of these people even tried to hack our system to get the code because they thought it was their God-given right to have it. These are also typically the people who contribute nothing to the community.

I had RMS come to me on this product to make sure we weren't violating the GPL, and he admitted that we were not, but in the course of the conversation he proceeded to project onto the KDE project aspects of theKompany in a totally inappropriate fashion and was very negative about KDE in this regard. Now, to my mind there is far more corporate involvement and control over GNOME than KDE, but RMS chose to see things the way he wanted to see them in this instance and say that it was too bad the KDE didn't stand for freedom. Again, this had nothing to do with KDE, this had to do with just one of our banner products and the way we chose to implement and license it.

Here we see that, on one hand, adopting GPL license put any software company in a rather difficult position (essentially sitting between two chairs and thus very susceptible to any "negative marketing" campaign). On the other hand GPL implicit approval of "free enterprise" puts "The Supreme Interpreter of the GPL license" into tricky position when he should formally approve actions that definitely contradict the spirit of the license. But I would say that position of companies like Red Hat, which use GPL and at the same time tries to protect their market position with software patents and trademarks is even more trickier.

Like any Anarchist philosophy, GPL offers a beautiful dream of  free, unrestricted access to high quality software for all people around the globe. Therefore it's unsurprising that in his articles Richard Stallman like to talk about freedom and often tries to elevate the free availability of software to the level of basic human rights. As Bertran Meyers  pointed out in his essay, "The Ethics of Free Software", Stallman "professes an absolute refusal of any notion of commercial software" [Meyers2000]:

A few samples from the GNU and FSF web pages include:

• "Signing a typical software license agreement means betraying your neighbor: 'I promise to deprive my neighbor of this program so that I can have a copy for myself.'" (http://www.gnu.org/philosophy/shouldbefree.html.)
• "When a program has an owner, the users lose freedom to control part of their own lives." (http://www.gnu.org/philosophy/why-free.html.)
• "The system of copyright gives software programs 'owners', most of whom aim to withhold software's potential benefit from the rest of the public. They would like to be the only ones who can copy and modify the software that we use." (Same URL.)
• "I think that to try to own knowledge, to try to control whether people are allowed to use it, or to try to stop other people from sharing it, is sabotage. It is an activity that benefits the person that does it at the cost of impoverishing all of society. One person gains one dollar by destroying two dollars' worth of wealth. I think a person with a conscience wouldn't do that sort of thing except perhaps if he would otherwise die." (BYTE interview, http://www.gnu.org/gnu/byte-interview.html.)

All the quotes above can be summarized with the following quote from Proudhon's classic work What is Property  [Proudhon18xx]

"Property is the right to use and abuse . . . if goods are property, why should not the proprietors be kings, and despotic kings -- kings in proportion to their faculties bonitaires?  [p. 266]

This view of GPL as the license that promotes anarchism in software is shared by many authors including Professor of Law & Legal History in Columbia Law School and general counsel to the Free Software Foundation, Eben Moglen [Mogden1999]:

At the center of the digital revolution, with the executable bitstreams that make everything else possible, propertarian regimes not only do not make things better, they can make things radically worse. Property concepts, whatever else may be wrong with them, do not enable and have in fact retarded progress.

But what is this mysterious alternative? Free software exists, but what are its mechanisms, and how does it generalize towards a non-propertarian theory of the digital society?

... ... ...

The GPL,[24] also known as the copyleft, uses copyright, to paraphrase Toby Milsom, to counterfeit the phenomena of anarchism.

... ... ...

For the free software community, commitment to anarchist production may be a moral imperative; as Richard Stallman wrote, it's about freedom, not about price.

In this sense "a hacker mentality" is nothing more than Anarchist philosophy (often intuitively) reinvented on a new technological basis of personal computers and Internet and artificially limited to computer software. Thus, it is not accidental that the Anarchist FAQ is now a project on the Sourceforge [Anarchist_FAQ]  The relative popularity of GPL among students and young academic researchers, as well as small commercial start-ups, has strong historical parallels: the same groups historically were the stronghold of Anarchist philosophy (historically small business owners always were the main social base of Anarchism; like all small businesses, software startups are more concerned with the danger of being mercilessly robbed/"eaten alive" by a bigger fish, then about protection of their IP rights.) As we will discuss in the next chapter, GPL does provide some level of psychological security against such a threat.   

The view of the "GNU camp" ideology as a direct adaptation of the Anarchist philosophy to software, helps one better understand an ideological split between Stallmanism and the "software libertarians" ideology (Raymondism).  The ideas of the "The Cathedral and the Bazaar" (CatB) [Raymond1998a] are totally unacceptable to Stallmanism in a similar way to the Anarchists philosophers rejection of Libertarian philosophy (which is often called "anarcho-capitalism").

For example, a prominent Anarchist philosopher, Noam Chomsky, addressed the question of compatibility of Anarchism with Libertarian philosophy in his interview in Z Magazine [Chomsky1996] in the following way:

5. Many "anarcho-capitalists" claim that anarchism means the freedom to do what you want with your property and engage in free contract with others. Is capitalism in any way compatible with anarchism as you see it?

Anarcho-capitalism, in my opinion, is a doctrinal system which, if ever implemented, would lead to forms of tyranny and oppression that have few counterparts in human history. There isn't the slightest possibility that its (in my view, horrendous) ideas would be implemented, because they would quickly destroy any society that made this colossal error. The idea of "free contract" between the potentate and his starving subject is a sick joke, perhaps worth some moments in an academic seminar exploring the consequences of (in my view, absurd) ideas, but nowhere else.

I should add, however, that I find myself in substantial agreement with people who consider themselves anarcho-capitalists on a whole range of issues; and for some years, was able to write only in their journals. And I also admire their commitment to rationality -- which is rare -- though I do not think they see the consequences of the doctrines they espouse, or their profound moral failings.

Noam Chomsky is certainly not the only philosopher who believes that capitalism (private property) and Anarchism are irreconcilable and any attempts to reconcile them lead to the worst forms of tyranny and oppression (see the section F of Anarchist_FAQ for additional references and information about this topic). In fact, historically Anarchism as a political philosophy was a reaction to the horrors of early capitalism. But as a movement Anarchism itself is far from being free from "Bonapartian" tendencies of its leaders and historically Stallmanism suffered from Richard Stallman posture as a lone prophet-like figure who does not have followers, only disciples. 

This internal inconsistency of rejection of property in software domain and toleration of the same thing in all other domains, including hardware that we noted in Stallmanism, is also observed in other areas, the most notably in respect to the attitude to the state. Classic Anarchism rejects the state. So it's pretty interesting that at Fall 2001 Symposium at The George Washington University one of the themes that Stallman discussed was no more no less :  "Which public policies and laws hurt the Free Software movement? How can Free Software help government agencies, schools, businesses and society?" It's enough to say that this Stallman's desire to help "government agencies" (i.e. government) is an anathema for any conscious Anarchist: by definition Anarchism believes governments are evil and that property rights that governments enforce should be abolished.

At the same time it's clear that both  in case of "software anarchists" and "software libertarians" we need to deal with a fairly eclectic philosophical platforms. For example, the "software libertarians" platform includes elements of economic determinism (vulgar Marxism) [Bezroukov1999b]. That creates multiple problems including need for never-ending process of interpretation of licenses adopted by movements, which is especially true for GPL.

In no way Stallmanism is a unique, isolated phenomenon. The enabling role played by the Internet, when combined with user attitudes towards sharing, contributed to the growth in popularity of anarchistic ideas, not only in software, but in other areas, for example in music[Fox2002 ]

In short, an attitudinal change has accompanied the growth of the Internet, namely the belief that information should be free (Sylva, 2000). This is part of a zeitgeist that leads to a denial of ethical issues surrounding obtaining music and other services online without paying. As early as 1996 - in the days before Napster and MP3 - Adam Segal observed that "[c]yberspace has bred an entitlement philosophy in Internet users. The prevailing dogma is that anything available over the Internet - text, graphics, music, software, etc. - is free, or at least should be" [9]. More recently, Mia Garlick has suggested that:

"... [the] [g]rowth of the Internet has also seen the rise of a hacker mentality and an entitlement philosophy. The majority of Internet users expect information and particularly music to be free. They also feel entitled to access such information or music regardless of any technological protection measures. This is partly reflected in the share and swap practices made possible by Napster and the popularity of MP3" [10].

In short, the culture of the Internet in general, and of music lovers in particular, contributes to an ethos that encourages universal access to music. Thomas Dolby Robertson opines that music is "essentially a tribal, participatory medium. Fans love to mingle and immerse themselves in music" (Robertson, 2001). Likewise Frith (1992) proposes that one of the pleasures derived from listening to music is that it signals the identity of the listener by indicating membership to a particular social group, subculture or "tribe". Recently, industry commentators suggest that peer-to-peer file sharing is primarily a social phenomenon, that is, "an almost instinctive behavior of many Internet users" [11]. Given the belief of many individuals that information should be freely available and the passion many share for music, it is hardly surprising that the use of peer-to-peer services have become extremely popular (Lenhart and Fox, 2000; Rainie, Fox and Lenhart, 2000).

Furthermore, the very nature of downloadable music leads to different consumer perceptions as to theft. A survey by the Pew Internet & American Life Project found that 78 percent of Internet users who download music do not believe that it is stealing to save music files to their computer hard drives (Lenhart and Fox, 2000). This same survey found that 61 percent of those who download music do not care if the music they download is copyrighted. Also, a Quicktake.com survey in the U.S. found that 80 percent of online users do not consider that it unethical to either download or share free digital music files (Tom, 2000). This attitude is underscored by the following response: "I understand that it might be the same thing as going into a store and swiping a CD, but when you're on a computer and the song is right there to copy and sample, you don't see it as taking from somebody" (anonymous self-report, quoted in Carlson, 2000).

I would like to stress again that, if my analysis is correct, "a hacker mentality" (as opposed to an "academic mentality" with its idea of "pro bono" work) is neither an independent, nor an isolated phenomenon, it is just attempt (often intuitive) to apply the philosophy of Anarchism to the particular socio-technological domain. In its extreme forms, and when it is exploited by demagogues, "a hacker mentality" can turn poisonous, being in part a reversion to primitive tribe loyalties and in part an irrational ideological absolute.

As a social movement Stallmanism is very young and has no historical tradition. That means that the underling doctrine is still under the flux and subject to periodic revisions like in [Stallman1999b] that might contribute to the problems for software developers using the GPL/LGPL licenses.  Only now it is getting a limited press attention with FSF as the most prominent organizing force and Stallman as the most visible leader. Until recently the movement did not enjoy even ten percent of the level of press coverage that for example was enjoyed by hippy movement in 1970th.

The rise of anarchistic ideas in any social or technological domain can be directly attributed to the rise of internal contradictions inside this domain and from this point can be considered to be a litmus test for the presence of serious unresolved problems, not that much as their solution. Noam Chomsky correctly pointed out the important connection of the popularity of the Anarchism to the presence of serious unresolved problem in the society [Chomsky1996]:

2. Critics complain that anarchism is "formless, utopian." You counter that each stage of history has its own forms of authority and oppression which must be challenged, therefore no fixed doctrine can apply. In your opinion, what specific realization of anarchism is appropriate in this epoch?

I tend to agree that anarchism is formless and utopian, though hardly more so than the inane doctrines of neoliberalism, Marxism-Leninism, and other ideologies that have appealed to the powerful and their intellectual servants over the years, for reasons that are all too easy to explain. The reason for the general formlessness and intellectual vacuity (often disguised in big words, but that is again in the self-interest of intellectuals) is that we do not understand very much about complex systems, such as human societies; and have only intuitions of limited validity as to the ways they should be reshaped and constructed.

Anarchism, in my view, is an expression of the idea that the burden of proof is always on those who argue that authority and domination are necessary. They have to demonstrate, with powerful argument, that that conclusion is correct. If they cannot, then the institutions they defend should be considered illegitimate. How one should react to illegitimate authority depends on circumstances and conditions: there are no formulas.

In the present period, the issues arise across the board, as they commonly do: from personal relations in the family and elsewhere, to the international political/economic order. And anarchist ideas -- challenging authority and insisting that it justify itself -- are appropriate at all levels.

In this sense the level of popularity of the Anarchist ideas in a particular domain strongly correlates with the  level of internal contradictions and problems in this domain. As the "abandonware" phenomena showed pretty convincingly, copyright terms are probably way too long for commercial software, they implicitly violate "fair use" provisions as perceived by the majority of the users and instead of being a solution became part of the problem. And that provided a fertile ground for the growth of anarchistic sentiments. But the proposed  extreme solution -- completely abandoning  the author's rights -- also violates fair use provisions and in this sense we can say that extremes meet and commercial licensing is the best friend of GPL licensing. We will discuss this question below.

Some authors also pointed out that GPL can be considered an anarchistic license because it implicitly tries to undermine the underling  intellectual property laws on which copyright it based. This aspect of GPL was first noticed by Stig Hackvän, who in his paper "Reverse-Engineering the GNU Public Virus" [Hackvan1999] noted  that the most constructive view of GPL is to view it as an invitation for the creation of a better, simpler license:

...the whole history of GPL had shown that although the anti-copyright component of the GPL is perhaps somewhat misguided,  some copyright reform is clearly necessary. Viral infection through contract law invented in GPL is actually an invitation to work out a better consensus on the proper limitations of intellectual property.

It is interesting to note that in his reply to Stig Hackvän's paper [Stallman1999c] RMS avoided the addressing the issue, but at the same time felt the necessity to explain why he never uses the commonly used terms "intellectual property" and "protection" (as applied to copyrights and patents) as well as why he prefers to think about commercial software developers as a social class that  exercises  power over software users (as in other his writings, he carefully selected words and instead of using the common term "oppression", preferred to distance himself from Anarchism by using a fuzzy term "exercising power" instead):  

I find the distinction between freedom and power useful for thinking about the ethics of political issues. Freedom is when you control activities that affect you most closely; to control activities that mainly affect other people is power, power to dominate others. When software users can change and share a program, that is exercising freedom. When software developers make a program proprietary, and place restrictions on the users, that is exercising power.

... ... ...

I suggest avoiding the term intellectual property, which Stig used in his article, because:

• It takes for granted that these things should be a kind of property, which is prejudging the most important issue.
• It is too big a generalization, and is likely to tempt all nonlawyers into assuming that patents and copyrights are similar except for some details. Actually, they are almost entirely different.

It is much wiser to talk about either patents or copyrights, and never try to talk about both of them at once.

I also suggest avoiding the term protection to describe what copyrights or patents do. That is a propaganda term -- it views the situation from the point of view of the person or company that owns the monopoly, rather than the millions of others who are restricted by it. This is why publishing interests use the word so much; they know what message it conveys.

This idea of viewing GPL as "an invitation to work out a better consensus on the proper limitations of intellectual property" will be further explored in the third chapter of the book. Of course, that means that those who consider GPL to be a sacred document, should not wait for this part and are advised to stop reading the chapter at this very point.

From the other point of view it is this proximity to the Anarchism that, due to specific historical situation of the last decade of the XX century, to a large extent determined the popularity and the tremendous social influence of GPL and ensured its lasting effect on free/open software development.

To summarize our finding we can state that GPL ideological foundation is a special brand of Anarchism limited to a single domain: computer software. That means that it can be called  "Software Anarchism". As such this foundation suffers from several problems:

• Anarchism, artificially limited to the software, consciously and subconsciously tries to expand to other areas.
• In the modern environment the line between software and hardware is often fuzzy (for example, the Transmeta chip) and rejecting proprietary software without rejecting proprietary hardware means drawing an arbitrary line.
• There are moral issues connected with using money donated by "evil" proprietary software and hardware companies for the "Software Anarchism" movement and especially with the government support of GPL-based software. 

1.3. GPL and Academic Ethics

As we already mentioned above, a free/open software license can be viewed not only as a legal document but also as a social contract, a mechanism for attracting users and co-developers and ensuring cooperation. Until recently none of the licenses were challenged in a court of law. As of the time of writing of this chapter there is one unresolved legal case in which a defendant was sued for "breach of the GPL license" among other things [MySQL_AB2002], other charges are much more legally explored  and include " trademark infringement, breach of the interim agreement, and unfair and deceptive trade practices", so it's unclear whether the "breach of the GPL license" charge is material to the dispute and will be addressed by the court; many view the dispute between NuSphere and MySQL AB as a dispute over trademark rights, not the GPL.  

1.3.1  Software License as a Social Contract

In my opinion most free/open source developers do not think about these licenses in purely legal terms and never study the test of the license as such;  they are usually interpreted as some kind of social framework that a particular developer adopts. Their primary social role might be in establishing "the rules of the game" ("rules of  the free/open software development league"), a set of expectations for the author, user, and co-developers to observe. From that point of view both are closer to a social contract than to a legal document.  Most often this is done by coping somebody else approach to licensing (licensing model of the reference group) so that you can share the social framework.

And this social framework is far from being static; it's a complex and changing mosaic of interrelated issues, including the ability to use components licensed under different licenses, the fear of misappropriation of the product under development, the ability and perceived value of attracting commercial developers to the project, and so on. This framework changes with time and with the level of the complexity and maturity of the product in development.

For example if you analyze GPL-related literature belonging to the last century (1992-1999), it is quite evident that in the new XXI century views on GPL that are currently held are very different and the level of understanding of each aspect of GPL is much higher; various new aspects of the GPL have been discovered and analyzed since 1999.

Similarly when, for example, Gnome was in early beta, the attitude to GPL was quite different than after version 1.4 was released and adopted by Sun, HP and other major hardware vendors as an alternative to CDE.  Sun plans to use Gnome 2.0 as the primary desktop. And if that happens that will change the situation again.  That same happened to Linux after its kernel reached version 2.6 that has substantial enterprise appeal as well as  several other free/open products that manage to reach a certain level of maturity.

The idea of the social contract is quite old. Here is the initial part of the definition in the Internet Encyclopedia of Philosophy [IEoF2002]

Social contract theory is the view that morality is founded solely on uniform social agreements that serve the best interests of those who make the agreement. Historically social contract theory is an outgrowth of natural law theory, specifically the theories of Grotius and Pufendorf. However, we find hints at social contract reasoning in earlier works, most notably in Book 2 of Plato's dialog The Republic. Two distinct portions of that Book contain social contractarian themes, the first of which is offered by a skeptical character in the dialog named Glaucon. According to Glaucon, we all recognize that it is good for us individually to be unjust, although it is bad for us individually to suffer. We also recognize that if we do act unjustly, we will suffer injuries from other people. To avoid suffering injury, then, make contracts with each other by which we give up injustice and practice justice. To demonstrate his point about our preference to be unjust, Glaucon presents a myth about a shepherd named Gyges who finds a ring that makes him invisible when he wears it. Understanding the special advantage gained by having such a ring, Gyges uses its powers to seduce the Queen and Kill the King. Glaucon then argues that if there were two such rings, worn by a just person and an unjust person respectively, they would both commit the same kind of unjust deeds. Plato himself rejects this skeptical view about justice; however, the hero of the dialog - the character Socrates - presents a different contractarian account of the origin of justice in society. According to Socrates, societies are formed for the purpose of fulfilling our human needs. We have many needs and thus many kinds people and activities are required to fulfill all those needs. We then form partnerships by which we exchange goods and services. The mutual fulfilling of the various tasks is the basis of justice in society.

The definitive statement of social contract theory is found in Chapters 13 through 15 of Hobbes's Leviathan. Briefly, Hobbes argues that the original state of nature is a condition of constant war, which rational and self-motivated people would want to end. These people, then, will establish fundamental moral laws to preserve peace. The foundation of Hobbes's theory is the view that humans are psychologically motivated by only selfish interests. Hobbes argued that, for purely selfish reasons, the agent is better off living in a world with moral rules than one without moral rules. Without moral rules, we are subject to the whims of other people's selfish interests. Our property, our families, and even our lives are at continual risk. Selfishness alone will therefore motivate each agent to adopt a basic set of rules which will allow for a civilized community. Not surprisingly, these rules would include prohibitions against lying, stealing and killing. However, these rules will ensure safety for each agent only if the rules are enforced. As selfish creatures, each of us would plunder our neighbors' property once their guards were down. Each agent would then be at risk from his neighbor. Therefore, for selfish reasons alone, we devise a means of enforcing these rules: we create a policing agency which punishes us if we violate these rules. Like rule-utilitarianism, Hobbes's social contract theory is a three-tiered moral system. Particular acts, such as stealing my neighbor's lawn furniture, are wrong since they violate the rule against stealing. The rule against stealing, in turn, is morally binding since it is in my interests to live in a world which enforces this rule.

1.3.2. GPL and the Acknowledgement of  the Work of Others
 

Another important consideration is that neither the BSDL nor GPL exist is isolation: they implicitly interact and influence each other as they serve a common social group that we defined as the "programming intelligentsia", and I think that "academic ethics" is the most important and distinctive feature of this social group. Here are typical requirements of academic ethics [McMASTER1984]:

The primary pursuits of the university are to disseminate and to further knowledge at the highest intellectual levels, to inculcate the habits of critical thinking and judging, and to contribute to the cultural, moral, spiritual and social well-being of mankind. These noble pursuits impose special ethical responsibilities on its community of scholars.

1. Scholars practice intellectual honesty in the processes of acquiring and extending knowledge. They do this by improving scholarly competence, and by exercising and practicing critical thinking and self-discipline.
2. Scholars heed and keep an open mind to the opinion of others. They show respect for, and courtesy to others in free discussions on academic topics. They recognize the right to free inquiry and opinion.
3. Scholars acknowledge fully the work of others. They provide references to the work of others in papers, essays and the like; they declare the contributions of co-workers; they refrain from taking credit which is not earned.
4. Scholars hold in contempt dishonest practices such as falsification of the results of experiment, impersonation, cheating at assignments, tests, examinations, and the like.
5. Scholars strive to ensure that others are not put at a disadvantage in their own pursuit of knowledge. They refrain from with holding material that should rightly be available to all; they do not purloin ideas, experimental results, test papers, and the like in order to "get ahead"; they do not resort to the exploitation of others to this end.

In summary, these responsibilities are integrity in relation to oneself, to one's subject and to society.

The most interesting from the point of view of this book is the requirement B: "Scholars acknowledge fully the work of others. They provide references to the work of others in papers, essays and the like; they declare the contributions of co-workers; they refrain from taking credit which is not earned."

In his paper Free Software/Free Science [Ketly2001] Christopher M. Kelty  addressed this value of the acknowledgement of the contribution of others in science in the following way:

Robert Merton clearly understood the power of citation indexing - both as currency, and as a kind of registration of intellectual property for the purposes of establishing priority. In the preface to Eugene Garfield's 1979 book Citation Indexing, Merton says "[Citations in their moral aspect] are designed to repay intellectual debts in the only form in which this can be done: through open acknowledgment of them" [9]. He thus makes of citations the currency of repayment. But he goes even further, explaining scientific intellectual property in a manner that directly parallels the claims made for free software's success as a reputation economy:

"We can begin with one aspect of the latent social and cultural structure of science presupposed by the historically evolving systematic use of references and citations in the scientific paper and book. That aspect is the seemingly paradoxical character of property in the scientific enterprise: the circumstance that the more widely scientists make their intellectual property available to others, the more securely it becomes identified as their property. For science is public not private knowledge. Only by publishing their work can scientists make their contribution (as the telling word has it) and only when it thus becomes part of the public domain of science can they truly lay claim to it as theirs. For the claim resides only in the recognition of the source of the contribution by peers" [10].

It's easy to see that here GPL promotes quite a different approach that is dictated by its anarchistic roots with the its fundamental requirement of the abandonment of the idea of intellectual property. Absence of the culture of acknowledgements of  previous work is not accidental, but is an intrinsic property of GPL, which is connected to its philosophical foundation and which contradicts academic ethics. Please note that Stallman called BSDL acknowledgement clause "obnoxious BSD advertising clause'' which is a deliberate attempt to undermine the underling important concept of the license [FSF1998]. BSDL states that every advertisement mentioning the software must include a particular sentence:

3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors.

And it's easy to understand why this requirement was labeled Stallman as obnoxious. Thus I think that GPL is an acceptable license if and only if the author(s) consciously or intuitively stays on the grounds of academic ethics, and defies the spirit of the GPL by explicitly acknowledgement of the contribution of others in his programming product, including preserving copyright of the contributors and listing all contributors in the copyright statement for the product.

From this point of view the transferring rights to FSF is a questionable idea that probably contributed to the stagnation of several GNU utilities (bash, gawk, etc). As the development of the Linux kernel had shown, that shortcoming can be avoided within the GPL framework. The willingness of Linus Torvalds to acknowledge the contributions of each and every significant contributor and preserving copyright of contributions was a very important factor in ensuring the success of the development of the Linux kernel. 

The presence of the public acknowledgment of efforts means that there is a implicit reward for submitting quality code and ideas. It contributes to the establishing of the environment of intellectual honesty in the processes of creating and extending a valuable programming product that programmers, as a special kind of academic workers, need and should fight for.

In this sense, only old BSD license (with the acknowledgment clause) corresponds to the spirit of the Academic ethics and it's not surprising, that Richard Stallman fiercely fought against this requirement.

1.3.3. Contradictory Interests of  Various Users Sub-groups as the Source of Internal Conflicts in Free/Open Software Licenses
 

Formally each software license can be viewed as a point in the multidimensional space, with dimensions corresponding to major social groups participating in the development. In this case the value of each dimensional coordinate corresponds to the level of satisfaction of the requirements of a particular user group. Such representation can make more explicit the fact that each license is an attempt to balance the often-conflicting interests of the author(s) and the interests of other subgroups in user space. The license needs to ensure the cooperation of others as well as to help to ensure the achievement of the author's goals. We will adopt a simple classification that distinguishes between four interwoven subgroups of users: 

• (pure) users (usually do not modify source code; may propose fixing bugs, submit reports about the errors, etc);

• distributors (may repackage and distribute the product like Caldera , Red Hat, Slackware, etc for Linux kernel and  other packages that constitute a Unix-like environment call Linux system;; often they are also the contributors to the project).

• contributors (may submit patches and additional modules, plug-in etc; also may revise and modify old code).

• creators of derivative works (make use of all or part of the codebase for their own product, which they may wish to distribute under different licensing terms).

If we assume that at each stage of the development of a software project we need to balance the (potentially conflicting) requirements of each of those subgroups, then it is evident that the license itself is an exercise in the art of compromise and thus the author can simplify this task by adopting different requirements depending of the stage of the program development and the fact of the existence (or non-existence) and relative importance of particular user subgroups at different stages. 

In its most basic form, a license is simply the grant of a right to do something that would otherwise be prohibited. In the context of a free/open software license, this usually means the grant of certain rights to each of the above mentioned subgroups.  For example, a proprietary software license simply withdraws the rights of distributors, contributors and creators of derivative works and severely limits the rights of the user, including his ability to copy and use software on several machines.  That means that the free/open source license is inherently more complex, because a proprietary software license specifies only the conditions of use for the program, while a free/open software license needs to specify a much broader set of rights that should cover not only the users, but also the distributors, contributors and developers of derivative products. 

It is clear that it does not make sense to give rights that nobody is asking for, such as putting under GPL assignments submitted to the professor in a university course. Here, for example, creators of the derivative works face some problems no matter what license is adopted. In the case of really useless and/or buggy software, neither of the groups mentioned above, actually exists: for such software BSDL, GPL  and even the commercial software license are nearly equivalent. That also means that the validity of the license depends both on the external environment and the quality of the software. All things being equal, the lower the value and the quality of software, the less relevant licensing issues are. That also means that the popularity of the product affects the licensing, and that a license that was adopted when the product was relatively unknown can became a stumbling block with the growth of the user base. In such cases it might be prudent to modify the license for example by moving to dual licensing scheme. 

As the importance of the groups mentioned above varies with the life stage of the project, it might be beneficial to try to cater to the interests of  the most important group at each stage, not to the interests of everybody. That leads us to the question of what set of requirements is most important for each subgroup. Although this is a complex topic, we can anticipate that the following rights are valued by each subgroup:  

1. Principal author/co-developers:

   • Rights connected with the protection of the author's and the product's reputation, including protection from punitive damages and lawsuits.

   • Rights for the due acknowledgement of the author's original contribution in derivative works (an important requirement for the academic world, implemented for example in the BSDL with an advertising clause).

   • Rights connected with the potential commercial interests of the original author (for example protection against a change of  license by creators of derivative works, as in GPL or Plan 9 licenses).

   • Rights to be informed about and receive free of charge modifications to the original code made by creators of derivative works (may conflict with the rights of the creator of derivative works).

   • Rights to freely reuse the code and patches developed by contributors without any preconditions (may conflict with the contributor rights).

   • Rights connected with the integrity of the API adherence to standards and other issues critical for compatibility, including clauses covering compatibility tests, that must be passed before the derived product can be distributed. This is especially important in case of open standards like in the Kerberos. For example the Sun Community Source License (SCSL) stipulates that such modifications have to be sent to Sun if they are to be distributed. And it is Sun who decides if these modifications are redistributable or not. Thus forking (even experimental) is made difficult, due to clauses covering compatibility tests.
      

2. The regular users/redistributors:

   • The right to use software without payment or obligations.

   • The right to redistribute the original product with minimal restrictions or preconditions (conflicts with the author rights).

   • The rights to correct errors by the direct modification of the source without any delays connected with the feedback loop and the time necessary for the creation of official patches.

   • The right to receive free upgrades.

   • The right to access/study  the source code and/or internal documentation
      

3. The contributors:

   • Right for some just and not involving red tape as is often the case in Linux kernel mechanism of incorporation of patches, fixes and contributions. No "capricious denial" or "lost patches" problems with CVS-style access to the source tree for all trusted parties ("committers" in FreeBSD).

   • In case of changes that affect other developers, the right to open process of discussing technical merits and the right to see decision about changes in a reasonable time.

   • The right to due acknowledgement mechanism and preservation of IP rights for the contributed code.
      

4. The creator of derivative products:

   • The right to change the original license as one sees fit, for example to make it possible to combine the product with other (more restrictive) licenses.

   • The right to change API or deviate from the standard /reference implementation for creating comparative advantages

   • The right to reuse modules with contributed code in other products without fear of "contamination".

   • The right to freely choose the license for the derivative product

   • The IP rights to the written code

Even if the license is never changed, the mosaic of different levels of  importance, understanding and exercising of those rights by different groups in the different stages of the software life cycle creates the social dynamic of the license. Therefore in no case can the license be considered a static object during the software life cycle, even if the text of the license never changes. Now let's discuss what we mean under the term "Software Life Cycle"

1.4 Software Life Cycle and the Dynamics of License Requirements

Software engineers have traditionally considered any work done after the initial delivery as simply software maintenance. This approach does not suffice for our purpose. I think that the software development process includes many phases or stages somewhat similar to the life cycle of an organism.  We can think of software as being born, having youth (pre-1.0 stages), adolescence (say version 1-3 or even 1-6), a mature period, enter an old age ("legacy mainframe software" or MS DOS) and eventually dying as hardware changes makes it obsolete. The important fact is that a large software project has properties that can be generically characterized as its "age" and  a successful software has the chance to enter  "mature" and then "stagnation/decay" stages. 

One of the common characteristics of aging software is the growth of the size of the software codebase without major increases of functionality  ("fat" software, "bloatware", etc) as well as the "entropy"  or the loss of conceptual integrity of the code. The latter happens because of the chain of interdependent events that can be briefly described as follows:

More complex program and data flow graph

-> more code paths and variants of data interactions

-> less understanding during bug fixes (and more chances that fixes will be implemented by somebody other than the original developer)

-> less code coverage during testing

-> less reliable code.

We will distinguish five major stages of development of the open source product:

1. Initial development:  in most cases the author is the only developer of this stage; the product might have a small number of pilot users who may contribute some patches, but the main burden lies with the developer; a considerable part of the projects that one finds on freshmeat.org  never graduates from this stage. This stage can also be called version 0.x phase and statistics show that many free/open projects "die in infancy".
    

2. The adolescent stage: can be viewed as encompassing from the "magic" version 1.0 through a couple of major revisions, say, all versions in the range 1.0-3.0. This stage is often characterized by some level of success in terms of the rapidly growing user base and the arrival of co-developers. But as the project attracts other developers, we start to observe some difficulties with the coordination, the growth of the entropy of the code and the slowing pace of development; the codebase becomes more and more complex. The initial author still is at the helm of the development, but is becoming less and less interested/ more and more tied of the stress of participating in the "rat race". An increasing level of adoption of the product by the market might lead to the creation of supplementary products, textbooks, and so on. For a scripting language this stage usually starts after the first book about the language is published; in the OS arena here we can think about Linux kernel with Linus Torvalds still at the helm...
    

3. The maturity stage:  the product reaches the most prospective users, and the codebase achieves some level of stability with all major features already implemented.  Some polishing is under way, although technical problems connected with architecture flaws persist. The architecture development stagnates. This is the famous version "post 3.0 stage": a magic version at which many claim Microsoft products became quite usable. The notable property of this stage is that usually the initial developer no longer participates in the development, and the survival of the product depends of people other than the initial author(s). The number of developers stabilizes because becoming a new developer is quite difficult, due to the size and the complexity of the codebase. In the free/open software domain we can think about FreeBSD, XEmacs, gcc, and X Windows. Often a mature program demonstrates signs of aging: the growth of the size of the codebase without major increases of functionality ("fat") that I mentioned before. Some features are added without the consideration of possible negative architectural influences, just because "we can do it"  attitude ("bloatware"). Although some may object,  I generally think about "bloatware" as a special, "unhealthy" type of mature software not the sign of the decay: the creation of bloatware requires a high level of available resources. Still the "bloatware" stage can be considered an indication that the decay phase might be near (actually this stage can be achieved even with the original developer at the helm; change of the guard helps but is not strictly necessary).  Competitive products may emerge and command growing media attention because of the "new kid on the block" effect.  For example in 2004  most journalists have difficulty writing something very exciting about such mature products as Microsoft Office or Windows; most people have used them for a decade now. So it makes more sense to write about the challengers. 
    

4. Stagnation/decay stage: the level of interest in the product fades, and the product is now unable to attract new developers. The development base started to shrink (this can happen not only after the maturity phase but on any stage from initial development or the adolescent phases; often this is connected with the impossibility of substituting the original author, who has lost interest in the project.)
   
   At this stage the product development slows, often the codebase becomes too baroque to attract co-developers; eventually development may slow to a halt, but the codebase is still maintained, fixes for discovered problems are still available, although with a significant delay; new slimmer implementations of the same ideas start to gain prominence and reach the adolescent or later phases. If distributors exists, we can observe the defection or disappearance of distributors. Generally this phase is characterized by a shrinking user population. In the operation system area, we can think about VM/CMS, VMS, OS/2, Windows 9x, etc.
    

5. Abandonment and clinical death: the remaining user population rapidly migrates to other products and/or hardware; the product is no longer supported and nobody is working on fixes for existing problems. In the operating system arena we can think here about DOS 6.22, DrDOS, Windows 3.1, PDP-11 OSes, Multix, and so on. As in nature this phase actually does not presuppose the completion of all previous stages and can occur after any of them. Still there is an important difference between programming products and biological organisms: software products, and especially free/open software products can be resurrected, but still in such cases the development continues from the same phase in which the product died.

Probably the single most important point of this chapter is that if we assume the existence of stages in software development (it does not matter if they are the same, as I proposed above, or different), it is logical to assume that a free/open software license might benefit from the ability to evolve with the stage of the software development, as different stages of the software life cycle feature different compositions, degrees of importance and levels of interaction with the principal developer of major user subgroups (users, distributors, contributors, creators of derivative works.)  That means that instead of attempts at creating complex all-encompassing licenses suitable for each and every stage of the life of the product, as well each and every user group it is possible to use a set of simple "basic licensing modules" each of which is well-suited for a particular stage in the development of the product and can expire when the product reaches the next stage in its lifespan. This approach to licensing will be more fully  discussed in the third chapter of the book.

1.5. The Social Importance of the Level of Complexity of the License

The road to hell is paved with good intentions
Proverb

If we can view licenses as algorithms, as I suggested before, it is only natural to use some metrics of their algorithmic complexity. That gives us a new point of view on software licenses in general, and BSDL and GPL in particular. After all, open source is about simplicity and transparency on the source code level. And it might be beneficial to extend this to the simplicity of  licensing.  If we use the analogy of  free/open software development as a social activity with a certain set of rules,  then the simplicity and comprehensibility of rules for all participants is of primary importance.  One should not need a brain transplant to understand the license.

The widely held misconception is that GPL is a simple license. This is an urban myth. The following quote from Slashdot discussion  Open Source Legal Issues by attorney Dan Ravicher[Ravicher2000] nicely illustrates this point:

Therefore, under the GPL, if the non-source code files are "distributed as part of a whole which is a work based on the [GPL'd] program," then the whole application, including those non-source code files, must be distributed under the GPL. However, if the non-source code files are not "based on the [GPL'd] Program" and are "merely aggregated" with the GPL'd program for distribution, then those non-source code files do not have to be distributed under the GPL. This means that the issue lies in how the non-source code files are incorporated into or with the GPL'd program. If no source code exists for parts of the work, section 3 of the GPL states that "the preferred form of the work for making modifications to it," must be distributed in order to satisfy the "source" distribution requirement. Since I have very little technical knowledge, I'm not sure exactly what is "the preferred form" for making modifications to image and sound files.

Some developers assume that if  they license software under GPL, they will automatically avoid complex licensing issues. This is very true for unpopular products, but for them it does not matter how they were licensed. 

It is now common understanding that for popular products GPL introduces a lot of non-trivial problems. I sometimes hear from students that using GPL gives them the ability to avoid "all the licensing crap." Well, unless you did not read the license, I'm not so sure about that. To a certain extent the GPL seems just as complex and irritating as EULA. The difference is that the GPL makes a very broad and sweeping grant of rights to users and "developers of derived products" as opposed to the highly restrictive grant by EULA and other closed-source/commercial software licenses given to the software users and only to software users.

Just compare nearly 2K words of the GPL (not counting articles 'a' and 'the' and with the prolog and epilog removed; more than 2.7K words otherwise) to less than 500  words of BSDL (in the total text of the BSD 4.4 license). It's difficult to avoid the impression that GPL is a more complex license (and thus potentially containing a number of unanticipated pitfalls.)

For example, even a simple question about the fair use quoting of GPLed programs/documents under close examination does not look trivial. In the quote below we can see two conflicting interpretations (several other also exist;  See Re Two GPL Questions):

Incorrect answer (Score:1) by evin on Tuesday June 05, @09:35PM EST (#169) (User #31167 Info)

In response to the shrink-wrap question, he said: This arguably prevents someone from making a fair use of GPL'd code (for example, by taking a small line of code and incorporating it into a million line program which is part of a doctoral thesis). However, by entering into the GPL, the licensee possibly waives her right to make any such fair use. The GNU GPL is an optional contract -- you can make fair use of the code without accepting its terms. Therefore, I can always take a small line of code from a GPL'd program without worry. The answer being requested was whether shrink wrapping is/should be a valid way of entering a contract. IMHO, it shouldn't, especially for things where it says "By opening this box you agree to the terms inside." I can't give consent to something I can't see. If I buy your software and you're not satisfied with the normal licensing terms you get by default under copyright, you should require me to sign and mail you an actual contract.

I think that even the simple considerations outlined above suggest that, considering the complexity and unanticipated side effects of GPL, the BSDL has a definite edge. The ability of GPL to create unforeseen (and possibly  not yet even known) side effects is especially worrisome for mature products and was well demonstrated by several historical precedents.

For example, an innocent looking phrase "either version 2 of the License, or (at your option) any later version"  in the beginning of 2002 suddenly became a hot issue for Linus Torvalds (more then ten years after the adoption of the license). And not only for him, but for the developer of glib too.  Here is what Linus Torvalds wrote about his action to block the possibility of licensing th