Softpanorama Bulletin
Vol 13, No.01 (January, 2001)

Prev | Contents | Next

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

Dr. Nikolai Bezroukov

version 1.02

Prev | Contents | Next

Copyright 2000-2001, 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 the Linux kernel under v.3 of the GPL, the action that largely undermined the viability of the GPL 3.0 efforts of RMS [Linux-Kernel Archive Linux-2.4.0-test8]:

The only one of any note that I'd like to point out directly is the clarification in the COPYING file, making it clear that it's only _that_ particular version of the GPL that is valid for the kernel. This should not come as any surprise, as that's the same license that has been there since 0.12 or so, but I thought I'd make that explicit.

Why? There's been some discussions of a GPL v3 which would limit licensing to certain "well-behaved" parties, and I'm not sure I'd agree with such restrictions - and the GPL itself allows for "any version" so I wanted to make this part unambiguous as far as my personal code is concerned.

The reason I wanted to mention that particular issue here explicitly (rather than as just a one-liner in the changelog) is that code written by others is obviously under _their_ discretion, and not limited by my personal foibles, fears and misgivings. If anybody wants to explicitly state that their code will be valid under any version of the GPL (current or future - whatever they may look like), please send patches to say so for the code in question. If you've used the FSF boiler-place copyright notice, you already have this in place (it says "v2 or later" - the FSF itself doesn't recommend v1 any more).

(Me, I'm taking the careful "wait and see" approach. I don't know if a GPL v3 is imminent, and I don't know if the issues discussed will even _become_ real issues, so you might as well consider me a paranoid, if careful, bastard).

Here is a typical sentiment expressed about the complexity of GPL on Slashdot:

Re:hmm by bmajik ([email protected]) on Tuesday June 05, @01:26PM EST (#65) (User #96670 Info) http://www.mattevans.org

This sentiment is exactly what a certain large company with a bad reputation on Slashdot is painfully trying to express. The GPL is _not_ a "Free" or "unrestrictive" license in any way shape or form. BSD licensed software is effectively worry free. Paste in the banner into your about box, done. But to a traditional software company, the GPL is the most frightening thing ever. Nearly every aspect of it is legally dubious.. including the extent and conditions of its viral nature. To those organizations that are currently IP-focused for revenue, the prospect of a court randomly deciding to strip them of their assets is easily reason enough to not bother. For a number of reasons, which Dan and others have hinted at or expressed directly, "safe" GPL development from a traditional software company is very tricky, and needs lots of spendy lawyers to sort through specific issues on a case by case basis. The situations where GPL is a worry free endeavor are few and far between. That it hasn't gotten anyone into serious trouble yet doesn't mean it wont.

The fact that no can one be sure that all the side effects of GPL v. 2 are already known can be a serious disadvantage for a large project relying on GPL, as KDE developers now know all too well. In this sense the KDE problems with GPL (see below) can be an indication that an adoption of a simpler license or double licensing may be a solution beneficial for other free/open projects that approach or have already reached a mature stage of development (for example Gnome, KDE, Samba).

Here one should remember that a free/open software developer needs to play many different roles and each role requires a certain time and effort. It's wise to try to minimize any distractions from the development per se. The last thing any developer of free/open work wants is to become a full-time license interpreter. But as we will see later, unless the developer is stuck with the Linux environment, the problems of the interaction of GPLed products with software licensed under different software licenses can become a serious drag on his resources and limit flexibility.

Moreover some companies are openly hostile to GPL, and now include licensing provisions that complicate or make it impossible for GPLed products to use free components/tools supplied by those companies. One such case is the license of the second beta version of Microsoft's Mobile Internet Toolkit, that explicitly prohibits customers from using the Microsoft software in conjunction with what they call "potentially viral software". The latter category explicitly includes software licensed under GPL[FSF1991], the Lesser General Public License[FSF1999a], the Mozilla Public License [Mozilla1999] and the Sun Industry Standards License [Microsoft2002, FSF2002].

The fact that the Mozilla project took pains to re-license the codebase under an MPL/GPL/LGPL triple license[Mozilla2001] to avoid conflicts means that a dual licensing mode became almost standard for large and mature free/open projects. Even Linux kernel can be considered dually-licensed if we consider the "Linus amendments" as a separate second license (see below). This is especially true if the product is not using the Linux environment exclusively and needs to provide ports to several operating environments including Win32.

At the same time I feel those complexity-related issues of GPL are not such a big a problem in the early stages of the non-commercial development of an individual product by a single developer or even several co-developers. This can be considered to be a "natural" environment for GPL (Stallman created GPL during the process of rewriting Emacs when he faced problems with reusing commercialized code of Gosling Emacs). Because of its origin GPL can really provide some physiological comfort for developers that are afraid of hijacking of their codebase. See chapter 2 of the book for the discussion of this issue and actual level of protection against hijacking of the codebase provided by GPL.

In the early stages of development, the interpretation of the license is not a big issue, because the number of developers and users is small, and they are close enough to be considered a circle of virtual friends. At the same time GPL requirements for derivative products to use the same license might spook some free-riders, although the level of actual protection here is open to debate and will be discussed in the second chapter of the book.

Still the main social attractiveness of GPL in the environment discussed is some kind of psychological security in the sense of "protection from hijacking." It may be illusive, but it is still here and still is important. As with many other social illusions, that doesn't prevent GPL from becoming a powerful organizing force. But it's important to remember that I am talking here only about an early stage of product development.

1.6. GPL License Clarification as an Important and Never Ending Social Process

It is well known that GPL was never tested by the court. One recent case does not qualify as a test of the license, although it might do so if the defendant claimed the legal unacceptability of GPL as a part of its defense; such avenue of defense is theoretically possible, because some authors consider GPL to be legally unenforceable[Hackvan1999]. Still, opinions about the legal properties of GPL including its legal enforceability that currently exist are what they are: opinions. And that includes FSF views on the subject.

But, as I stressed before, even with no possibility of legal enforcement, GPL is an important social force that shapes the behavior of many free/open developers. This chapter discuss social dynamics and social perception of the licenses only, and we will purposely avoid the intricate legal aspects of the interaction of GPL with the current copyright and intellectual property law. Those issues are better left to lawyers.

We will consider the existence of those complex legal issues to be an important part of the social environment in which GPL operates, and thus an important force that creates a certain type of social dynamic in the free/open software developers community: due to the complexity of the GPL, its interpretation became a very interesting intellectual game with many players, including players that are trying to assume and institutionalize for themselves the role of the "Supreme GPL Clarifier."

Moreover in keeping with our "programming intelligentsia" view on the community, the ability to interpret GPL is subject to innumerable debates and is widely considered an important and worthwhile social activity in this social strata. The ability to discuss this topic even has a status enhancing potential in the most radical part of the free/open community (that applies for both media outlets and individuals; Slashdot can serve as a media outlet example, while Bruce Perens probably can be used as an example of an individual).

This complexity even gave rise to a special genre of pages and Usenet postings known by the generic name GPL Clarifications [ Oncoresystems2002]. This approach modifies our previous view on the "programming intelligentsia" as two interconnected and interdependent camps with one preferring BSDL and the other preferring GPL. It is not mere acceptance of GPL, but the acceptance of FSF as "The Supreme GPL Clarifier" can serve as a litmus test that differentiates between the above mentioned camps. That, for example, means that logically most Linux kernel developers including Linus Torvalds should probably be considered as dissidents in GPL camp.

1.6.1. Twelve Candidates for the Inclusion into GPL FAQ

Due to changes in the software environment, with the advent of the WEB and distributed computation, GPL 2.0 became fuzzy in areas that were not anticipated at the time of its development. That fact, along with the poor quality of the www.gnu.com site materials that address those new questions, increased the intensity of the "GPL Clarification" process in the community. Below I listed the questions that I have found on the Internet using the Google search engine and the search phrase "GPL problems". This list might constitute a nice addition to the GPL FAQ that was recently created by FSF [FSF2001]:

1. Does GPL approves some types of social behavior that generally contradict the logic of the copyright law and academic ethics principles ? The answer is yes. Ironically, GPL actually allows companies that adopt it to act more, not less, like a traditional closed-source company. When a company offers its software under GPL, it typically requires all contributors to assign the copyright of their code to the company in order to be able to offer commercial licenses to the product to make money which pay for work on the GPL version. That in turn ensures that the holder of the copyright is able to act as a monopolist -- a side effect that Richard Stallman missed when he created GPL.

   Over 75% of Linux development is now funded by large corporations. Claiming that Linux developers are not conventional thinkers just screams delusion: you can' survive in a large corporation in that role.

   Also practice of GPL usage shows that it does not protect the original author from plagiarism, i.e., distribution of a (slightly modified) work with all traces of the original author removed. That property is not accidental and is connected to the fact that Stallmanism is a "software anarchism." One form of plagiarism is the "GPL renaming game": renaming of the GPLed product with a notice buried somewhere in the code (GPL formally requires such a notice, but it can be put anywhere) is acceptable under the GPL. That means that anybody can rename and re-release the product without the original author consent and such practice proved to be quite popular on the Internet. Sometimes renamed products make their way into major archives because nobody analyzed the source code.
   
   For example Tara (Tiger Analytical Research Assistant) is not a new derivative product based on Tiger but ripware -- renamed original package (Tiger 2.2.3) with just a minor bugfix (environment variable GROUPS was renamed to GROUPSS because of the conflict with the existing global environment variable on some Unix systems). See web site TARA - Tiger Analytical Research Assistant. That means that implicitly GPL approves some types of social behavior that generally contradict both the logic of the copyright law and academic ethics. Here is a relevant quote from Donald Becker, the author of several popular Linux Ethernet drivers [Becker2001]:
   

   Several drivers have been distributed that are little more than renamed versions of my drivers. Some have my name, the copyright notice or the Gnu GPL license notice removed. The less flagrant violations merely fail to note that the driver has been modified from the original version. (The GPL requires such a note.) Here is a mapping from the bogus driver name to the official name:

   mpx5030.c	rtl8139.c
   smc1211.c	rtl8139.c
   rtl8029.c	ne2k-pci.c

2. How does the right to redistribute the code conflicts with the security of the code? Some authors explicitly prohibit redistribution of modified versions on this basis. For users, that also creates some anxiety: if each module of software is not signed with cryptographic signatures, it's difficult to be sure that the source was not modified by somebody else (there were several such cases on the Net, with the most well known related to tcp_wrappers). There also might be the question of liability and/or damage to the reputation of the author, if a virus, Trojan horse or backdoor were planted into the source. For example, in response to the RMS letter about the licensing of the ip_filter and tcp_wrapper, Tres Melton[Melton2001] noted: 

   You mentioned the license as not being free to modify and redistribute djbdns (qmail, and ucspi-tcp). The reasons for this are Mr. Bernstein's and are related to security. It seems that he doesn't want to have modified versions that might have security problems running around the Internet for people to download thinking that he has given them his blessing. I have been a programmer for many years but security is not my forte. I have audited his code (to the best of my abilities) and am reasonably sure of its security; enough to be running his software on my machines. I find his code to be exceptionally clean and well thought out. This is in stark contrast to some of the other servers (sendmail, bind, etc.) that are distributed with the various GNU/Linux distributions. These programs seem to focus on features to the detriment of security.

   Was it not a security flaw in sendmail that brought the Internet to its knees in the 80's? I believe the first time the major news outlets covered the Internet was to say that it was being devastated by an unknown problem and most of the major sites were pulling the plug to The 'Net until they could fix it. Although that was a bit before my time I'm currently very aware of the various bugs that have been exploited recently in multiple BIND vulnerabilities to create a multitude of migraine for various system administrators throughout the world.

   A great deal of software that I use that is considered free and/or open and I enjoy tinkering with it. I also enjoy the new features that come out on a regular basis. Unfortunately some of these features come out without serious thought put into their security. When it comes to running these programs on my desktop, behind my firewall, with limited local access, I can easily tolerate these mistakes in the name of progress. When it comes to a corporate server that is exposed to the Wild, Wild, 'Net that is a different story. In that case I'm very thankful that programs written by Mr. Bernstein have his seal of approval; not to mention having survived the security bounty that he has placed on these programs:

   http://cr.yp.to/djbdns/guarantee.html "I offer $500 to the first person to publicly report a verifiable security hole in the latest version of djbdns"

   I believe that qmail had a similair bounty for awhile too.

   I realize the difference between DJB's programs and ipfilter is that ipfilter is embedded within an OS with its own license and not running on top of it as a service. And I'm not sure how to address a license that is a small part of a whole product with a different license, as in the case of BSD and ipfilter. I do know that I'm willing to accept things like:

   http://cr.yp.to/qmail/dist.html

   If you want to distribute modified versions of qmail (including ports, no matter how minor the changes are) you'll have to get my approval. This does not mean approval of your distribution method, your intentions, your e-mail address, your haircut, or any other irrelevant information. It means a detailed review of the exact package that you want to distribute.

   If it means that I can be assured that the code has undergone a thorough security audit by the author and has his/her seal of approval. I know that Linus keeps a tight leash on 'his' kernel: as distributed by kernel.org but that it doesn't always get the review that it might need. The various forks of Linux are even more murky. I would be in favor of the firewalling code and other security portions of the kernel either not being modified or having the modifications approved by the authors. I know that RMS might not agree but he has the expertise to verify his own code. Some of us do not. The freedoms granted by the GPL are very important to me but so is secure code. There are certain circumstances in which I would be willing to forgo the third freedom of the FSF...

   It's unsurprising that in his response RMS avoided addressing the critical problem of liability and damage to the reputation of the author and promptly shifted the question to a political area more beneficial for him: 

   "It is clear that your goals and values are very different from mine. I don't think technical merit can make up for a lack of freedom to distribute modified versions, any more than a capable despot who makes the trains run on time can make up for a lack of democracy."  

3. What number of GPL amendments still preserves the compatibility of a product with other "more pure" GPL products without violating paragraph 4 of GPL: "You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License." ? For example, there are two major "Linux amendments" to the GPL:
    

   • The First Linux Amendment is related to the possibility of using proprietary user-space programs with Linux:

     "This copyright does *not* cover user programs that use kernel services by normal system calls -- this is merely considered normal use of the kernel, and does *not* fall under the heading of 'derived work.' "

   • The Second Linux Amendment stipulates that proprietary device drivers that use the normal driver/kernel interfaces are OK, because all the exported kernel interfaces are considered to be LGPL. [GCOM2000]

   Still Linux is widely considered to be GPLed software. GPL can be viewed as "The Incompatible License" and potentially the mere presence of "strict GPL" products in any Linux distribution creates a "GPL compatibility" problem [Stallman2002a]:

   The presence of these binary-only programs in "source" files of Linux creates a secondary problem: it calls into question whether Linux binaries can legally be redistributed at all. The GPL requires "complete corresponding source code," and a sequence of integers is not the source code. By the same token, adding such a binary to the Linux sources violates the GPL.

   Of course the Linux movement is a more powerful political force that FSF and thus RMS compains about "GPL compatibility with Linux kernel problem " can be safely ignored. Moreover as the copyright to the Linux kernel was never assigned to FSF, from a legal standpoint (and GPL became a paradise for lawyers ;-) FSF lacks "standing" in this case (see above). But still the question of the compatibility of Linux GPL++ (GPL with two amendments) with "pure" GPL looks like a tricky one. I think that one possible way to resolve it is to explicitly assume that the Linux kernel is dual-licensed with the amended license forming the second license.
    

4. If some commercial company uses that free/open product, to what extent are they liable for damages to the original author, if some code in this product was GPLed illegally? Suppose an individual or company wrote a proprietary driver (or other software) and someone else managed to get hold of the software and contributed the source code to a new or existing project that uses GPL. If some commercial company uses that GPLed product, would they be liable for damages to the original author? This is a generic problem for all free/open licenses, but judging from a comment to the Kero5in.org news story "Stolen Open Source a Corporate Legal Risk?" [Gregbillock2002] in this particular situation using BSDL and Apache licenses might be less dangerous than using GPL:

   yeah, it's a real risk (5.00 / 8) (#14) by gbroiles on Tue Apr 9th, 2002 at 12:38:09 AM EST

   ... but probably not a big one. You don't need the hypothetical "stolen source" example - a more believable (and likely) example would be source code apparently contributed to an open source package which was (by oversight or ignorance) not within the power of the contributor/author to grant - for example, if the code were written by someone whose employment agreement (or other terms of employment, perhaps supplied by custom or local law) specified that all of the intellectual property they created during the course of their employment - or while on the premises of their employer, or created using the equipment of the employer - belongs to the employer. Now the open source package/project can't get a license/copyright assignment from the author .. because the author has already granted those rights to another, or because they never had them in the first place. That, by the way, is the default assumption in the US - that if you create IP during paid hours using your employer's equipment, it belongs to the employer, not the employee. Some open source projects are aware of this issue and require written assignments/licenses for contributed material; that's a good first step, but ignores the fact that if the employee doesn't have the IP, they're unable to grant a license or assignment. All the open source guys can do is ask for indemnification by the employee if their license/grant turns out the be faulty .. but that's not worth much, in most cases, because the employee has (comparatively) no assets to back up the indemnification, and the open source group is likely to be unwilling or unable to bring suit to enforce the indemnification clause. This - in the real world - doesn't turn out to be an especially awful problem, because most people act reasonably most of the time. Even if there are problems in the chain of title/assignment for the IP in big software packages .. so what? The IP involved isn't likely to be especially important, if it's only copyright in widely distributed source code - that's pretty easily recreated in a cleanroom environment, so this doesn't have the same potential for abuse and extortion that patents do. IBM's legal department spent a long time worrying about this before IBM embraced Apache and Linux - eventually they just got over it. Other companies will, too. (I was corporate counsel for C2Net, a small software company which was negotiating a license for an Apache derivative to IBM in 1997-1998, so I spent a lot of time on the phone and in email explaining why we couldn't indemnify them against all possible problems in the Apache source, etc.)

5. At what point in the rewriting of a GPL program can one be sure that he/she eliminated all GPL license requirements ? At what point can I change the license to BSDL or another license, if I almost completely rewrote the GPLed code ? Let's now assume that I started developing my program using a GPLed product as a prototype and made so many changes including architectural ones that it now constitutes a completely new product (think of the story of the BSD mini kernel published in DDJ by William and Lynne Jolitz modified into Linux kernel, but now applied to the Linux kernel as a prototype and with, say, BSDL as a target license). What if some traces of the original GPLed code still remain. Can be they called an infringement? See also a related question about fair use below.
   
   The same situation arise when the company initially uses GPL code but later understands that it open the company to all sorts of negative PR attacks and decides to rewrite it to the other license. At what point such a company can feel safe ? does such point exists at all.
    

6. How do fair use provisions of the copyright law interact with GPL ? If I borrow a fragment from a GPLed program, am I protected from the threat of expansion of GPL on my product by the fair use principle of the copyright law or not ? For example, one osOpinion column "Computer News Fair Use and the Fallacy of GNU" [TechnoJoe2001] provided an interesting critique of FSF's stance on the subject:

   The copyright laws include the doctrine of "fair use," which overcomes the exclusivity rights and other restrictions placed on copyrighted material and gives people the right to use copyrighted works without permission, even when permission is explicitly denied. See Campbell v. Acuff-Rose Music, Inc., 114 S.Ct. 1164 (1994).

   ... ... ...

   Assembly code would have way more lines than the exact same code in C. What is the context of fair? Is it 10 percent of the lines of a specific author's work, 10 percent of the lines in a file, 10 percent of the lines in a module, 10 percent of the lines in the entire Linux kernel, or 10 percent of the lines in an entire Linux distribution? Because GNU GPL has never been challenged in court, these questions remain unanswered.

   Free for the Taking

   GNU GPL really shoots itself in the proverbial foot on the fourth point. Lastly, the courts consider the effect of the use on the potential market. Since GNU GPL protected software must be freely redistributed, any use of GNU GPL protected code would have no harm to the potential market for the original work.

   In addition to the fair use loophole, not all software is protected by copyright. Some software is in the public domain. For example, any software created by the United States government is in the public domain.

   Also, copyright protects only the ways ideas, systems or processes are expressed, but the ideas, systems or processes themselves are in the public domain.

   The Ultimate Irony

   I think it's ironic that the openness of copyright laws through fair use and public domain could allow developers to create a proprietary, closed source program that uses GNU GPL protected code. Further, I think it's ironic that fair use can only be applied so liberally to open source software, because only open source software allows people to subject the source code itself to fair use.

   In another relevant paper about the concept of fair use Professor Bell stated that generally nobody can claim an infringement unless there is a market that was harmed [Bell1998]

   In American Geophysical, eighty-three publishers of scientific and technical journals joined in a class action copyright infringement suit against Texaco, alleging that the defendant had made unauthorized photocopies of individual articles from their [p. 567/p. 568] publications.[45] Among other defenses, Texaco cited fair use.[46] It lost in the district court,[47] appealed to the Second Circuit, and lost yet again.[48]

   The outcome of the case turned on the crucial fourth factor of the fair use defense,[49] which requires a court to consider "the effect of the use upon the potential market for or value of the copyrighted work."[50] Citing the district court's findings of fact, the court of appeals held that the publishers had, with the help of the Copyright Clearance Center, created "a workable market for institutional users to obtain licenses for the right to produce their own copies of individual articles via photocopying."[51] This made it difficult for Texaco to claim that its unauthorized copying had no impact on revenue the plaintiffs might have earned from their copyrights. As the court of appeals explained, "the right to seek payment for a particular use tends to become legally cognizable under the fourth fair use factor when the means for paying for such a use is made easier."[52]

   Because he disputed whether the plaintiffs had created a workable market for licensing copies of individual articles, Judge Jacobs dissented. Absent such a market, he opined, the majority's reasoning ran in circles: "[T]he market will not crystallize unless courts reject the fair use argument that Texaco presents; but, under [p. 568/p. 569] the statutory test, we cannot declare a use to be an infringement unless (assuming other factors also weigh in favor of the secondary user) there is a market to be harmed."[53]

   The proposed test of "the effect of the use upon the potential market for or value of the copyrighted work." might be applicable to the case of any GPL infringement: if the license explicitly denies the possibility of the creation of a market by allowing free replication and further redistribution of a product at zero cost, it is impossible to harm it.

   Paradoxically the same test opens GPL to lawsuits like Daniel Wallace price fixing lawsuit. He accused FSF of dumping and claims that FSF engages in price fixing by getting multiple vendors to agree to give their products away for free. The is anti-competitive, because it prevents other vendors who don't want to give their products away for free from entering the market. [EOSM2005]

   In it he says the GPL is "slowly destroying the market for independent software applications" and that the FSF is out "to destroy the intellectual property value in computer software," drawing the agency's attention to such FSF-produced collateral as the provocatively titled "dotCommunist Manifesto."
   
   Wallace told the regulator that the obvious target of the open source business model is Microsoft and Windows.
   
   "Unfortunately," he says, "it is not Microsoft who suffers. The result of this predatory pricing at 'no charge' for intellectual property under the GPL license is causing the foreclosure of any remaining intellectual property market for the individual software developer and small business entrepreneur dealing in POSIX operating systems and various applications for the desktop and enterprise markets. The license is a per se violation of the antitrust laws."
   
   Taking his argument a step further, he says, "Removing the profit incentive in intellectual software property creation is even suppressing the enrollment of new students training for careers in the computer sciences here in the United States."

7. How do sweeping grants that are bestowed on users and creators of derivative works in GPL interact with the third party patents and trademarks that the original author may hold ?  Let's assume, for example, that British Telecom(BT) owns the hyperlink patent and the conditions of its free usage specified by BT are incompatible with GPL. Does this prevent distributing any GPL software that uses hyperlinks? A similar question applies to trademark law. Is it possible to limit the redistribution of exact copies of the GPLed work by using the trademark law in a way similar to Red Hat's protection of its trademark against Linux CD publishers like www.cheapbytes.com. Here is a quote from the Red Hat Trademark Guidelines [Redhat2002]:

   It is important to understand that, although Red Hat allows third parties to replicate its open source software under the GNU GPL, absent a written agreement or other express permission it does not allow third parties to use its trademarks. For example, absent a trademark license from Red Hat, a party would have the right to copy, modify and sell Red Hat's open source software, but they would have to call it by another name. Red Hat has always been fully supportive of open source rights with regard to copyrights and demonstrates that support by releasing the software we develop under open source licenses. This document is designed to provide guidance on how the software developed and marketed by Red Hat may be copied, modified and marketed by others, with particular emphasis regarding appropriate use of the Red Hat trademarks.

8. Can GPL be used as a "dumping ground" license: the license for all previous versions of the product, the latest version of which is released under another license ? For example, Ghostscript releases the most current version under the Aladdin Free Public License. About a year later this version is re-released under the GPL. Can this newer version formally be considered a "derived work" of the earlier GPLed version and thus unprotected from unauthorized copying along the lines of the following question from the FSF GNU FAQ [FSF GNU FAQ], but substituting the word "patches and additions" instead of the word "deletions" ? :

   Can I release a program with a license which says that you can distribute modified versions of it under the GPL but you can't distribute the original itself under the GPL?

   Such a license would be self-contradictory. Let's look at its implications for me as a user.

   Suppose I start with the original version (call it version A), add some code (let's imagine it is 1000 lines), and release that modified version (call it B) under the GPL. The GPL says anyone can change version B again and release the result under the GPL. So I (or someone else) can delete those 1000 lines, producing version C which has the same code as version A but is under the GPL.

   If you try to block that path, by saying explicitly in the license that I'm not allowed to reproduce something identical to version A under the GPL by deleting those lines from version B, in effect the license now says that I can't fully use version B in all the ways that the GPL permits. In other words, the license does not in fact allow a user to release a modified version such as B under the GPL.

9. The questions connected with fuzziness around the notion of "distribution" in GPL.  The previous question was connected with the fuzziness of the notion of "execution". The key word here is "distribution", and Clinton-style discussions about the meaning of this word are quite possible. The set of questions related to this problem, which can be found on the Internet, includes but in no way is limited to the following:
    

   • Is creation of a proprietary derivative of a GPLed program for the explicit purposes of using it on a Web site allowed under GPL ? This is not a distribution, is it? Here is how this question was discussed in Distributed Computing Foundry:

     For example, suppose Alice wrote a shopping cart Web application, and released her source code under the GPL. Now suppose that Bob takes Alice's source code, modifies it, and runs it on his Web site. Does Bob need to release his modifications under the GPL?

     Under the current terms of the GPL, the answer is most likely no. Bob is not distributing the software, so he is not required to GPL his modifications. This ultimately circumvents the purpose and spirit of the GPL, in that Bob benefits from free software, but is not required to return that benefit to the community.

   • Can I create a legal entity and distribute the proprietary modification of GPLed code just to the members of this entity to bypass GPL requirements ?  This controversial idea surfaced at Slashdot (see Slashdot discussion: Hole in GNU GPL) and in essence can be explained as the creation of a legal entity (for example a non-profit foundation) for the explicit purpose of circumventing the notion of "distribution" used by the GPL. GPL mandates this by requiring that modifications to software licensed under the GPL also be distributed under the GPL. But formally this is an "external distribution" and this limitation does not apply to the "internal distribution" within a given legal entity, for example a corporation. The GPL FAQ states:

     You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization."

     If only members of this specially-created legal entity (let's call it "Truly Free Software Foundation" (TFSF)) are eligible to use the derived proprietary program that incorporates GPLed code, than formally this is not a "distribution" as defined in GPL. For example one can distribute a proprietary version of gcc with a better code-generation engine to members of such legal entity without violating GPL. As we mentioned before, legal issues are outside the scope of this chapter and we provide information about the possibility of creating an umbrella organization for distributing commercialized GPLed programs to members (for example in the form of the above mentioned TFSF ) just as a nice illustration of our general point about the complexity of GPL.
      

10. How does GPL work for kernel drivers ? This is a complex question that can be subdivided into several typical sub-questions. The set of questions related to this problem that can be found on the Internet includes, but is in no way limited to the following:
    

    • May I write a non-GPLed sound driver that loads some GPLed microcode onto the chip? For example, a developer might want to find a way to integrate his non-GPL driver code that is written for a non-GPL kernel, but needs to load the GPL'd microcode dynamically. Here usually there are a few data structures in the header that a developer needs to access to properly initialize the card, but they can be easily rewritten, making them syntactically different but representing the same memory mapping. Does this solve the GPL licensing issues or not ? Actually this possibility was at one time raised by Alan Cox and he got the following response (note the level of legal thinking involved)[GCOM2000] :

      ...Alan is incorrect in a crucial point. Linus' opinion very much counts when it comes to licensing issues. The reason is that in U.S. tort law there is a concept known as "standing". "Standing" means that in order to have a court hear a complaint, the person filing the complaint must be the party that was harmed by the alleged action. This means that I can't file a lawsuit alleging that you were harmed by someone else's actions.
      
      The case of the Linux kernel is complex in that there are a number of copyright holders. Unless there is an agreement subordinating all other copyrights to Linus, each copyright holder retains certain rights with respect to the portion of the code that they wrote. In Tom Johnson's words:
      
      "... Linus cannot claim copyright ownership on the whole. Each copyright owner can sue if the infringer is using the file that
      copyright owner created. If a license is granted, the person claiming violation can only sue if that person's file is being used. Lots of times, the later files are developed based on or working with the original files so they become derivative files under copyright law. That means that the owner of the derivative files can only grant a license on his own files, not the underlying or original files; neither can the original file owner grant licenses on the derivative files. If someone is using both original files and derivative files without a license, either owner can sue but typically they will cooperate in bringing a suit."
      
      So, theoretically at least, it comes down to who wrote what in the Linux kernel. What did Alan write? In the 2.4 kernel source Alan's copyright appears on 11 files which also contain copyright notices of others. His copyright notice appears on just 6 files as the sole copyright holder. These files are mostly sound card drivers and watchdog board drivers. He does have a sole copyright on the traffic shaping module that seems to be an interface between IP and serial line network drivers.
      
      So if Alan wanted to file a lawsuit alleging violation of the strict GNU license, he would have standing in the case that the alleged violator used any of these eleven files. (Depending on the agreement with the other joint copyright holder, Alan may not be able to commence a lawsuit without the agreement of the other joint copyright holder).
      
      By contrast, Linus' copyright appears on 336 files in the 2.4 kernel source, including a few of the files jointly copyrighted by Alan Cox.
      
      ... ... ...

    • Is it OK to release the driver for a GPLed kernel as non-GPL and under a license, incompatible with the GPL? Here is a typical question posted by Dave Allen to the Linux Kernel mailing list [Allen2000]

      My company is currently working on a linux network driver (I'm sorry, but I can't disclose which company or the nature of the driver right now). However, recent discussions on this list have made me grow concerned about licensing problems with the GPL.

      The source code for the driver _is_ going to be available, but it will not be GPL'd. There are no patches to the kernel involved. I understand that there should be no problems, but the use of inline functions in the kernel header files makes the situation a bit more complicated. The compiled binary code then does contain GPL'd code, so would it not then be considered a "derivative work"?

      If indeed this is a violation of the GPL, is there any way around this by releasing only the source code (even though it isn't GPL'd)? I mean, the compiled binary code does contain GPL'd code, but the source code does not. Is it OK to distribute this?

      So, I'm asking the experts here for opinions or insights.

    • What are the consequences of using GPLed drivers in non-GPL products? Here is a relevant quote by James MacMillan from QNX Software Systems Ltd. [QNX2001] that suggests that some commercial developers are concerned about this issue to the extent that they rewrite GPLed drivers:

      The drivers that shipped with the QNX RTP prerelease are based on the ALSA (Advanced Linux Sound Architecture) 0.5.2 sources (http://www.alsa-project.org). The ALSA API provides highly detailed control of the internals of a sound card. Many of the contributors are experts in the field. However, we reevaluated ALSA's suitability and were faced with a number of issues that brought us to the decision to write our own drivers.

      GPL and embedded systems

      Chief among the issues was the GNU Public License (GPL). While the open-source movement is rapidly gaining acceptance in the business world and with the public in general, the embedded world has constraints above and beyond those in the desktop arena. A number of our customers had expressed concerns about sections of the license. To address these concerns we are rewriting our drivers without GPL code.

      Actually the problem is not limited to drivers. There is a huge amount of hair-splitting debates about "GPL compatibility" problems on the Internet. See for example Using GPL incompatible components
       

    • What if somebody wants to run GPLed drivers on a non GPLed system, for example recompiled Linux drivers on Solaris for Intel ? There was a controversy around a tool provided by Sun for converting GPLed Linux drivers to the format compatible with the proprietary Solaris kernel for X86 architecture [Slashdot2000]. That controversy gave rise to a special genre of "GPL Clarifications" [Oncoresystems2002]:

      Although parts of the microkernel were derived from public sources, it has zero GPL and/or Linux code in it. We have enabled two complementary driver strategies - a native driver interface for "bare metal" performance, and a Linux driver interface that allows the immediate use of the growing library of Linux device drivers, without Linux software being within the solution. The top of our microkernel is an open abstraction layer that allows the use of multiple OS interfaces to be used simultaneously. These interfaces can be enterprise interfaces, like Linux, or any number of RTOS interfaces such as VxWorks, pSOS, POSIX and others.

      See also Linuxgram FSF Lawyers Puzzle Over Sun Hole in GPL
      

11. Are GPL requirements applicable to components, especially to components that use new methods of program interaction less widely used or unknown at the time of writing GPL? For example Web services are now a fashionable topic. The question arises "I am an application service provider, can I run a proprietary modification of a GPLed program over a network using, for example, web services without disclosing the source code?" It's unclear whether web services qualify as a distribution of a GPL-derived program, because here we face a clearly unanticipated usage of GPL. But even simpler and older cases are not that clear. Consider the following shell script:

    /bin/ksh A_GPLed_program | A_proprietary_program 

    Let's assume that this program is a an installation script for a non-GPLed package. Formally this is derived work that consists of three components ksh, A_GPLed_program and A_proprietary_program . Here we assume that ksh is licensed under the license, incompatible with GPL (as is the case in Solaris, HP-UX, AIX, and other System V based Unixes). Moreover ksh is an interpreter not a compiler. As we can see A_GPLed_program also interacts with a proprietary program using pipes, which were known at the time of GPL's creation, but not addressed in GPL.
    
    If a commercial distribution of this script under any license other than GPL is a violation of GPL, then we can suspect that there are quite a lot of GPL violations out there, because no matter what FSF thinks about this case, that's what "people want" and how they actually use GNU utilities. Therefore we can probably safely assume that this is not a violation, and that such usage is just a special case of the "execution" of A_GPLed_program and that I/O redirection (piping interface) is a part of the OS environment. The same thinking is probably applicable to GPL programs that can be invoked in scripts and/or interact with other components via named pipes, sockets or CORBA. For example, it is widely assumed that any CORBA-enabled GPLed program may be used with any proprietary program without violating the GPL(see [piper] Licensing issues):

    If I understood what Richard Stallman had to say on the subject, linking to GPL code through CORBA (from closed-source) is legal, because it's a hole in the GPL. CORBA didn't existed (or wasn't widely used) when GPL version 2 was written. Since future versions of the GPL (remember we can link with any version newer that 2 with the current license) may patch the CORBA hole, I say: "if you want to be allowed to link with CORBA, release LGPL".

    But that also means that this possibility is automatically extendable to any new component architectures like .NET, doesn't it ? Does this also mean that any conversion of a GPLed program into a component (licensed under GPL) creates an opportunity to use it in any proprietary program ?  Here we can also ask: "How do open source implementations based on open interfaces interact with the R&D and promotion efforts of the actual creators of the interfaces?" There is an opinion that the open source community is cutting the legs out from under all the R&D and promotion efforts of open interface strategies of vendors such as Sun and thus are hurting this part of the open development ecosystem [McMillan2002]:

    Q: Well the JBoss guys say that their product has a lot of appeal at the low end, so they see people evaluating .Net and their product, but that there is some reluctance to go with JBoss because it's not certified.
    
    McNealy: I think it's important to have a community process, open specs, and choice for the customer, absolutely. How that gets implemented, I don't particularly care. I actually think we need more revenue in the J2EE space, so that we can do more advertising to get the message out, because right now the world is getting blitzed with Microsoft advertising, and promotion and branding and propaganda, and big lies, and that's why they're going, not because it's a better product.
    
    So, potentially you could make an argument that the open source thing is just screwing up all the revenue models and we aren't getting the advertising, because it isn't the best technology that always wins, it's who advertises more. You could make a very strong argument that says, "No that's messing with it." And in fact Bill Gates may be sitting up there laughing his butt off because the open source community is cutting the legs out from under all the R&D and promotion efforts of all the open interface strategies -- not open implementation, but open interface strategies.

12. Do GPL "linking" problems undermine the broader free/open software movement and keeping software authors hostages to FSF political ambitions by inhibiting usage of useful libraries in GPL-licensed products on one hand and making GPL libraries unusable for free/open software that isn't GPL compatible on the other ? Most researchers now agree that to a certain extent GPL is "The Incompatible License" that does not play well with the majority of free/open licenses including classic BSDL (with the acknowledgement clause). This was never the purpose of GPL as Stallmanism from the very beginning was an isolationist, separatist movement, the tendency that only increased in recent years with the publication of Stallman's paper "Why you shouldn't use the Library GPL for your next library" [Stallman1999b]. That does create problems for authors who adopted GPL for their products, and need to use libraries from authors who adopted a different free/open license or vise versa for authors who are using non-GPL compatible license and want to use a GPLed library. Here is how an author sympathetic to FSF described the situation in his Linux Gazette paper[Kidd1999]:

    I'm really lucky--I write free software for a living. When I decided to stop writing proprietary software, my paycheck got cut in half. (Don't worry; I'll find a way to earn it all back.) My new employer pays me to enhance a mail server used by several colleges. I also do consulting work, since it pays well. All the code I write can be used in GPL'd programs, but very little of it is released under the GPL itself.

    Even though I write nothing but free software, my programs can't link against a GPL'd library. A GPL'd library can only be used in a GPL'd program. Programs using the X11, BSD, Netscape, Mozilla or Artistic Licenses cannot use GPL'd libraries. (Several of these licenses are flawed, but that's another topic.)

    My employer's mail server uses a BSD-style license. I don't have the necessary influence to make them use the GPL. Unfortunately, this means that I can't use GPL'd libraries to make the program better. Instead of doing something useful for the free software community, I waste time reimplementing broken versions of pre-existing libraries. My time would be better spent adding new features to the mail server, or even enhancing an LGPL'd library.

    So in this case, using the GPL for libraries can actually hurt free software. It's not a simple issue.

    Here is a couple of typical letters describing real situations encountered by the authors:
    
    Letter No.1: Re openssl and GPL

    I am still a bit confused as to the problems with linking GPL code with OPENSSL. I don't intend to start any flame wars...
    
    Please send CCs to me. Thanks.
    
    If there is somewhere I can find this information, URLs would be appreciated.
    
    1. What is the problem? I have read the GPL, and cannot recall the problem. According to the top of /usr/doc/openssl/copyright, openssl has a dual BSD style license. I haven't heard of problems linking GPL code with BSD code before. So why is this different?
    
    2. Is <URL:http://www.openssl.org/support/faq.html#LEGAL> wrong? ie. "the GPL does not place restrictions on using libraries that are part of the normal operating system distribution".
    
    I normally like the GPL, but I find it a bit irritating that I can't take some GPL program, and link it against Heimdal (which happens to be linked against OpenSSL), without express permission from all the copyright holders of the GPL software. In fact, I would argue that this goes against the goals of the GPL.

    Letter No. 2: Codec licenses

    M.-A. Lemburg wrote:
    |
    | > scanning through the CVS archive of the SourceForge python-codecs
    | > project I found that most codec packages were placed under the GPL
    | > for some reason. This makes the codecs unusable for software which
    | > isn't GPL compatible and limits its usefulness considerably.
    | >
    | > Please consider either moving to the LGPL which does not have the
    | > GPL problems (other software relying on it will need to be shipped
    | > under the GPL too), but still assures that your code remains freely
    | > available or one of the Python licenses (preferrably the
    | > old CWI one).
    
    Well, I have two (opposite?) thoughts regarding to the licensing of the JapaneseCodecs package.
    
    First, I've released the package under the terms of GNU GPL, because that license is comfortable for me. I want users to "use" the package in the GNU GPL sense.
    
    On the other hand, I hope that many people use my software. If needed, I release JapaneseCodecs or its part under different licensing terms. It is not a problem for me that a package that includes JapaneseCodecs as its part is released under an open source license (like the PyXML package).
    
    To tell the truth, JapaneseCodecs is the first free software package that I've released, and when I released it I was not
    sure what was the best licensing terms for the package. I've chosen the GNU GPL, but the situation seems complex...
    
    If possible, I'd like to utilize two different licenses: the GNU GPL for JapaneseCodecs as a separate package, and another license for the composite package that includes JapaneseCodecs as its part.
    
    Hmm... Does this reply make sense? I'm confused...

With some additional effort and the use of Usenet newsgroups in addition to Google, the number of questions in this "List of potential candidates to the GPL FAQ" can probably be doubled. Please note, that here we do not make any assumptions about the validity of legal concerns that some questions contain, nor the legal ramifications of some plausible answers. My point here is that, although many of those questions might be given a rational interpretation within the GPL framework, they as a whole give a definite impression of the daunting complexity of GPL licensing issues and the intricate problems of interacting between GPL and non-GPL software, complexity that many developers who use GPL grossly underestimate.

That also suggests, that "the GPL interpretation game" provides FSF with the power of negative marketing, the hammer that might be used anytime against a commercial or non-commercial entity developing software under GPL, if their behavior for some reason does not satisfy FSF. We will discuss one case of such "negative marketing attack" in the second chapter of the book (the case of Stallman's anti-KDE jihad).

From my point of view, at some point in the maturity of the GPLed program adopting a second license or switching to the alternative simpler license (for example BSDL) might save the author(s) the additional efforts required to understand and then navigate their way through the GPL licensing labyrinth. We will finish our discussion of this issue with the following pretty revealing quote from a GPL supporter, the quote that expresses a typical concern within the embedded Linux community [LinuxDevices2001]:

In a recent article in Integrated Communications Design, Mike Downing interviews Curt Schacker, vice president of corporate marketing for Wind River Systems. In the interview, Schacker expresses his "fear" that legal ambiguity surrounding the GPL "is impeding development in the embedded open-source arena." In Schacker's hypothetical scenario, a company making Ethernet switches uses Linux for the platform and chooses not to release their code under the GPL, because it represents the bulk of their product's core technology.

Shacker fears that because the GPL has not been tested in court, this company's project may be in jeopardy. He says, "Can you imagine a court case some day that determines that all of the software you've developed falls under the GPL, and is now in the public domain?"

FUD? or a legitimate concern?

While some have jumped to the conclusion that Schacker is cynically spreading FUD ("Fear, Uncertainty, and Doubt") about a technology (Linux) and development model (open source) that poses a threat to his company, I prefer to think that he is genuinely concerned about the welfare of users of Linux in embedded applications.

1.6.2 Fuzziness as an important social property of GPL

Unfortunately, you will not find definitive answers to the concerns of, say, embedded Linux community on the FSF site (at least at the time of the writing of this chapter). As I mentioned the quality and quantity of material provided on the FSF web site (www.gnu.org) for resolution of developers GPL-related problems is rather poor:

• Most typical cases of GPL licensing problems that can be found by using an Internet search engine (see above) are simply ignored.
• Bibliography on the subject as well as relevant legal references are completely missing.
• Available materials looks more like a political party platform, than an attempt to help users of GPL to resolve legitimate concerns about the license.

Most materials are pretty generic and do not address specific issues; they can be classified as philosophical essays (often authored by Richard Stallman) that promote Stallmanism and are detached from a reality. Some pages contain a high dose of moral judgments (especially related to the concepts of "free" and "non-free"). The impression one gets from reading those pages is that GPL is a flawless choice for software developers; if incompatibility or other problem arise, it's the other side that needs to adapt, for example to change the license; the idea of "peaceful co-existence" of various licenses in a single product is pretty foreign to FSF.

Along those lines FSF created a special terminology (often called "GNU-speak") that redefines the meaning of existing words like "free software" (FSF provides a definition of the term), and introduces a new word "copyleft" (also with the definition). Some pages demonstrate a real artistry in playing with the term "copyleft": "real copyleft" (GPL), "strong copyleft" (GPL), "not a strong copyleft" (whatever) "non-copyleft" (a bad thing) and such pearls as "simple, permissive non-copyleft free software license" or "a free software license, partially copyleft but not really" [FSF1999b].

Another related observation is that FSF never managed to provide a point-by-point answer to Microsoft's questions about GPL[Microsoft2000a], which were a rather harsh critique of the license, and as such represent an implicit threat to any developer that uses GPL, and thus should not be taken lightly.

Those observations create a definite impression that FSF has some reservations in exploring the depth of real or potential problems with the foundation on which it was built, and deliberately prefers to maintain some level of fuzziness. I think that this is because they view themselves as a political organization and as such the last thing that they want is to face the risk of undermining the political platform (Stallmanism) on which the organization was built. That suggests that the substantial level of fuzziness is not an accidental, but is an important and lasting social property of the GPL that developers should be aware of.

Historically, it did not do much harm to the popularity of the license and most problems with GPL surfaced only during the last three years, the period when many free/open source projects reached maturity. That further supports our arguments that such a license represents primarily a social contract. For example, the site Linux in Business provides an impressive list of businesses, governments and charities that use GPLed software in their day-to-day operations. I doubt that any government in any part of the globe would like to be associated with writings of the Proudon and Kropotkin. The funny thing is that the list even contains one law firm, but the link is now defunct.

At the same time this fuzziness does not always keeps developers, which are using GPL, happy. Of recent interest is the fact of the drastic precautions that Linus Torvalds took when he learned about the possibility of licensing the kernel under a license different from v.2 (which is implied in the pretty innocently sounding phrase "version 2 or any later versions",  in the GPL 2.0 text). As we discussed above he explicitly stated that he wanted the kernel to be licensed at v2 and not "any later version," because, while he liked the GPL v2, he didn't trust the FSF not to go haywire with future releases.

As a reaction to the problem of GPL complexity that we discussed above, there is now a commercial tool "which interviews developers to help uncover any conflicts with the GPL" was developed by Lineo[Coleman2001]. The toolset, which can be considered to be a slap in the face of FSF, probably went down with the Lineo, but still is an obvious allusion to the commercial software license compliance tools and the efforts of the Software Alliance to fight software piracy. It is difficult not assume that "extremes meet" after reading about the fact that the tool consisted of three parts: the Code Review Wizard, The Library Check, and the License Report Wizard. There is something troubling and deeply ironical in the fact of the existence of a commercial software that measures the level of GPL compliance. As Chris Coleman wrote[Coleman2001]:

Fear, uncertainty, and doubt currently surround the GPL (GNU General Public License) in the eyes of most IT managers. They wonder whether it will infect their software and require them to expose their intellectual property to the world. They worry that trade secrets will be exposed and allow their competition an unfair advantage over them.

Nowhere are these fears more real than in the embedded systems market. With software so tightly integrated into the design of the hardware, most vendors want to reveal as little as possible to the public, in order to maintain their competitive advantage.

This article gives a quick look at the Lineo Embedix GPL Compliance Toolset, which interviews developers to help uncover any conflicts with the GPL. The toolset currently exists only as an add-on to the Embedix software developer kit, and costs around $3,000.

An interesting argument in favor of BSDL as a way to simplify the number of issues involved for both developers and users for a mature stage of the development of the free/open software project was presented in LWN Interview by Bruce Momjian [Momajian2001] the leading developer of PostgreSQL:

CL: As you have mentioned, PostgreSQL is distributed under BSD license, not GPL, which theoretically means that Great Bridge can take the software and make a proprietary version of it. Do you have such a plan?

BM: Great Bridge is a strong believer in open source. They have stated very clearly that they would never develop proprietary software or closed software. Everything that they do, all the code that they do will be open source. Even, I believe, the manuals that come with Postgres will be available on the Internet, in PDF, for example.

Great Bridge is not interested in generating revenue from software. They wish to generate the revenue from support. We've clearly decided that we do not want to close off, or try to defeat open source. To do anything that would be proprietary would be counted like trying to compete with Oracle, you can't do that.

We believe that we are going to be successful because we are open source. Trying to do closed sourcing anything with Postgres would not be counted as the way we think we are going to succeed. The BSD license allows this to happen. But we honestly believe that if somebody goes proprietary with the product, then eventually they will see the light and will open source their software.

So, instead of using the GPL and requiring them to go through all the effort of understanding the GPL and require that before they do anything, we say "Fine, go ahead, go try and do it," because all the software manufacturers at this point are moving toward open source model and we do not fear somehow a company is going to come along and do the proprietary version. We just can't imagine why they would want to do it.

That quote finishes our discussion of the relative merits BSDL vs. GPL from the point of view of license simplicity.

GPL and open standarts

Interaction of GPLed programs and open standards is another complex issue that is never mentioned on FSF WEB site. There too issues here:

• The influence that GPL programs play on Internet

• The influence of GPLed microcosm on open standards process.

I find it amazing that some Linux enthusiasts are very dogmatic abut GPL and do not want consider other options. there is some circumstantial evidence that linux might be better off using BSD or BSD-style license. And this is not a matter of agreeing or disagreeing with Microsoft. 

Internet and GPL programs

I would like to start the discussion fro a pretty telling comment for the news item in Linux today called InfoWorld Don't Fear the GPL

People tend to forget the landscape in 1993-1995. AOL was coming on strong. People had barely heard of the Internet. OS/2 had some TCP/IP support in it and I believe WARP did include a browser, but OS/2 was not selling. Netscape was just being born out of the NSCA funded work. They wouldn't have been born with the NSCA work being GPL'd. Microsoft was busy putting the finishing touches on Win95. Win95 did not include Internet. It had the proprietary MSN as a counter to AOL's strength and momentum at the time. Only after Microsoft saw the success of Netscape and saw that people were actually buying OS/2 for its Internet capabilities, and it saw AOL opening up limited Internet connectivity in its system, did Microsoft decide to offer the Plus pack that included Mosaic (renamed IE). Live in your dream world, but IBM wouldn't have put Internet capabilities into OS/2, Netscape wouldn't have been born, AOL wouldn't have started to include some Internet content, and Microsoft would still be promoting their proprietary MSN, if the Internet had been GPL'd. Read Bill's comments on the time, they are quite interesting. He totally missed the boat and had to swim up-current to catch it in the first place.

Effect of GPLed programs on open standards development

Even taking into account a positive role that Linux played as an alternative to Microsoft OSes on Intel, the effects of Linux on open source standards are open to discussion. The key component of "open" world is not GPL software, its open standards. Development of these require research and cost a lot of money. During all ten year of its existence FSF did not contribute anything significant to the open standards (although at some point it was a minor player in C standardization and POSIX utilities). 

Acknowledgements

The author wishes to thank David Johnson and Ted Mittelstaedt for the comments on the v. 0.95 of draft of this chapter.

Summary

Programming is like mathematics and it favors young developers. I think that the famous quote of mathematician G. H. Hardy "No mathematician should ever allow himself to forget that mathematics, more than any other art or science, is a young man's game"[Hardy1941] is perfectly applicable to system programming. Given the average political tendencies of college students, who seem to form the largest part of the free/open software movement, I suspect that they can greatly benefit from learning about the errors and missteps made by the previous generation of programmers, including the GPL-usage problems that were discussed above. I believe that the following are the most important ideas of this chapter:

• The growth of the importance of free/open software development signified the creation of a "programming intelligentsia": a social stratum of programmers who value programming as a social activity and were ready to advance their own technological and social agenda in this area. Developers who prefer BSDL and developers who prefer GPL are just different subgroups of the programming intelligentsia as a social group. I also think that the programming intelligentsia can learn much from the lessons of the Russian intelligentsia's support of radical social ideas. In this sense the academic underpinnings and the adherence to Academic ethics, not intelligentsia extremism is the vital thing that needs to be nourished.

 
• Both BSD and GPL are connected with some underlying philosophy; in the case of GPL, this is the Stallmanism that partially contradicts requirements of Academic ethics. While making GPL appealing as any left populism, it also means that GPL has a rather eclectic and shaky theoretical foundation that suffers from the inherent problem of "where Anarchism actually stops". The latter is and always will be the source of constant internal contradiction and frictions inside the "GPL camp". GPL problems connected with its philosophical foundation include but are not limited to:
   
  • In the modern environment the line between software and hardware is often fuzzy (for example in the Transmeta chip) and rejecting proprietary software without rejecting proprietary hardware means drawing a rather arbitrary line between two as "GPL and embedded Linux" discussions had shown.
  • The absence of the culture of acknowledgement of previous work is not accidental but is an intrinsic property of GPL which contradicts academic ethics. GPL is an acceptable license if and only if the author(s) consciously or intuitively stays on the grounds of academic ethics and defy the spirit of the license by explicit acknowledgement of the contribution of others in his programming product, including listing them in the copyright statement for the product. From this point of view transferring rights to FSF is a questionable idea, that, as the development of the Linux kernel had shown, can be avoided within the GPL framework. The willingness of Linus Torvalds to acknowledge the contributions of others by name in public ways was very important in ensuring the success of Linux. The presence of the public acknowledgment of efforts meant that there was an implicit reward for submitting quality code and ideas. It constitutes a level of appreciation that programmers need and should fight for.

  All-in-all I would disagree with Stallmanism as a philosophy, but I it's important to admit that Stallmanism historically did play a valuable gadfly role. While several ideas of Stallmanism are very wrong, that did not prevented them from hitting pay dirt.
   

• One can view any license including BSDL and GPL as a social contract (or even a set of the rules that regulate this social process) which behaves differently depending on the stage of the development of the programming product. The other possibility is to view the license as some algorithm and measure its complexity by some metric. From both points of view, a widely held notion that GPL is a simple license is an urban myth.
   
• Most free/open source developers do not think about those licenses in purely legal terms. They usually view them as some kind of social framework or developer league that a particular developer adopts. In this sense the primary social role of a free/open software license might be in establishing of "the rules of the game" ("rules of free/open software development league"). At the same time this social contract view means that it is not that easy to change the license because the author did not adopt just a license, but a whole social environment for the development of the program. Changing that environment is not that easy and for a really successful product might looks similar to the situation in Eagle's "Hotel California" and requires some courage and proper timing.
   
• Due to the complexity of the GPL its interpretation became a permanent intellectual game of a certain part of the "programming intelligentsia." Moreover completely along the lines of our "programming intelligentsia" view of the free/open developers community, the interpretation of GPL became a "hot kitchen topic" that mistakenly but widely considered an important and worthwhile social activity that brings most active participants additional social status in the most radical part of the programming intelligentsia. 
   
• A substantial level of fuzziness is not accidental, but should be considered an important social property of the GPL. From the quality and quantity of materials about GPL on the FSF web site it is difficult not to come to the conclusion that FSF is not very interested in addressing the complex social and legal issues that arise from GPL use. Software developers that use or want to use GPL might benefit from an awareness of this property of the license. The process of the clarification of GPL is an unpredictable never-ending social process with one primary (FSF) and several minor players. Nuances of the GPL interpretation can be used as a weapon in conflicts between groups of developers and as an instrument of ensuring the importance of FSF. The author suggested that the acceptance of FSF as a "Supreme GPL Clarification Commission" can serve as a litmus test of belonging to the "software anarchists" camp, and that the power of negative marketing might be the most potent FSF weapon in GPL infringements cases.

 
• A simple license that most developers consider fair and are ready to comply with voluntarily might be superior on many counts to a complex that tries to enforce "free sharing" but requires periodic "clarification letters." I would suggest that it is impossible to for any successful GPL-ed product to avoid "GPL clarification mess" and this activity can be very costly for the organization and distract from the development efforts. MySQL saga (that included a litigation round) is one good example of such a mess.

All-in-all what is good about the GPL is that it is an open source license that due to its politicized nature provide software developers with the sense of belonging to a movement. For commercial software developers GPL also can provide an escape path from the corporate software development atmosphere without losing paycheck. What is bad is the fact that it is complex, fuzzy and restrictive with regards to derivatives. One only has to look at the history of the Internet to see that the public would be best served by open source licensing, but not necessarily the GPL. And if Internet software were GPLed it might well be possible that we would work in MSN those days.

In the next chapter we will try to address the possibility of the "kidnapping" of a free/open software project by some "evil" commercial company in the context of the level of protection that BSDL and GPL provide to developers.

Last modified: March 12, 2019