Softpanorama Bulletin
Vol 13, No.02 (April, 2001)

Prev | Contents | Next

Chapter 2: Social Dynamics of Free Software Licenses in the Context of the Program Life Cycle

Dr. Nikolai Bezroukov Draft (version 0.97)

Prev | Contents  | Next

Copyright 2000-2001, Nikolai Bezroukov. This is a copyrighted unpublished work. All rights reserved.

Contents

Abstract

Introduction

2.1. BSD, GPL and the Author IP rights

2.2 Stagnation vs.  "Kidnapping paranoia" in the context of free/open source development life cycle

• 2.2.1 Commercial Forking Fear and GPL

• 2.2.2. Case study No.1: Microsoft's use of Kerberos code

• 2.2.3. Case study No. 2: Scripting languages and GPL

• 2.2.4. Case study No. 4: Apache and GPL

2.3 GPL and innovation -- another side of kidnapping paranoia

2.4. GPL and standards, Artistic License as a Compromise Between BSD and GPL

2.5. The Influence of Social Environment on Attractiveness of GPL and BSDL

2.6. GPL as "The Incompatible License"

2,6.1. GPL restrictions on the code reuse

2.6.2. The hostility to other licenses and the dander of the "GPL Jihad"

Conclusions

Webliography (has it's own table of content)

Abstract

This is the second part of the paper "BSD vs. GPL". Properties of the GPL are compared with the properties of the BSD license (BSDL) not statically as in many previous publications on the topic, but in the context of the life cycle of the program. The latter presuppose stages like youth, maturity, decay and abandonment.  The author argues that different licenses might be beneficial in the different stages of software development and that the free/open software developers might benefit from changing the license as their product mature. For example, there is nothing wring with using  GPL as the first license. Later as the product matures, the developer might benefit from replacing it with BSDL, or adopting dual licensing.

Also the author tried to show that BSD style license give freedom, but little security, while GPL limits freedom, with the illusion of improving the security ("kidnapping protection illusion"). Wasn't it one of the founding fathers of the US who thought that those who are willing to give up a liberty for security deserve neither?

Moreover the author argues that the popularly of the GPL can be explained by its subtle appeal to good old greed:  "I just don't like the thought of someone taking my hard work and making money off of it -- I want to reserve that privilege for myself, thank you."  while slightly perverted form of greed this "GPLed greed" is still greed mixed with the fear that a powerful player can crash small venture anytime. The fact is that while GPL pretends to provide some ways to restrict others from profiting from your work, all commercial Linux distributors do exactly what GPL wants to prohibit -- they make money off of the work of enthusiasts. That means that there is an interesting internal contradiction between "freedom" and "profit" motives in GPL. In a way GPL is step mach from regular commercial software development  as it promotes the law of jungles were the biggest and the most fearsome beast gets all he wants at the expense of smaller fish. Re-phasing French quote that socialists who became ministers in the government are no longer socialists we can say that "GPL revolutionaries who became owners of a business are neither revolutionaries nor GPL lovers"

Introduction

In this  chapter we will try to answer the question "How advantages of BSDL and  GPL  demonstrate itself of various stages of the free/open source project life cycle". Thus we will analyze those two licenses not by comparing static properties of licenses (the license A said this and the license B said that type of analyses) like most previous works do, but in the dynamic context of the program life cycle, using existing projects as a guinea pigs for the real life behavior of respective licenses.  Also dynamic, generational approach means that software itself is not eternal and has distinct life stages like youth, maturity, decay and abandonment.

The second, related and much less studied question  is "Can a developer of the programming product that reached a certain stage of development benefit from changing/amending the license? ". After all  the freedom to offer your work to the world on the terms that you choose, and for the recipients to accept or reject those terms that is a fundamental freedom we all fight for.  In no way a software author is an indented servant of some corporation or association. Programming is often considered to be an art and as an artist the creator of software has some inalienable rights. My attention to the individual developer rights is not accidental: most open source project are leaded by single developer with huge personal stakes in the success. Of the 100,000-plus projects on SourceForge (as of 2005), 73% have a single active developer. Close to 85% are no longer actively maintained/developed. Moreover 80% have fewer than 10 participants [Enterprise Unix Roundup Plateau or Bubble]. Contrary to Raymondism, open source programming is a pretty lonely art...

Therefore, there is no reason to consider the license to be a holy cow, the article of faith ("if you change a word of this text you shall be excommunicated"), the developer need to assert his own interests and resist attempt to hole him into the requirements imposed by some software cult.  The license probably should be considered as a instrument or even a component of the programming product and as the product changes the license can (and probably even should) be debugged, modified or even replaced with the another license, more suitable to the new environment.  

The latter question will be touched on, but will be explored more fully in the third part of the paper. In this paper we will discuss a simplified version of this question that can be formulated as following:  "If we assume that free/open software product grow through several stages of development and eventually die is there any evidence that for early stages of development GPL is somewhat more suitable than BSDL, and for mature stages BSDL is somewhat preferable to GPL ? "

An approach that we would try to promote in this part of the paper is that while both BSD and GPL are two major free/open software licenses, it's might be more beneficial to use GPL as the first "temporary license" for the early stages of the development of the project. Later as the product matures the developer might benefit from replacing it with the BSD license or commercializing the product.

That does not mean that GPL ceases to be one of the major free/open software licenses. That just means that developers can benefit from understanding the limits of applicability for GPL is the current social environment.  All-in-all I still consider GPL as the second major free/open license and the major achievement of Dr. Richard Stallman. Despite all GPL shortcomings (and shortcomings are logical continuations of strong points), GPL played a major role in the Unix renaissance that we experienced at the end of the last century and that is still far from the end.

The important thing to understand in the context of the BSDL vs. GPL  debate is that the success of GPL can be considered a reaction to the fact that fair use provisions deteriorated in common software licenses to an unacceptable level. To this extent I would call GPL  to be a Microsoft-sponsored license because GPL attractiveness is connected with the existence of the dominant player. Moreover its popularity greatly increases due to the attempts to find a alternative to Microsoft by the broad social forces that oppose Microsoft domination of the Intel-based computers (Wintel monopoly). Although the connection of open source movement to Microsoft was discussed in my earlier paper [Bezroukov99a], it's relevance to GPL popularity was not.

The main point that I stress is that the mere Microsoft existence has created a social need for an aggressive pro-user license and that need was largely fulfilled by GPL. That's why we need to understand that the radical part of programming intelligentsia that is associated with GPL is an important component of the social forces that try to keep the dominant commercial software company in check.

A very interesting and positive feature of GPL is that by the mere virtue of being the most radical and controversial of software licenses, it stimulated discussion about the general principles of free/open software licensing and thus contributed to the development of all relates areas of knowledge including but not limited to the intellectual property law.  It also influence proprietary software developers. For example, Microsoft also realized that there is something it can learn from open source. More free sharing of source code with some customers can provide for the company important benefits with minimal risks, especially if the spectrum of customers that get such an access is limited to major software development companies, large integrators and universities.

Along with those positive features we will discuss some negative properties of GPL. The main negative aspect of  GPL is closely connected with the philosophical doctrine on which it is based. The latter completely disregard of the original author intellectual property (IP) rights. But along with this principal shortcoming there are also several other unexpected negative properties of  GPL that are often overlooked by developers but can significantly complicate development of the product that reached or is close to the mature stage. One such  unexpected but important social property of GPL is that developers of important for community products that for some reason does not belong to the "GPL mainstream thinking" are often attacked with what we call "negative marketing attacks" (see  discussion of The dander of the "GPL Jihad"  below). Recent Microsoft questions about the problems of using GPL in government sponsored projects is yet another new phenomenon that requires careful investigation. It raised spectrum of question about sponsored software licensing and now even the interaction of GPL with university funded research is far from being clear. I think that FSF silence (aside from pure propagandistic counterattacks) about those questions is somewhat alarming.

2.1. BSD, GPL and the Author IP Rights 

BSD license in its original variant (with advertising clause) can be considered as a codification of a venerable academic tradition. Other works can be used freely by a\other researchers as long as proper credit was given for the original work.  By providing proper respect you can stand on the shoulders on the giants.  The history of science is a proof that this idea of  "proper credit" is a very important and efficient social mechanism. 

But GPL advocates a completely different approach, the approach based of its philosophical foundation that was discussed in the first part of the paper.

Despite all nice phraseology about cooperation, in certain aspects GPL explicitly promote the "right of the strongest" or "the law of jungle". The key feature of GPL is protection of  the right to redistribute both original work and create and distribute derived works as long as the license is preserved. That means that  freeloaders and the authors/contributors are treated equally under the GPL terms. In other words by promoting the equality of all users GPL implicitly denies the original author IP rights. Notice that there is no attempt in the GPL to differentiate "users" into different classes. Yes, the original author still can change the license but as we will discuss later this is not that easy.

This "the law of jungle" property means that at any moment the tables can be turned against the original author -- cases of hijacking (or as they are called "forced forking") are well known in GPL world (including several ideologically motivated, but unsuccessful attempts led by RMS himself). The typical precondition of such fork is that development slowed down to the level that is unacceptable to users and other subgroup of developers that feel capable to continue development alone. For example, this was the case in both gcc and XEMACS forks.

This feature of GPL  is completely foreign to European civil tradition where the author of an innovative work always has some moral rights by the virtue of his creativity. But this important moral right is denied by GPL. RMS himself can serve as a perfect example here. Historically he lost and never managed to regain the control of the development of his two major products: Emacs and GCC (egcc project was eventually renamed gcc and brought back under the FSF umbrella, but still this is "the final solution" of the problem that was essentially equivalent to the elimination of the original gcc tree). In both cases RMS not only lost control of the future direction of the development of the product, but he was also explicitly dismissed as the leading developer by a more powerful and more agile team. It was proved that the user community can easily change loyalty to the alternative developer if the latter is able to produce and/or enhance the product quicker than the original developer.

I also feel that GPL discriminates against the original author in an additional way, although this was not the case in Linux.  As it lacks 'proper credit' requirement, it supports pure "lifting" of some GPLed and BSD code as well as advantages to the most powerful player (that's why cases of forking of project in which the original developer lost interest are so common -- not continuation of development but forking with obvious "vanity fair" component).  The latter provides financial advantages to the first entity which commercialize GPL product (the right of the first night as for new contributions).  Historically this kind of advantages were enjoyed in case of Cygnus and gcc, as well as Red Hat and Linux.  Moreover, due to unique historical conditions of Internet bubble, in case of Linux the ability to commercialize and financially benefit from the GPLed product distribution led to creation of a caste of "Linux Mandarins", people who became multimillionaires riding huge Linux-hyped IPOs for their companies. The real situation reminds Orwell's "all pigs are equal but some pigs are more equal then others". In some cases (Larry Augustine, Robert Yong) Linux Mandarins benefited on the scale that makes any Microsoft commercial software developer envy.  As Linus Torvalds aptly put it: [COMPUTER NEWS DAILY - Linux Honchos Gather for Group Gripe]

`Science is not a product,'' said Torvalds, becoming a little heated despite wearing shorts and sandals. ``Everyone says that working together is good. But somewhere, in their dark, little minds, they say, `I want to do this alone. I want to make millions.' ''

It seemed as if all eyes turned to the panel's moderator, Larry Augustine, the VA Linux chief executive officer whose claim to fame is riding a huge Linux-hyped IPO into the ground while profiting big time in the process.

Augustine smiled wanly and tried to steer the conversation back to some more Microsoft bashing. And so it went.

This commercialization potential for the first strong commercial taker/hyper might be implicit but very important and interesting property of GPL which may deserve further study.

Another side of this potential is that for mature, ready for the commercialization projects that use GPL the original author seldom fully controls the project codebase, so the project is somewhat "anonimized" by this very property: there is no  single person, who can change the license. Still the original developer usually enjoys some moral privileges and as long as his status and level of contribution is high he can, for example, provide a specific license to a commercial company that is interested in the product. The latter would help for the original developer to receive the lion share of financial benefits from the software that would be more along the line of European notion about immanent right of the author.  Here is one pretty telling quote about Stallman's April 2001 London appearance on the CODE  (Collaboration and Ownership in the Digital Environment) conference as it was reported by the Register [Register2001]

If there was a problem it was that Stallman takes a totally American view of copyright, seeing it as a set of rules to encourage people to share the products of creativity. He does not discuss - or seem particularly aware of - the European approach in which authors have moral rights which transcend economic factors.

Still despite the problems noted above, GPL may serve very well as an instrument of marketing for an individual developer if he fully controls the codebase: a developer can test waters with GPL version and if there a substantial commercial interest in the product emerge, change his strategy by either moving in the subsequent versions of the product into the commercial domain (may not be easy due to potential negative marketing attacks) or to grant interested commercial parties additional  licenses to market and sell the product and support for it (this path when GPL co-exists with other licenses proved to be more fruitful; it was pioneered by Perl). Switching to dual licensing is probably the most smooth way to get rid of GPL "straitjacket" when the product is ripe for commercialization.  The history of X86 had shown that if alternatives are available changing the current license carry certain risks and should be avoided. In a way, GPL is a "sticky" license.

GPL also has other subtle aspect which developers should be aware of. It is important to understand that GPL goes further than protection of user interests. Its "any later version" part explicitly disregards the author intellectual property rights by virtue of the ability of stealth switching to a newer version (for example from version 2 to version 3).  Here is a pretty telling quote from the letter of glib maintainer Ulrich Drepper  [glibc 2.2.4 Release Notes]:

This part has a morale, too, and it is almost the same: don't trust this person.  Read the licenses carefully and rip out parts which give Stallman any possibility to influence your future.  Phrases like   [...] GNU Lesser General Public License as published by the Free  Software Foundation; either version 2.1 of the License, or (at your option) any later version just invites him to screw you when it pleases him.  Rip out the "any later version" part and make your own decisions when to use a different license since otherwise he can potentially do you or your work harm. In case you are interested why the SC could make this decision I'll give a bit more background.  When this SC idea came up I wanted to fork glibc (out of Stallman's control) or resign from any work. The former was not welcome this it was feared to cause fragmentation. I didn't agree but if nobody would use a fork it's of no use. There also wasn't much interest in me resigning so we ended up with the SC arrangement where the SC does nothing except the things I am not doing myself at all: handling political issues. All technical discussions happens as before on the mailing list of the core developers and I reserve the right of the final decision. The LGPL 2.1 issue was declared political and therefore in scope of the SC. I didn't feel this was reason enough to leave the project for good so I tolerated the changes.  Especially since I didn't realize the mistake with the wording of the copyright statements which allow applying later license versions before. I cannot see this repeating, though.  Despite what Stallman believes, maintaining a GNU project is NOT a privilege.  It's a burden, and the bigger the project the bigger the burden.  I have no interest to allow somebody else to tell me what to do and not to do if this is part of my free time.  There are plenty of others interesting things to do and I'll immediately walk away from glibc if I see a situation like this coming up again.  I will always be able to fix my own system (and if the company I work for wants it, their systems).

Another reality of GPL development is that the original author can be simply dismissed by forces outside his control if his/her component are just part of the larger product. For example, an author of GPLed Linux drivers is completely unprotected from hijacking of his project if he has problems with Linus Torvalds or do not line up to some of Linus' recommendations.

Re:hmm (Score:2) by Arandir (arandir-at-usermode-dot-org) on Wednesday June 06, @01:33PM EST (#205) (User #19206 Info) http://www.usermode.org/

Oh, I understand the issues perfectly. Understanding exactly what the GPL is and how it works does not imply complete approval of it. The GPL is designed to create "a community to cooperate on the commons of software" (http://www.gnu.org/philosophy/apsl.html). Ignoring the real history of village commons (owned solely by a manorial noble and rented out to villagers in exchange for serfdom), there is some valuable insights to be gained from this poor analogy. GPL software is a commons in a village. Only the serfs of the village have access to the commons. All else can bugger off. Before you can utilize the commons for your own production, you must first swear fealty to the lord. But software released under unrestricted licenses, like the BSD, MIT or Apache, is like a market square in a town. Anybody can make use of it, regardless of their citizenship. And no matter what a travelers sells in the square, it will still be available to everyone else. I license my own code under the BSD license. Over the past year, three other independent projects have decided to utilize portions of my code in their own software. Two of these are GPLd projects, and one is a BSDd project. If I had used the GPL instead, then one third of these projects would have had to reinvent the wheel.

With this introductory notes we are ready for exploring the key (and as we will show by-and-large fake) attraction of GPL: protection from "kidnapping". Let discuss the possibility of "kidnapping" the a free/open software product by some "evil" commercial company.

2.2. Stagnation vs. "Kidnapping paranoia"
 in the context of free/open source development life cycle

what motivates an open source programmer to choose one approach
 over another may have more to do with fear and mistrust than with freedom.

You shall not belong to anybody
A famous line from the final scene in the classic
Russian play "Bezpredannitsa"  (Cruel Romance) 
where the beautiful and intelligent heroin is killed 
by her mediocre and jealous husband.

 "Those who would give up essential liberty
for temporary safety deserve neither liberty nor safety."

 

A popular claim against from GPL supporters is that BSD-style licenses don't help you keep software free and that there is constant danger that your work might become proprietary and part of a larger commercial package. I would call this popular argument "kidnapping paranoia" and for the purpose of this paper we assume that this newly introduced term means that the major advantage of GPL vs. BSD is that the latter permits "kidnapping" of the free product by "evil" commercial software developers while the former does not. 

This is an important argument and some authors [Leibovitch2001a] correctly state that "an open source programmer to choose one approach over another may have more to do with fear and mistrust than with freedom"  while simulationiusly observing that "GPL creator Richard Stallman's appeals to freedom, that has primarily driven the popularity of the GPL." In reality the key motivation for adoption of GPL by many developers might be fear and mistrust, not the desire for freedom. But the appeal to freedom provides a perfect rationalization for the underlying fear and mistrust and thus greatly enhanced the attractiveness of GPL:

It seems that what motivates an open source programmer to choose one approach over another may have more to do with fear and mistrust than with freedom.

...It is this fear, I believe, far more than GPL creator Richard Stallman's appeals to freedom, that has primarily driven the popularity of the GPL.

Just because someone uses the GPL doesn't mean they buy into the dogma of Stallman and his Free Software Foundation. Not everyone using or creating GPL code believes in the necessity of ending all use and development of proprietary software. Many appear to use the GPL simply as a way to balance the playing field for certain core elements of computer software. (Of course, opinions vary wildly on what constitutes the "core," but that's a different story.)

I would argue that GPL wording bears strong resemblance to the classic case of implicit/suppressed desire of  revenge along the lines "you should not belong to anybody", as exemplified by Cruel Romance, written by Ostrovski long before computers were invented.  Historically this line of thinking is connected with Stallman's inability to reuse Gosling's codebase of Emacs [Bezroukov2002a]  along with suppressed feeling that he cannot compete with Gosling as a developer.  Sometimes the justification of GPL adoption reads like it was written by Prince Kropotkin, like in this Stallman's quote: [The X Windows Trap ]

Non-copylefted software is vulnerable from all directions; it lets anyone make a non-free version dominant, if he will invest sufficient resources to add significantly important features using proprietary code. Users who choose software based on technical characteristics, rather than on freedom, could easily be lured to the non-free version for short-term convenience.

Sometimes those arguments are spiced by explicit mentioning of  the "kidnapping"  danger (the quote below was taken from “Microsoft: Stop Attacking Linux" by Esko Woudenberg):

"The GPL license does not allow proprietary companies to 'kidnap' open source/free software and turn it to their own uses without making their changes freely available."

It can be argued that software cannot be kidnapped. Free version still exists and can be used and developed without any limitations. What can be gone is popularity (and infrastructure for the project) so this motivation looks like plain vanilla jealousy.  Here is how Wikipedia defines the latter:

Jealousy typically refers to the thoughts, feelings, and behaviors that occur when a person believes a valued relationship is being threatened by a rival. This rival may or may not know that he or she is perceived as a threat.

According to many authors, jealousy is a complex emotion, meaning that it is not possible to provide a simple and immediate description of it, as it would be for “basic” emotions like joy or anger. A definition that expresses this character of complexity is “a cognitive elaboration of basic emotions” (Prinz, 2004, p. 93). This means that the experience of jealousy as felt by humans appears to be not merely sensory, showing some characters of rational elaboration and instinct. In addition, it is a common fact that the experience of jealousy can last much longer than the one of a basic emotion like anger, without losing its original intensity.

Some additional  variations of the same line of reasoning are listed below (all of them were taken from responses to a story on Linux Today [Maxtor picks Windows, dumps open source]),  but tons of similar postings can be found on Slashdot  or other Linux-related sites:

• "BSD can have developers of pure gold, but who cares? They slave away at their beloved OS only to see their code get ripped off. It's too bad, because BSD is good software. GPL is the way."
• "MS likes BSD since it allowed it to get the NT stack for nothing. And the BSD people rejoiced when Apple went to bed with them and began touting they would leap frog Linux. They will go to bed with MS in the same way they went to bed with Apple so I see no reason we should feel concerned by their misfortunes. And many of them hate Linux, just remember the T-shirt affair or when they made like throwing darts at Linus."
• "We also see a weak point of the BSD license. You can take the code but then you cut yourself of a bunch of very good developers (yes the BSD guys are good) and have to do the rest of the work yourself. You cannot release your code to get some contributions since your competitors will use it against you. With GPL you can take advantage of the free-project developer base since your competitors cannot take advantage of this fact. In fact you can end contributing to the same project than some of your competitors (like IBM and SGOI are doing for Linux) in a mutually beneficial cooperation (Linux developers, SGI, IBM) but detrimental to the "other" competitors: those who obstinate in a proprietary line or in a closed source one based on BSD. "
• "It is GPL who is business friendly on the long term."
• "Businesses that want to contribute to make the community's software more valuable will love the GPL. Businesses that want to make their proprietary software more valuable will love the BSD."

While most of the arguments in the quotes above just do not hold under more close scrutiny that does not make them less attractive as they convey powerful emotional element of fear of the loss to a more powerful rival, the emotion that strongly influence  human relationships since the beginning of civilization. Those feeling of "suppressed envy" and jealousy are perfectly understandable and all too human so it is important to stress that developers who adopt BSD license consciously or subconsciously occupy a higher moral ground in comparison with those who adopt GPL.  Linux Mandarins behavior during dot-com gold rush fever demonstrates that aspect of GPL vs. BSD debate quite convincingly.

But let's return to the historical examples. When evaluating historical examples we need to distinguish behavior of the BSD and GPL licenses on the early stage of  a program development and behaviors of those licenses on a mature stage. The level of protection provided by both BSDL and GPL fluctuates significantly depending on the level of maturity of the program. I would like remind that under a mature stage we will assume the stage with the following characteristics [Bezroukov 2002a]:

The product reaches most prospective users and codebase achieve some level of stability with all major features already implemented.  Some polishing is under way. This is famous version "post 3.0 stage". The important property of this stage is that 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 stabilize as becoming a new developer is quite difficult due to the size and the complexity of the codebase. Here we can think about FreeBSD, XEmacs, gcc, X Windows and some other products.  Often a mature program demonstrates some signs of aging. One of the common characteristics of aging software is growth of size of software without major increases of functionality ("fat").

I would argue that the kidnapping paranoia is stronger on early stages of program development. While in reality on early stage of program development the product is too raw and there is not much intellectual property that somebody can kidnap anyway, many developers psychologically are very worried about such a possibility. I cannot deny this feeling as I experienced it myself many times. This is a complex feeling and it is very strong and I suspect it is not limited to programmers: this is a part of general insecurity creative people experience in society.

But usually the reality is quite opposite of what developers are worried about -- if their creation is really innovative they will find tremendous difficulties in selling it to anybody. That's the common tragedy of really innovative approaches -- nobody understands them and nobody wants them. And paradoxically that might prevent stealing much more effectively than any license. Look at the story behind Google: they try to sell the search method they developed only to find out that nobody is really interested.  Look how Microsoft completely missed the rise of Web and emergence of http as a new dominant Internet protocol in 1994.  Look how IBM brass missed  virtualization (the technology they posses since 60th via VM/CMS) and give VMware complete freedom to capture the X86 virtualization market. Those examples can be continued ad infinitum.

The second factor is that in the early phases of the development cycle the speed of the development is pretty high and thus by itself provides an additional level of protection (some kind of bicycle-type stability), the level of protection that is quite independent of the license the developer(s) adopted.  The principal developer is still highly motivated, has new ideas and as such represents a formidable opponent to any hijacking attempts as codebase is still pretty raw.   As we will discuss in more detail later in this section maintaining a forked version in such conditions is both difficult and costly. Still I would agree that in this sense GPL provides some additional level of physiological comfort (that may be illusory like the positive effect of a placebo pill) in comparison with BSD in early stages of development. It is natural for a developer to see his project as the best of the breed and thus overestimate its attractiveness to other developers and the danger of stealing.  This psychological comfort is so important that I would agree that GPL has advantages over BSD in those stages: its really important that developer had high level of confidence that the program he/she is working on (and spending so much effort on) will not be stolen overnight, and then re-released as a profitable commercial product, somehow bringing the perpetrator millions of dollars. While realistically this chance is as remote as winning the New York lottery,  physiologically such a perspective is very worrisome.

But this advantages of GPL do not extend to the mature stage of the development of the project, were the original developer is no longer participating in the project and the danger of stagnation is greater  than the danger of hijacking. This change of the social environment should probably be reflected in the change of the license. for example in adopting dual licensing to benefit from the feedback of commercial developers.  This problem of stagnation has two major aspects:

1. First of all,  if we consider free/open programming as a form of the academic exchange of knowledge, then the critical question is "How essential to the open exchange of ideas is the notion that none of the participants is getting rich off the exchange?"
   
   I think that it is extremely important and like in science it is essential not to mix apples and oranges. Some lack of resources typical for academic environment (including low salaries) protects  the field from "make money fast" adventurists and charlatans (look at the dot-com bubble or subprime mess for  good examples) and help to maintain an academic freedom. Those developers who decided to commercialize their products should have a clear and unobstructed opportunity to move on to a different social sphere and play by the rules of commercial software developers.  So they need to enter the ring, fight and win or lose like everybody else. Their place can possibly filled with a new talented developers. If not, commercialization is still better than a dead product.  In no way they should be forced to sit between two chairs like so many GPL developers who tried to commercialize their software do.
    

   "How essential to the open exchange of ideas is the notion that none of the participants is getting rich off the exchange?"

   Making money is not very compatible with the free exchange of ideas in science and I doubt that situation in software development is different.  That's why open source developers are often as secretive (or even more secretive) as commercial developers about the algorithms they use. That's why they usually do not document any architectural aspects of their creations. In this case open source is just like assembler language code -- yes, the source is available, thank you, but, yes, it is pretty much useless without undue efforts to understand it (barrier of entry).  And believe me, tens of thousand lines of  undocumented C code are as close to assembler language or binary module as one can get ;-).
   
   So there are stages of development when a person should consciously strive for free exchange of ideas and there are stages when the same person can adopt an opposite approach trying to capitalize on his creation. There is some inherent integrity is switching to commercial development model: it is a honest and open declaration that the stage of open exchange of ideas is over and the person wants to benefit financially from his previous work. People are mortal. There is time to work for the benefit of humanity and there is time to earn a living and to secure a comfortable retirement. Also creativity is not something that is constant in human beings, especially in such complex and fast moving sphere as programming.

   There is some inherent integrity is switching to commercial development model: it is a honest and open declaration that the stage of open exchange of ideas is over and the person wants to benefit financially from his previous work. People are mortal. There is time to work for the benefit of humanity and there is time to earn a living and to secure a comfortable retirement. Also creativity is not something that is constant in human beings, especially in such complex and fast moving sphere as programming.

   That means that the availability of clean and clear alternative to the academic development via the commercialization is a very  important factor for the maintaining of the health of  the open source movement. In science blocking this path historically led to such negative factors as "academic empire building", "academic parasitism" (like the right of a senior person to put himself in the paper written by a junior associate) and Lysenkoism.   If we accept the analogy between free/open and academic development[Bezroukov99a], then it logical to assume that free/open programming development needs a freedom of commercialization of the product without the precondition to keep the source code open.
   
   In this sense one can argue that BSD provides an important edge over GPL, as it explicitly permits to move from free academic style development to commercial anytime and without any preconditions. And that possibility historically proved to be very fruitful as was demonstrated by the history of Sun (as well as to a lesser extent by BSDI). For example Sun, the company emerged as one of the results of Berkeley University Unix project, contributed back to the Unix world (including all free Linux distributions) such important innovations as NFS, RPC, NIC, PAM.  Linux developers cannot boast to possesses even half of this record. The question arise what the Sun creation beneficial to the society? And the answer is yes. On the other hand GPL tendency to block or obscure the commercialization path tends to create people who are sitting between two chairs and in one side like to talk about the importance of free/open software, but on the other try to limit the level of disclosure, exercise options and sell shares in the very company that produces this free/open software as fast as possible (as the track record of  multiple "Linux millionaires"  including Linus Torvalds proves so convincingly).  
    

2. If we assume that it is natural that free/open projects need to survive in quite severe conditions with constant lack of resources then as soon as the initial enthusiasm evaporated and the original developer gets some kind of recognition for the project and moves on, the project often balances of the brink of survival. That means that the danger of stagnation far outweighs the danger of "kidnapping". If we need to chose between abandoned program and commercial program, then the variant with the commercial program looks more attractive.  The mere existence of actively developed commercial program holds potential of revitalizing of an abandoned free version at some point. As for GPLed projects the danger of abandonment is probably the major danger as soon as the project loses the main developer. Often nobody wants to take his/her role. If you see a WEB page that was not updated for a year or so, most people suspect that the project is in trouble or is dead.
   
   That means that excessive defense against hijacking might lead to side effects that might be more dangerous for survival of the project, than mostly imaginary problem of "hijacking" of open source by a commercial entity.   Moreover "commercial developers" (programmers that are interested in the contributing to the project not only from the standpoint using it, but also reusing parts of codebase in their own commercial projects) are an important asset, not a liability for free/open software projects on mature stages of development and it may be wise to make steps in modifying licensing to attract them. It is the achievement of a critical mass of interested developers that is necessary for the survival of the free/open software in the long run. That means that exclusion of "commercially motivated developers" diminish chances of the project survival by the fact of diminishes the available pool of developers interested in the project.
   
   As a rule of thumb most GPLed projects that fails to achieve a critical (self-sustainable) mass in first three-five years are probably doomed, as the original developer at this point lost most of his/her initial enthusiasm to the extent that development either slows down to a crawl or is abandoned (Linux kernel is a notable exclusion from this rule: Linus Torvalds remains the project leader for more then ten years[Bezroukov2001b], a pretty rate case; but still it is true that both his level of enthusiasm and activity in coding are dropped considerably). At the same time attempts to attract developers when the project had reached a certain level of maturity is more difficult than on early stages: at this point the codebase is more complex and the barrier of entry is much higher (the effect that I called "self-closing of an open source project" in one of my earlier papers).

We will discuss the second danger a little bit later. Now let's concentrate on the assessment of the real level of the danger of commercial forking.

2.2.1 Commercial Forking Fear and GPL

If one decided to "hijacks" a free/open product, then it is evident that one feels that product stagnated and is an easy grab or one sees important shortcomings in existing product that can be eliminated by commercializing the product and still preserving the core of the codebase. The latter means the belief that eliminating architectural shortcoming and/or enhancing the product make the latter so attractive that people are willing to pay for at least for support of the new product. That presuppose that the product can provide a substantial value on the marketplace in comparison with the alternatives, the value that is somehow absent or limited in the free version with which the product will inevitably compete. 

So the person who chose this path will be squeezed between a free version which is not going away (and can be revitalized by the mere fact of creation of commercialized version with paid support) and between established commercial competitors with which free version used to compete. It's looks like fighting with Chinese on one front and with Germans on the other. Not a very enviable position. 

Realistically there are very few open source projects that enjoy wide commercial adoption. Still if such decision was made,  then in order to provide a commercial value the first thing to do is to try to improve the product by making major architectural improvements and changes that correct some of the missteps and architectural blunders committed by open source developers.  And this is not difficult as most open source products suffer from premature "fossilization" of internal architecture. 

It's not difficult to understand why forking of open source project into a commercial is a mixed blessing. Even in the best case the problem of synchronizing two large source trees is far from trivial, so one needs to rely more on his own development skills that for the possibility of "lifting" code from future version of initial open source branch. On the other sense blind borrowing does not make much sense for the developer who is a higher level system architect then those who created the original open source version:  why repeat architectural blunders that are present in existing version ?  Why inherit all this entropy that exists of codebase of any large and old open source project ?  Anybody who worked on large software projects with several branches (for example multiplatform development of a commercial operating system like Solaris) can testify that this is a huge problem and a real tar pit for the developers. The problem with such branches is that every time there is an important fix or a refinement of the underling algorithms in one branch, you cannot immediately take advantage of that fix or refinement in the another.

Even forking of open source project into another open source project is very problematic. The first question to answer is who is the stronger and have more resorces. Law of jungle apply here(The myth of open-source forking ):

Forking is frequently touted as one of the principal benefits of using open source. The reality, however, is that this benefit is primarily an abstraction. Projects of any substantial size are extremely difficult to fork, and successful forks not backed by serious dollar investments are very, very rare. The reason for the difficulty lies at the heart of another open-source myth, namely of the midnight engineer generously donating his or her time to a project that interests him or her. Those people certainly exist, but they are rarely the principal developers of a large project. I discussed this phenomenon in my column, “The Changing Face of Open Source.”

Core developers of large projects are almost always paid developers. This is true for Eclipse, JBoss, Red Hat, most Google projects and, notably, OpenSolaris, among many others. These developers are either employees of companies that have a commercial interest in the finished product, or that derive revenue from ongoing support of the product. These developers, then, don’t have any reason to join a fork. In fact, they have strong reasons not to.

In the event an open-source project is closed down, such as Oracle’s decision regarding OpenSolaris, the competition of an existing product is no longer a constraint, but the lack of payment for contributions is a limitation. Today, this dynamic is playing out with Illumos, the community that has gathered to keep OpenSolaris going. The project, which is receiving contributions in kind (as in services such as hosting), will taste success only if it can secure the wherewithal to hire Solaris engineers who choose to leave Oracle or are drawn in from other companies.

While it’s certainly possible that engineers could volunteer their time, it’s unlikely volunteers will contribute on a scale sufficient to do more than maintenance. Illumos’ principal goal of replicating the new features Oracle adds to Solaris is unlikely to be a big draw for engineers assessing where to donate their time. Most contributors to open-source projects enjoy, even delight in, blazing new paths rather than copying features—especially when they're developed by a company viewed as an antagonist. As a result, Illumos faces many substantial obstacles.

Most open-source forks of any importance (such as the FreeBSD and OpenBSD forks of BSD Unix, as well as the many variants of Linux) occur in operating systems, and generally because of a specific need that a group is willing to invest in.

Ubuntu is a prime example, and one that was well funded. Community-based forks of Linux mostly originated when the OS was smaller and less stable than it is today. Other forks, such as the Joomla-Mambo-MiaCMS tri-vergence, were done due to personality or philosophical differences. I leave you to decide which have been successful and which not.

Forks of open-source projects nearly always split a community. Because most projects don’t have a large community to begin with, if there is no one paying for development of the fork, most forks die off quickly as the forking group begins to realize the size of its undertaking and the limited resources at its disposal. There have been perhaps 25 successful forks of high-profile projects that were sustained by a volunteer community. And those few projects (most of which occurred years ago) have kept alive the belief that forking is a standard open-source activity and a viable development option.

However, unless there is a serious commitment of dollars behind the new project, in today’s world, most forks are stillborn or die quickly. 

If there are even slight differences in the API or architecture (the latter is typical for the forks) you cannot just insert code from subsequent versions of open source project, you have to re-implement it (and then debug and maintain) each such fix.  This might be not that difficult initially. But if each product line is actively developed, then trees quickly diverge more and more and each subsequent fix or refinement becomes harder and harder to synchronize. Here is how Ted Mittelstaedt  the author of The FreeBSD Corporate Networker's Guide  explained the situation[Mittelstaedt2000]            

....For example, say you get BSD networking code and you see a race condition in it.  You fix it, and decide that your fix is so fantastic that your not going to share it.  Then, 3 months later someone working on the public code notices the same race condition, and fixes it, but does it differently than you did. Then, a few weeks later someone working on the BSD code implements this great new feature that has a component that's integrated into the public BSD anti-race code.  Now, you have a lot of work, because you have to go rip out your race fix and redo it like the BSD code, then integrate in this new feature.  And, what if you have continued to make modifications to the code, so now when you rip out your race fix, you break more of your own code.  And, if you decide not to rip out your race fix, then you have to reimplement the new feature in the public code. You can imagine what happens if this sort of thing has been going on for years and years with hundreds of little changes - implementing new features basically eventually means that you cannot merely copy them into your code from the BSD code, you have to completely reengineer them. What ends up happening if the fork exists for years and years is that your code ultimately becomes so different from the BSD code that it completely loses all resemblance to the BSD code, i.e.: it simply no longer IS BSD code.  Thus, you eventually end up losing access to the very code that you originally decided to "close".  To give you some examples of why this is so stupid, there have been a number of security vulnerabilities posted in the last couple of years that were repaired in public BSD code within a day of release of knowledge of the vulnerability, yet commercial software vendors (who purported to be using Real Live BSD networking code) took weeks to issue patches...

Moreover this new (commercial) code tree becomes disconnected from the community that is working on it (if such a community still exists). Even when developer of a forked version is using one of free/open software licenses he/she needs to create own developer community and to attract and extend existing userbase. Unless  the deployment is done on a different platform, for which no direct competitor exists (for example you forked the product in order to create a Windows version), you need to compete with pre-existing open source version which now became the lowest common denominator. Getting competitive advantages in such a situation is an expensive and long process. Remember that any vendor of commercialized open source software needs to fight the battle on several fronts simultaneously, the situation which was long deplored by military strategists: 

• Against pre-existing free product which actually can be revitalized by competition (RHEL vs. Suse 10 vs. FreeBSD )
• Against existing commercial competitors, which possibly give rise to open source product in the first place (Linux vs. Solaris, Nagios vs. Tivoli Monitoring 6.2). Paradoxically commercial competitors (like Sun in case of Solaris) proved to be able to open their codebase stealing high moral ground.  In case of very complex codebase like Solaris or Linux kernel openness of code does not matter much as the code is closed by the over-complexity much more effectively. 
• Against late comers to the same area (Oracle vs. Red Hat)

So that problem is not that GPLed products are perfect and there is no way one can improve it: in most cases they have an lot of warts and it's not that difficult to rewrite and improve along the way any GPLed product. The problem is to find market for the improved commercial version. This is not easy. For example, commercial version of gcc instantly would needs to compete against the original gcc on one front, and against established commercial compilers such vendors as IBM, Microsoft, and Sun on the other.

All this considerations suggest that it does not make much sense to try to hijack a free/open project and convert it into a commercial product, if the free product is still enjoys active development. This bicycle-type stability of free/open products that are actively developed is not dependent of the type of the license used.  The fact that BSD explicitly allow conversion to the closed source commercial product does not actually help much to make money from it. As we already discussed the forking cuts down the efficiency of reuse of the original code, increase communication overhead with the original project and put new product square between already entrenched existing free product and similarly entrenched its commercial competitors. 

But even of  the development of the open/free product stalled and the product itself managed to reach rather mature stage, the conversion of the free/open product to commercial still is a mixed blessing. First of all the fact that free product at some point lost traction with users and the development was stalled is a warning:  profitability of this undertaking is highly questionable as free/open version will always be a shadow and this shadow may be reactivated by your very efforts and run after you.  This consideration applies equally to both GPL and BSD licensed products. In both cases unless there was a huge hidden potential in the product that was left undiscovered by the initial developers of the free version the value of commercialization is problematic. If we assume the same platform, one can agree that this situation is definitely not a road to Eldorado.

The second considerations is that copyright protects expression not ideas and the cost of changing this existing expression (codebase) is usually quite substantial and as year 2K conversions show so vividly does not the differ much from the cost of complete reimplementation. It's important to understand that the restrictions than are imposed by GPL do not affect the level of difficulties (and the costs) of  reengineering. It costs the same to re-implement any GPL based product as BSD licensed product. After all in both cases the conditions for reverse engineering are perfect: the source is available, the active development is over so the codebase is relatively stable (if we assume this as a precondition for the successful commercialization) and there is possible discontent in the userbase about quality, slow pace of development or bugginess of the free version so there are chances to attract former and present users to the new offering.

Moreover, commercial developer is free to chose a different and better language or mixture of languages) or compiler or both. It also can find a better commercially distributed set of libraries for the reimplementation. As Perl supporters rightfully stress, in software there's always more than one way to write your code.

And please don't forget that reverse engineering is a very powerful tool to get a new expression for a viable programming ideas and that unless you explicitly prohibit reengineering in the license, it is always possible to reverse engineer the product (and substantially improve it along the road) for the fraction of the cost of the initial development.  Actually for small GPL projects (let's say below 10K lines of code) any gifted programmer probably can reengineering a codebase in half a year or so creating a noticeably better commercial version.

The second consideration is that even if we assume that the GPL was created to protect against such un-ethical behavior as plagiarism, we need to face the fact that people are not perfect and that those violations are often specific to the group of people who violates other social norms. With any license a free/open project is much like a house with open doors. That means that like open doors it attracts a certain type of people, who are only afraid of being caught.

But are the chances of being caught ? I think that they depend mainly on the popularity of the original product not on the license. Unless the hijackers are very stupid or rushed their version to the market, even if the product that is using the same codebase chances to detect a plagiarism in a closed commercial product derived from a stalled GPLed product are not that great. Whether this trick will help such dishonest people to get any return on their investment is another story. I think that this far from being given: in many GPLed products are reimplementation of existing commercial products or have powerful commercial competitors and as such are not very attractive for the commercial marketplace.

It is also naive not to assume that a certain technical measures similar to those used by students to hide plagiarism will not be applied to the codebase. Getting or enhancing a code-washing-machine used by students to conceal plagiarism is not that difficult.

All those consideration means that a more realistic policy is to overcome your fears: explicitly permit commercial appropriation and try to use such cases, if any, to the benefit of the product development, not try to prevent then with a paper sword of  license restrictions. At the end of the day, the license is nothing but a text document and, with the source code freely available, the preventions measures are limited by definition to those who would like to exhibit a moral behavior anyway. 

I feel that licenses like the GPL aren't the real answer to the problem of plagiarism and "free-riding" in software development. At the same time any license with such measures have some immanent properties that are harmful for mature free/open projects: they tend to restrict potential contribution from commercial companies and commercial developers. This is definitely the case for GPL. Many commercial developers, who can contribute to GPL projects, do not do so because of the fears connected with GPL limitations of derived works. GPL supporters often forget that while the BSD style licenses don't prevent a code from becoming proprietary, they also don't discriminate or deny access to anyone and that fact alone creates a pool of "good will" that is absent at the case of GPL. And the fact is that commercial companies employ the largest pool of high-level professional programmers.

Let's summarize out findings. It's not that easy and actually pretty and risky costly to convert free/open software to a viable commercial product. If GPLed product is commercialized and this action is discovered, the next logical step for the commercial company in question is complete reengineering, not the return to the co-development of a free version (relations are already spoiled by PR attacks used by GPL enthusiasts). That means that in this respect GPL is even weaker than BSD because the latter preserve a pool of good will from commercial developers. I think that free/open developers should not be worried too much about somebody "stealing" their code.

As long as the code is open and is useful for the community, there will be continued development of the free/open implementation that with each iteration makes the product better. And this does not depends on the level of protection from hijacking. If  a company takes code and builds a commercial product around it, so can any other company. Therefore unless the product is substantially improved, the commercial potential is very slim, if exists at all.  The mere fact of the existence of free/open implementation creates the effect of "the least common denominator"  for this class of software tools. The latter makes competition for the commercial offerings more difficult because the company needs to fight on two fronts: on one defend somehow itself from the free version and "free-riding", on the other try to win customers of already entrenched more expensive commercial products. The stock curve and the difficult path to the profitability of the Linux distributors that had highly successful IPOs during "Internet bubble" can serve as another illustration of  this point.  Note that this "lowest common denominator" defense is independent of the license used. 

In a way free software is similar to dumping and as is the case with dumping it is difficult to counter it with higher priced goods no matter how better they are.  Actually the most interesting case of hijacking recently happen with GPLed product: Oracle decided to create its own version of Linux based on Red Hat.

2.2.2. Case study No.1: Microsoft's use of Kerberos code

The classic arguments of  the "kidnapping paranoia" line of reasoning are arguments connected with Microsoft's use of the Kerberos code. This example is often sited as an explicit confirmation of the threat and, by extension, the value of GPL (Kerberos was released under a license derived from the BSD and X11 licenses). Here is a more or less typical pro-GPL description of the situation[Leibovitch2000a]:

...In what has become fairly widespread news, Microsoft has taken the Kerberos security system and attempted to extend the protocol in a non-portable way while keeping the extensions secret. So far the biggest news surrounding this issue came from the following Slashdot-Microsoft exchange: a Slashdot reader posted the extensions; Microsoft, under the terms of its license, attempted to have the links removed; Slashdot subsequently told Microsoft where to stick its e-complaint.

Open sesame Certainly one could take Microsoft to task for the ethics of taking an open standard and turning it proprietary. But why it was done, to me, is neither as interesting nor as genuine a source of concern as how it was done or how it can be prevented in the future.

You see, the Kerberos code that Microsoft "enhanced" is distributed under a BSD-style license similar to the one used by XFree86. This is the kind of license that generally allows anyone who legally obtains the source code to make modifications without requiring such modifications themselves to be open. Indeed, the copyright file that comes in the current Kerberos code explicitly says:

Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted.

In contrast, the GNU Public License, under which Linux and most of its tools are distributed, requires that all modifications must be as open as the original code.

Clearly, had Kerberos been distributed under the GPL rather than a less-restricted license, Microsoft wouldn't have been able to do what they did. Sure, the company could challenge the GPL or even try to flout it; but considering Microsoft's own paranoia about software licenses, that's unlikely...

People who state that "had Kerberos been distributed under the GPL rather than a less-restricted license, Microsoft wouldn't have been able to do what they did."  forget both technical and social context of this "Microsoft appropriation".

From the technical standpoint the problem with pro-GPL views is that actually it's not clear that Microsoft used the code of the reference implementation, not just the standard. Moreover Microsoft "embraced and extended" Kerberos in a perfectly compatible way using a specific field reserved for such extensions by the designers of the Kerberos protocol as defined in the standard. 

From the social environment standpoint is no way Kerberos can be called "actively developed product" at the time when Microsoft decided to use it; it was a mature, but not widely used standard and reference implementation) and the potential problems with GPL.

Here are some additional counterarguments to such a typical "pro-GPL" interpretation of the Kerberos situation:

• the fact that Microsoft adopted Kerberos means a lot for the popularization of the package. Before Microsoft decision Kerberos as a technical solution was "stalled" and thus Microsoft revived interest in the interesting technical solution and stimulated other implementation including Linux-related work. Given Microsoft's market share and aggressive promotion of  the Windows 2000 server, it is more likely that Samba and open implementations of Kerberos  benefited, not were harmed from this fact. The emergence of the debate also means that they got some press attention and thus can attract fresh resources and thus evolve.  This evolution may eventually lead to the incorporation in some form of Microsoft extensions.
   
• The value of the reference codebase for Microsoft is unclear and that means that the question about the license for this implementation is largely irrelevant. Moreover the mere fact of existence of GPLed Kerberos implementation may convince Microsoft that that there is not much commercial advantage in implementing the protocol and thus Kerberos would be languishing in obscurity. Even LGPL is problematic here. Some people argue that is Kerberos was released under LGPL Microsoft would have been able to use the code just as well. But the resulting KERB.DLL would have been available to other parties. That is not an attractive for Microsoft solution taking into account the FSF origin of LGPL and Microsoft resources. Moreover GPL implied political problems might scare not only Microsoft but other commercial companies, including some Microsoft customers. This can motivate Microsoft to break or  drastically modified the standard. In both cases the situation might be even worse that it exists today.
   
• Microsoft did provided compatibility with an older implementations and later even promised to release the specification of extensions. Compatibility means that Microsoft and other Kerberos implementations are interoperable on the basic level. Currently one still can not use the additional Microsoft-specific features in other systems, but with this limitation you still can use it in heterogeneous networks.

2.2.3. Case study No. 2: Scripting languages and GPL

But the most significant historical observation that works against the claim about the value of GPL in preventing kidnapping is that none of the major scripting languages that reached the maturity stages are now released under pure GPL (Perl manages to innovate even in this area by the introduction of a dual licensing GPL+ Artistic from the very beginning ;-).

Scripting languages represent the most innovative part of the free/open software movement, in comparison with which the Linux kernel is a pretty conservative undertaking.  They essentially became a new class of algorithmic languages,  the class that provided the first practically useful implementations of the idea of so called "very high level languages."  This approach is the most clearly expressed in TCL: you can program as much as you can in TCL; when TCL does not provide necessary primitives you can switch to a lower level language (C or C++) and create components that will be integrated into pre-exiting TCL framework.  All-in all one can claim that in this area free software developers contributed to innovation by creating leading representatives of this new, innovative class of languages. Among the most prominent representatives of this class are  TCL, Perl, Python, PHP.  None are currently released under pure GPL, although in the past some were.

The level of innovation present in this area means that they represent an important test case, the case where there is certainly an intellectual property that can be kidnapped. But other then unsuccessful FSF attempts to fork the languages that changes the license from GPL, this danger never materialized.  And as Guido van Rossum stated in his Responds to Python Licensing Issues  Open Source, Community, Software Sep 7th, 2000

In any case we don't want to use *just* the GPL for Python, because there are many proprietary software developers in the Python community who don't want to work with the GPL. Python has always had a BSD'ish license which was perfect for them. I see no reason to suddenly confront everyone in the Python world with the GPL.

A similar opinion expressed by PHP developers Andi Gutmans and Zeev Suraski: in LG interview :

LM: What were the motives behind changing the license between PHP 3 and PHP 4?

Suraski: There were several reasons. The main concern with the GPL was that commercial companies, such as IBM and others, avoid GPL'd code like the plague. The fact that the GPL is "contagious" discouraged many companies from putting effort into projects that are distributed under it. If we take a look at the few open source projects that IBM endorses, we would find Apache, Jakarta and PHP - none of which is released under the GPL, and we believe it is not a coincidence. These licenses are less restrictive, and we believe they work better in the real world. We also felt PHP was mature enough to let everyone use it, without having to ask for our permission, which is why the permission clause was dropped. Other than that, the license stayed pretty much the same.

I would like to comment on the claim "commercial companies, such as IBM and others, avoid GPL'd code like the plague".  Large commercial companies are not stupid and sometimes make moves that looks like an adopting of open source. IBM play in this area is vey interesting as it actually did contributed a lot of code to Linux (and was sued for this by SCO). But IBM motivation here is/was quite different. Linux for IBM was a brilliant move to same its mainframe business (as well as to consolidate other lines of business) by providing VM/Linux environment instead of "VM/CMS" environment.  This was really brilliant move similar to Henry IV  of France conversion to Catholicism. And re reasons were the same. As Henry IV famously quipped "Paris is well worth a Mass" .  There was also a subtle connection with outsourcing about which you can read in more details in  IBM marry Linux to Outsourcing

Here we can see that the author explicitly state that "We also felt PHP was mature enough" to justify the switch of the license. I feel that here they catch the essence of the situation. As Tim O'Rielly pointed out:

I remember Bob Schiefler of the X Consortium (who is one of my heroes) stating so clearly that he was developing software that he wanted to be used as a base for further development, whether that development occurred as free or proprietary software.

Richard Stallman acknowledges this problem in his  Response to Dave Winer on Python Licensing

David Winer is passionate in his disgust for me and my work; so much so that he does not limit himself to rebuking me for the things I have done. He feels entitled to imagine other things he would disapprove of, and attack me for them too.

In his column on September 8, he notes that he tells Guido van Rossum, "Don't give in to Stallman." From the context, it is clear Winer imagines that I am asking--or rather, demanding--that Python be released under the GPL and only the GPL.

As Guido can confirm, that is not the case. I have been pushing for the license of Python to be compatible with the GPL, so that it can be linked with GPL-covered programs as well as with other programs.

If the Python license is incompatible with the most popular free software license, that creates a major practical problem for the community. Given the importance of this problem, all my efforts in talking with the Python developers have been aimed at solving it, at trying to propose some solution that they will accept. This isn't easy, and I am not going to make it harder by asking them for something else in addition.

We can also ask ourselves a question "Why do developers of some scripting languages decided to avoid GPL after the product reached a mature stage?". My impression here is that the main problem is that GPL is not only about freedom, it's about "suppressed envy" as well.  "You shall not belong to anybody" mantra that as we discussed before is dictated by fear and envy, not only by the desire to cooperate with other people (and that's explains why GPL is rather popular for small commercial startups often called "Linux startups").  Actually this "suppressed envy" and paranoia about actions of competitors that is typical not only for "free software developers" but for small businesses in general.  That's why GPL has such an appeal for a small business environment. Often small companies are very paranoid about their bigger competitors;  they are afraid about the possibility that their product attract a bigger competitor that can destroy the company by stealing the code, re-hiring key workers or both.  As many philosophers pointed out this makes them susceptible to any Anarchist ideas and GPL is no exclusion.   

That lead us to an important conclusion.  The protection from the hijacking that free/open project have is more connected with "bicycle type stability" of fast pace development, than with the license per se.  If codebase is more or less stable and speed of development is low, then the product can be hijacked no matter what license was used and here again the difference in protection in minimal as the best way to create a commercial version of the product is to completely reengineer the existing codebase. 

The inability of the BSD license to defend the product from hijacking is an illusion. If the development is active, both licenses have approximately the same ability to defend the products. Those who still disagree can, as an additional example,  revisit the history of development of the OpenSSH vs. the commercial version of SSH.

To conclude this part of our discussion I would like to stress that the threat of commercial exploitation should be always weighted against the threat of stagnation. The latter is a real threat: most free/open projects are underpowered. Contrary to Cathedral and Bazaar mythology more often then not the only real force in the project development is the original author and thus the project dies if the original author(s) lost interest in the further development of the product). If you exclude commercial developers the number of people interested in the project has larger changes go down below critical mass and thus there are more chances for the project to stagnate. A lot of promising FSF projects ended this way (bash, Midnight Commander, etc). I would say that the danger of stagnation is definitely higher for GPLed products and that is an important negative aspect of GPL that often is missed in the process of the initial selection of the license by young developers.

2.2.. Case study No. 4: Apache and GPL

One of the slides in [Craig Mundie's] presentation was actually a very useful slide. It showed that there is a relationship — a set of relationships — between the public research through universities, corporations, users, and government. I think what we've seen is that it's not one-directional like that. What we've seen is that it's actually bi-directional in all those things — in fact, bi-directional across universities and consumers and government and business and all those directions.

And so while Apache, for example, is under a BSD-style license, it was very important while we were building the Apache community that we not only have other corporations use it and adopt it into their commercial products, but also that we communicate to those companies the need to reinvest back, the need to build Apache itself as a strong force as they build up the momentum behind it. And to us, even though the obligation isn't there to share their code back, the companies that are participating in the Apache Software Foundation and even more broadly, within the BSD communities, understand the need to reinvest, to build it back up. And that's one thing that I think may be missing in some of this debate: the creation of licenses, the creation of regimes that really are bi-directional, that really put all the participants at an equal level.

I totally welcome Microsoft exploring shared source licenses. I think for proprietary software, I'd much rather have the code to it than not have the code to it. I think we're going to see a big difference in the amount of resources that people will put in to a shared source license regime versus one that is an open source license regime. So it's all a matter of experimentation. I'm all for experimenting with different licenses. I think history has shown that open source is a more efficient way to go in certain circumstances. At the same time, there are 10 million Microsoft developers out there who might have a different opinion. I think it's worth finding out.

2.3. GPL and innovation -- another side of kidnapping paranoia

Richard Stallman was absolutely right when he said that the purpose of GPL was not to promote the free exchange of ideas, but to create a society in which virtually all software must be free.  We need to distinguish between two types of software development:

1. Creating an innovative software product

2. Creating an infrastructure in which it is easier/possible to create innovative products.

Most FSF activity can be classified as belonging to the second category. Major GPLed products including gcc, bash, gawk and a set of Unix utilities are actually pretty conservative reimplementation of pre-existing software. That makes changes for GPL products to be kidnapped substantially lower because they often represent "the least common denominator":  a free alternative to exiting and entrenched commercial software. In a sense GPLed products represent trend that might be called "communization of Unix environment" and can be considered as oriented on creating of pool of goodwill, not explicit financial benefits, although they might be a side effect of increased social status of a programmers (as Linus Torvalds aptly demonstrated). This is actually a pretty common idea among more critically oriented part of programming intelligentsia as the following typical comment to the kuro5hin.org The GPL A Technology Of Trust that revolved round this this idea:

People write free software do it because they estimate that the potential prestige/goodwill that they derive from a successful project would outweigh the financial opportunity costs of releasing it for free.

Little opportunity cost

The fact is, most successful open source software are commodities and would probably not find a paying market, eg. the Linux kernel (essentially Tenenbaum's Minix), Apache web server, and almost all the projects on sourceforge.

The browser is a good negative example. It is non trivial to write a standards compliant browser, and not many people even attempt to write one. Mozilla was a mess until very recently, and still doesn't measure up to IE or Opera.

Another source of open source software is from the academic community, eg. TeX and other languages, where the developers (students, researchers) often have neither the time nor inclination to market the software.

Prestige

The amount of prestige to be gained from being associated with a successful project is huge. The lead programmers for MS Office laboured in obscurity, but Miguel Icaza is almost a hero for leading the Gnome project, which is not exactly cutting edge software. Similarly, Linus' prominence probably got him his job at Transmeta.

My two cents: write whatever software you feel like writing, sell it if you can, give it away if you can't. Just stop expending so much energy over meaningless licensing issues or pretend to have some sort of moral high ground.

But by logical extension the fact that GPL product "standardized" the development environment may have some inhibiting effect on innovation: it's zero price advantage and adherence to existing standards makes it more difficult to create an alternative better product that occupies the same niche. In this sense GPLed products can raise the barrier of entry for other developers who are willing to produce a better alternatives to the product and (to great dismay of GPL zealots) the entrenched GPLed software actually acts much like a software monopoly.  In this sense if GPLed product can be counter-innovative and thus help to kill a profit-based  incentives for developers to create a better versions of the product, let's say bash3 and gawk++   --  efforts that may lead to substantial improvements of the underlining concepts, algorithms, implementation or both (just look on variety of commercial word processors offerings and features that they provide).

That shortcoming is absent in case of BSD licensed products as you can always convert the product into commercial and try to find a market niche based on innovative add-on features. Actually this is not easy as existing free product still represent a lowest common denominator for the market, but still easier than for GPLed product because you can save the cost of reengineering that base version.  That 's why such an approach is often used for appliances: a lot of appliances are based on some version of FreeBSD. 

And it's not accidental that GPLed products has proven to be beneficial primarily for commercial companies that sell both hardware, and integration and/or software consultancy services and need someway to cheapen TCO for some of their projects (e.g. IBM, TiVo, to a lesser extent HP) as well as some companies that use this open source software in their business (some ISPs). The Linux distributors experience (Mandrake, Caldera and to a lesser extent Red Hat) suggests that the GPL forces those companies to spend massive amounts of money on development without adequate return on the investment: disenfranchising software development (The GPL A Technology Of Trust):

The GPL is good for business. Companies that use the GPL are neither foolish nor stupid. They simply want to trust that other companies won't be able to take unfair advantage of them, and the GPL gives them that immediate security while simultaneously allowing open cooperation. This is a rather interesting comment. The GPL has proven to be good primarily for companies that sell hardware and need someway to cheapen their TCO (e.g. IBM, TiVo, etc) as well as companies that use software in their day to day existence (almost all of them). The GPL forces software companies to become support agencies while still spending massive amounts of money on development. In the long run the GPL will probably be beneficial to people who use software while disenfranchising a majority of those who produce software which will lead to less professional development of software but will make the software that does exist a commodity.

If GPLed product is "the least common denominator" in highly developed areas were standards already were created and got wide acceptance, then their only appeal stems from strict adherence to standards and if existing standard is conservative they also help to maintain status quo. That probably is true for Samba and might be partially for Star Office (that definitely inhibited the development of  Gnumeric and AbiWord). It's also difficult to claim that Linux kernel helped BeOs survival. 

Thus major GPLed product might be protected from hijacking by commercial companies not by GPL license per se, but by the fact that most of them are pretty conservative products that signify "baseline" and as such has limited commercial potential. As many people noted Linux kernel did not introduce any significant innovations into operating system kernel design. And it's not accidental that most of its development it fall behind Free/Open/Net BSD kernels that were developed with a small fraction of the recourses. At the same time Unix which served as a blueprint for Linux introduced at least seven major innovations: C language as system programming language (actually C was a pretty innovative blend of BCPL and PL/1), hierarchical file system, pipes and a set of pipes friendly utilities/filters, regular expressions, devices as files, shell as the mother of all modern scripting languages, first built-in TCP/IP stack. If one compares Linux with BE OS, Inferno or even with OS/2 and Amiga one can see that in major design decisions Linux is a pretty conservative kernel.

As Rob Pike noted in his "Systems Software Research is Irrelevant"  Linux can be considered as a sign that computer science research became irrelevant and he claimed that the whole situation in OS design is generally bad and requires action. I my other paper I suggested that the value of Linux can be attributed to its role as a new freely available Super BIOS that can be used for creation of additional layers of compatible software. But the stagnation in the OS market caused by Linux successful bid for Super BIOS role can hinders development in hardware. One needs to remember that Unix enabled the RISC revolution. What hardware improvements Linux bring to the table? It's not Transmeta as the last thing Crusoe chip can benefit from is traditional monolithic Unix kernel. This kind of chips are more suitable for OS virtualization i.e. VM style environments and probably Transmeta lost some of the chances for commercial success by betting on the wrong horse for the sake of positive PR.

Again here we need to understand that GPL is not only about freedom, it's about envy as well. It's naive to assume that the society deserves free software not only in a form of GPLed software. Below I reproduce one of Slashdot posts that contains the most typical arguments of GPL critics in this domain:

Try this: GPL and reason behind copyright (Score:0) by Anonymous Coward on Saturday January 01, @02:05PM EST (#121)

First: GPL is proving itself an effect means to an (RMS's) end, namely, GNU (GPL-licensed OS+apps). Those who don't care about ethics, philosophy, etc., won't need to burden their minds further. Many of us find the discussion entertaining or important to influencing how we or others license the code to which we or other may want to add more code (ie, derivatives). Now, on to my seldom-seen point. Copyright law exists mainly to encourage people to create and publish works. (The law recognizes that complete loss of copyrights after about a hundred years will has little effect on that encouragement, for example.) GPL-licensor's use of copyright law, specifically the viral aspect (you can't use my code if you don't GPL your additions), has little or nothing to do with encouraging new work. Few people would not develop software if they couldn't use the GPL. In fact, it discourages new work because it many developers will refuse to make derivatives of GPLed software because they refuse to be told how to license their own work. BSD type licenses (and some parts of the GPL) do encourage new work by protecting reputation (attribution clauses, etc.) and protecting against liability (warranty clauses, etc.). But the nasty no-share clause of the GPL has nothing to do with the reason for copyright law and the GPL thus abuses the law. That is the business of (even) ethical lawyers, but it shouldn't be the business of ethical software developers. It's inherently selfish and should receive the same admonishment as other forms of selfishness outside the commercial world.

2.4. GPL, BSDL and the Standards

A relatively new and a very important idea in the area of free/open software licensing is that such licenses should protect compatibility of derivatives with the existing standards, if any. I would even say that the importance of the adherence to standards is one of the cornerstone ideas of free/open software development. Regrettably here both BSD and GPL are completely toothless in this area and we may need to use other licenses to ensure the standards compatibility.

For example, Linux is not Unix. And the reason is simple -- Linux was never certified by Open Consortium for compliance with POSIX standards. The point in this statement is that GPL permits compatibility with standards. It does not encourage it. Actually FSF itself contributed to the proliferation of incompatible programs with a very similar functionality due to its fight for the ideological purity. The classic example is KDE/Gnome saga. Moreover sometimes FSF promote forks of important free/open products based on their ideological impurity. This was the case with PHP and Python -- the important and innovative scripting languages that would benefit  from all and every possible support of the community. And this is a really sad historical fact that is on FSF record that cannot be eliminated by any number of repetitions of the word of "freedom".

And it might make a perfect sense to add some protection against unnecessary deviation from the standard (or "reference" API) into the license by treating the creator of derived works differently, if he/she violates this requirement. This idea in a rudimentary form was probably first introduced in the Sun community license. As I understand it, someone can take my program, modify it and then choose himself how he wishes to release his modifications. He can make them available under the same license. He can make them available only in binary form. What he cannot do (under the license) is to distribute his 'non-standard version' ("the original program *with* incompatible changes") in binary only form without also including my 'standard version' and the copyrights and disclaimers. It's a definite refinement of both BSD (you can do anything you want with it, even make it commercial and secret) and GPL (you can do anything you want with it as long as you allow anyone else exactly the same rights with regard to your own modifications) because it introduces an important new dimension that protect the initial implementation from  arbitrary NIH (not-invented-here) changes and  breaking of standard without additional benefits ("embrace and extend for it's own sake" approach).  For example such an approach makes sense for Perl middleware, where someone is likely to grab a several pre-exiting components and  modify them slightly to accomplish a particular task.

The important next step in the direction of ensuring the standard compatibility was probably made by Sun in its Sun Industry Standards Source License (SISSL) that was created in early 2001. Although it has some flavor of Sun's battle with Microsoft over Java, it is one of the two licenses the OpenOffice code is dual-licensed under (The other is the LGPL.) The license basically says that your implementation should conform to an approved industry standard, or if it doesn't, than you need to document all deviations with standards as well as provide a source code of the reference implementation. This property of SISSL makes it very attractive for dual licensing purposes. We will tough this theme when we will discuss so called "GPL hell" problem.

2.5. The Influence of Social Environment on Attractiveness of GPL and BSDL

Traditionally BSD is considered to be most suitable for university software development. An important feature of this university-bound development is that it often has some direct or indirect sponsor, especially a government sponsor. That puts it in a special category of taxpayer sponsored software (or oven into a subclass of "government sponsored software"). For example in his paper The Ethics of Free Software Bertran Mayers (of Eiffel fame) proposed to distinguish between five major economic categories of free software:

The categories identified here--donated, taxpayer-funded, privately funded, taxpayer-sponsored and privately-sponsored--seem to exhaust the economic possibilities; they provide precise and accurate terminology, more useful in practice than the catch-all term of free software.

In connection with taxpayers-funded and taxpayer-sponsored software in Feb. 2001 Microsoft vice president Jim Allchin's  raised an important question: is it fair to released such software under the terms of GPL[Allchin2001]:

''I worry if the government encourages open source, and I don't think we've done enough education of policy makers to understand the threat.''

Actually this is not a theoretical question: the attempts to release some government-sponsored software exclusively under GPL can be found in many free/open software repositories, for example Freshmeat. An explicit case of releasing software under the GPL by an author  working under the government contact was mentioned in the [February 24, 2001 Slashdot discussion] As Tim O'Reilly pointed out in his commentary on the subject [O'Reilly2001] essentially he stated:  "...Microsoft is an American company. We pay taxes. I don't see why government-funded software should be put out under a license that prevents us from using that software." In other words government-funded software should be released under such a software license that does not discriminate against proprietary software developers. 

That consideration means that BSD-style licenses are a better choice for government sponsored work; but probably dual licensing will also work. The reasoning behind government-sponsored software may be generalized to most types of "grant-based" university research. As a general rule the software should be released in such a way as not to discriminate against any of the sponsors.

Universities usually have an elaborate code about  proper behaviors of students and faculty in the area of intellectual property rights and here reconciliation of GPL with such policies may be a non-trivial exercise. For example, typical university policy  usually specifies something like the following  [University of Unnioise2001]:

... ... ...

SECTION 4. COPYRIGHTS

(a) Ownership. Unless subject to any of the exceptions specified below or in Section 4(c), creators retain all rights to traditional academic copyrightable works as defined in Section 2(b) above. (See, however, Sections 4(b)(2) below.)

The University shall own copyrightable works as follows:

(1) Works created pursuant to the terms of a university agreement with an external party, or

(2) Works created as a specific requirement of employment or as an assigned university duty that may be specified, for example, in a written job description or an employment agreement. Such specification may define the full scope or content of the employee’s university employment duties comprehensively or may be limited to terms applicable to a single copyrightable work. Absent such prior written specification, ownership will vest with the University in those cases where the University provides the motivation for the preparation of the work, the topic or content of which is determined by the creator’s employment duties and/or when the work is prepared at the university’s expense. [see endnote 1]

(3) Works specifically commissioned by the University. The term "commissioned work" is hereafter used to describe a copyrightable work prepared under a written agreement between the University and the creator when (1) the creator is not a university employee or (2) the creator is a university employee but the work to be performed falls outside the normal scope of the creator’s university employment. Contracts covering commissioned works shall specify that the author convey by assignment, if necessary, such rights as are required by the University.

(4) Works that are also patentable. The University reserves the right to pursue multiple forms of legal protection concomitantly if available. Computer software, for example, can be protected by copyright, patent, trade secret and trademark.

(b) University Rights in Creator-Owned Works

(1) Traditional academic copyrightable works created using university resources usually and customarily provided are owned by the creators. Such works need not be licensed to the University.

(2) Traditional academic copyrightable works created with use of university resources over and above those usually and customarily provided shall be owned by the creators but licensed to the University. The minimum terms of such license shall grant the University the right to use the original work in its internally administered programs of teaching, research, and public service on a perpetual, royalty-free, non-exclusive basis. The University may retain more than the minimum license rights when justified by the circumstances of development.

(c) Student Works. Unless subject to the provisions of paragraph (a) or provided otherwise by written agreement, copyrightable works prepared by students as part of the requirements for a university degree program are deemed to be the property of the student but are subject to the following provisions:

(1) The original records (including software) of an investigation for a graduate thesis or dissertation are the property of the University but may be retained by the student at the discretion of the student’s major department.

(2) The University shall have, as a condition of the degree award, the royalty-free right to retain, use and distribute a limited number of copies of the thesis, together with the right to require its publication for archival use.

That definitely excludes the possibility of using pure GPL licensing for the student and faculty works unless explicitly approved by the Board of Trustees of the University in qt>University in question.  Usage for "internally administered programs of teaching, research, and public service" may include making derivative works for commercial or non-commercial distribution, distributing the product linked with commercial libraries, etc. There are many cases where GPL forbids such actions without certain conditions first being met by the university. It looks that for most universities (University of Texas may one of exceptions) any product licensed under GPL should be at least dually licensed to the university under BSD style license. For the reasons discussed above additional difficulties may arise with GPL licensing if this was a product of research that has commercial sponsors.

But there is also an interesting (and false) line of thinking that somewhat increases the attractiveness of GPL for government sponsored projects.  Let me illustrate it with the RSA example. In the RSA and Diffie-Hellman case, the two universities worked out a cross-licensing deal so they could each use the algorithms without cost. The government agencies can use them for free too, since it was a government funded research. But one can argue that other taxpayers were left in the cold.  That probably was not a bad thing as it permitted commercializing of research that in a long run benefited all taxpayers as the patent eventually expired. But this temporary injustice in the long run benefited the society as a whole.

At the same time GPL is often considered to be more attractive in the corporate environment when the author works on the project in his/her spare time. This attractiveness have two sides. First of all traditional strength of GPL is small software development companies like Red Hat and other Linux distributors. In this case the hijacking paranoia is probably much  stronger motivator that freedom motives.

But GPL is also seems to be attractive to individual developers who are working in the corporate environment and are somewhat disenfranchised, alienated by this environment. In this case it can well serve both as a revenge and as a protector from (real or imaginable) corporate greed.

I think that the more the environment resembles somewhat Dilbertesque paradise with some local PHB in the key position, the more attractive GPL became as a form of social protest. From other point of view doing some development (possible rejected by the corporation) under GPL may decrease chances of the accusations of misusing corporate resources for personal benefits as "you shall not belong to anybody" property can be played as a kind of trump card.

From the other point of view GPL can provides additional flexibility in negotiation with corporate chieftains and may pave the way to return of the project previously rejected into corporate environment under the GPL's black banner of Anarchy. The latter may even be sympathetic for the management of small firms, with immanent in their position constant threat of a powerful competitors stealing company's lunch. That's why a substantial part of corporate developers who are contributing to free/open projects generally positively view GPL and many use it for their small and medium projects.

2.6. GPL as "the Incompatible License"
 

In his early days Stallman used "An Incompatible Operating system". And he seems follow this MIT tradition by creating "The Incompatible License": one of the most commonly sited problems with GPL is its extremely low level of compatibility with most other licensees. This problem is often called "GPL hell" problem or "GPL poison pill" in BSD circles. Actually it comprises of two  distinct sub-problems: The "Viral property"  and  "The hostility to other licenses and the danger of GPL Jihad".  We will discuss both of them separately after presenting some important background material.

Here I would like to provide an analogy between licenses and chemical compounds. As we know periodic table invented by Dimity Mendeleyev gave a unique view of the elements that gave a possibility to predict properties of elements from the properties of adjacent elements and even predict existence of several unknown elements.  A similar approach can be adopted toward licenses. Even chemical reactivity has its analogy. For example BSD and it's derivatives can be called lightweight, "chemically active" licenses in a sense that components produced under one license can almost without restrictions be used in other projects. At the same time other licenses, for example GPL, can be viewed as an examples of "noble gases type of license" and generally rejects any bonds with most of other licenses.

As Stallman admit himself that problems with GPL compatibility can badly affect the popularity of the "copylefted" software. In his note The X Windows Trap - GNU Project - Free Software Foundation (FSF) he wrote:

For many years, the X Consortium was the chief opponent of copyleft. It exerted both moral suasion and pressure to discourage free software developers from copylefting their programs. It used moral suasion by suggesting that it is not nice to say no. It used pressure through its rule that copylefted software could not be in the X Distribution.

Why did the X Consortium adopt this policy? It had to do with their definition of success. The X Consortium defined success as popularity--specifically, getting computer companies to use the X Window System. This definition put the computer companies in the driver's seat. Whatever they wanted, the X Consortium had to help them get it.

Computer companies normally distribute proprietary software. They wanted free software developers to donate their work for such use. If they had asked for this directly, people would have laughed. But the X Consortium, fronting for them, could present this request as an unselfish one. ``Join us in donating our work to proprietary software developers,'' they said, suggesting that this is a noble form of self-sacrifice. ``Join us in achieving popularity,'' they said, suggesting that it was not even a sacrifice.

But self-sacrifice is not the issue: tossing away the defense that copyleft provides, which protects the freedom of the whole community, is sacrificing more than yourself. Those who granted the X Consortium's request entrusted the community's future to the good will of the X Consortium.

Usually GPL enforced restrictions are not important for small products in semi-prototype phases. And  judging by the content of freshmeat.net this semi-prototype (version 0.1) stage comprises the lion share of all GPLed software.

One popular and proven solution to the GPL incompatibility problem is dual licensing. Dual licensing was first introduced by Perl and became a common practice in open source projects like Mozilla and OpenOffice. For example the OpenOffice.org source code provides open and free access to the technology both for the GPL community and for commercial developers or companies that cannot use the GPL.  Thus, through the combined use of GPL/LGPL and SISSL, OpenOffice developers can provide a better level of adherence to standards (an innovation inherent in SISSL) than either BSD or GPL license can provide.  Important and positive feature of dual licensing is that commercial developers can drop GPL is derivative products and thus have incentives to participate in the project despite its association with GPL.

But as soon as the product reaches maturity GPL licensing starts to create some unnecessary problems for the developers. Actually GPL pushes the developers into the reinventing the wheel because formally GPL is not compatible even with such liberal license as BSD with advertising clause. That why Stallman so relentlessly fought (and luckily for him, despite absence of any sound arguments eventually won) the battle against adverting clause in the BSD license. But there is still important software released under more resent Artistic-style licenses like NPL, Apple public license and several other, that are incompatible with GPL. In a pretty funny fashion Richard Stallman admitted this problem, but only as a reverse problem that he attributed to other licenses, as if compatibility with GPL should be a noble goal for any free software developer. Here is what he said about NPL:

The most serious practical problem in the NPL is that it is incompatible with the GNU GPL. It is impossible to combine NPL-covered code and GNU GPL-covered code together in one program, not even by linking separate object files or libraries; no matter how this is done, it has to violate one license or the other.

That means that developers are restricted in the use of software and is a developer feels this restriction, then from my point of view he/she can benefit from changing the license to BSD. That is actually the reason why many developers prefer the BSD license (as used in FreeBSD and elsewhere) or the X license: they prefer it not because they want to give proprietary software vendors the freedom to use their code (although as we discussed above the difference between BSD and GPL in this area is mostly an urban myth). Rather, they prefer such licenses because they don't discriminate against other free software licenses.

For mature products a major problem of GPL (well noted by the authors of alternative licenses) is that it discriminates against other software licenses and especially against commercial developers in case those developers contributes to GPLed software and their contributed module evolve in this GPLed environment. For example if I contributed module A to the GPLed program G, and my module was modified by other participants of the project G, then suddenly this module itself became at least dually licensed.  And if you do not want any GPLed modules in your commercial program you cannot reuse your own modified version. This is a rather theoretical case, but still it creates unnecessary anxiety that prevent people from  cooperating with GPLed projects.

My impression is that most software developers that use GPL want just to force the creator of the derivative works to provide them back changed source code, not to enforce GPL on the contributed code. An interesting side effect (a "cuckoo effect") can be observed if GPL product uses BSD licensed component or library and modifies it to enhance its usability, etc. In this case modified product essentially becomes GPL licensed (derived products for internal use probably are exempt).  As KDE case demonstrated quite well, presence of any  GPL-licensed component is a large software product is an implicit problem that may bite the developers anytime. And many developers of non GPLed product understand this threat quite will.  I would like to quote the following except from http://www.openbsd.org/policy.html.

The GNU Public License and licenses modeled on it impose the restriction that source code must be distributed or made available for all works that are derivatives of the GNU copyrighted code.

While this may be a noble strategy in terms of software sharing, it is a condition that is typically unacceptable for commercial use of software. As a consequence, software bound by the GPL terms can not be included in the kernel or "runtime" of OpenBSD, though software subject to GPL terms may be included as development tools or as part of the system that are "optional" as long as such use does not result in OpenBSD as a whole becoming subject to the GPL terms.

As an example, some ports include GNU Floating Point Emulation - this is optional and the system can be built without it or with an alternative emulation package. Another example is the use of GCC and other GNU tools in the OpenBSD tool chain - it is quite possible to distribute a system for many applications without a tool chain, or the distributor can choose to include a tool chain as an optional bundle which conforms to the GPL terms.

All this lead to the fragmentation of free software developers efforts and essentially endorses GPL isolationism.  All those considerations suggest that the newly introduced term  "GPL-compatible" looks as problematic as "Windows-compatible" and that's not that  funny. Actually a good appetite for discussions about "GPL compatibility" from some members of FSF  make use even any LGPL component in a commercial software very problematic. That also creates uneasiness among free software developers that use other licenses.

All that means that the illusive benefit of shutting out potential misuse of  free/open code by commercial software developers is far outweighed by the sheer irritation of shutting out the rest of the free software community.

What is really unfortunate that many developers artificially shuts off the important sector of free/open software developers that use BSD-style licensing by adopting just GPL license. After all most developers consider themselves first of all a programmers trying to solve some important for them problem that might benefit other people, not as political activists on an anti-IP crusade. For a successful product, the practical implications of retaining and defending your GPL'd code yourself  increase the load on the developers. The palliative solution is to transfer copyright to the FSF. Once this is done, though, the process of granting exceptions for creating derived works that aren't GPL'd became much more evolved.

It's important to understand that free/open software still has costs. It takes time to download, configure and build. For more or less large and complex product its the quality of the software and the fact that new features continue to be added that make it valuable, not its openness per se. I believe this to be directly related to the fact that someone (or many someone's) cares for it. And more often then not those people can work for commercial company. Why restrict benefits of free software for that category of people ? Commercial developers involvement is valuable also because of the expertise that commercial software brings to several fields were commercial products shine, for example the user interface field. Commercial developers really know about intricacies of creating a usage-friendly GUI  and the end user, because that's were they make their money. If the commercial developers are unwilling to participate in an open source project more often than not this is not only a substantial loss to the movement but might also lead to a loss of quality in certain areas.

Most people and especially academic researchers can and should benefit from free infrastructure (i.e. OS, libraries, component frameworks), but in no case they should be limited by it and the ability to mix free and commercial software is essential for research.  Programmers don't want to reinvent the wheel and this desire contradicts the desire on "purity" that some GPL activists suffer from. If I want to use a proprietary library and release my product as free software, so be it. Right ? Wrong, unless you use dual licensing.  And that brings us to the second part of the problem, the possibility of  GPL

2.6.1. GPL restrictions on the code reuse

Dual licensing is the Perl's way
to disinfect the GNU General Public Virus!
sig in Slashdot postings

As we already discussed  GPL is pretty long and complex document. But the principal idea of GPL is very simple: it is a specific restriction on the reuse of the code in the derived works, that is often (incorrectly) called the "viral property". The GPL does not contaminate code, it only places restrictions on it's re-use, just like BSDL with advertising clause places restrictions on it's re-use:

• 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

... ... ...

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

To a certain extent this restriction binds the software developer to the GPL license for any derived software. Due to the ambiguity of the phrase "or any part thereof"  even fair use seems to be denied (although this can be challenged in the court) and that limitation might affect the original author if he accepted modification/contributions/patches from others that were explicitly licensed under GPL.

And due to the complexity of defining a derived work it is unclear whether the use of any minor GPLed-component (even if a fragment is so small that it falls under fair-use case) makes the software vulnerable to the GPL infringement charges. Actually there is no requirements to release your intellectual property under GPL in case any infringement is found. Contrary to popular opinion (see, for example Microsoft GPL FAQ [Microsoft200]) usage of GPLed components does not converts the program into GPLed work. This is only a violation of the license and the author can just remove offending GPL code. At the same time due to the power of negative marketing (discussed below), such a release might be the easiest and preferred way to cut PR losses. 

What is even worse is that unless you adopt from the beginning a dual licensing strategy, GPLed code from multiple contributors can not be re-released under any other license without the explicit consent of all copyright holders even if the original author changed his mind about preferable license (if the copyright was transferred to FSF then explicit consent of FSF is needed).  At the same time the original author still is free to adopt dual licensing for his own code. Actually most GPL projects have a single author or a principle author with the lion share of contributed code so this problem is not as important as it theoretically appears.

2.6.2. The hostility to other licenses and the dander of the "GPL Jihad"

The term "GPL jihad" encompass both negative marketing and the attempts to fork the product on pure ideological motives, for example if the product changes the license from GPL to BSDL.  That's why a safer way to adopt a new license for already GPLed product is to adopt dual licensing.

The problem of negative marketing are connected with some provisions of GPL, that permit companies to provide some surrogate of IP right protection (economic barrier to the source code access in a form of substantial "media fee", using a specific not so popular media type, etc) but are generally negatively viewed by the "GPL community". For example, nothing in GPL excludes the possibility for the company to provide source code only on DLT tape.  That provides some level of "pseudo IP rights protection" but the question is how effective is this effort against the freeloaders.

The problem is that company that adopts GPL does not control the public view of the license and thus, if the public interpretation of the license is different (and GPL is complex enough license to be interpreted differently in different times), this issues can became a hidden minefield with potential negative PR effects for the company in question.  Also anybody can redistribute the product and that undermines any benefits of "pseudo IP rights protection" like CentOS, and Oracle Linux proved all too well in respect to Red Hat Linux.

But this is only a part of the problem. The second part of "GPL jihad" is that GPL implicitly positions Richard Stallman as a grand arbiter (or Grand Inquisitor ;-). I sometimes wonder if RMS is a pragmatist, who uses consistent and dramatic dogmatism as an artificial mask used to get additional visibility and achieve his financial goals a la infamous Soviet foreign minister Vyacheslav Molotov ("Mister Nyet"). That bring us to the wonders of fundamentalist thinking in a form of "GPL jihad". 

A classic example of this behavior was Stallman's vendetta  toward KDE project [Bezroukov2001a]. As one can see for example from RMS letter of the subject [Stallman2001] and its discussion of Slashdot this case cause substantial PR damage to the KDE project as such can be considered as a classic case of "GPL jihad". Here is one commentary on the KDE problems from Martin Cracauer's GPL Page:

Imagine you want to build a free desktop software. Such a desktop software is built from various tools that are built on top of various libraries (collections of software elements). If you use the GPL as a license for this desktop (that means, for its applications and libraries), you cannot ship applications built from these sources and other sources under licenses with additional requirements.

The UNIX desktop KDE suffered from this problem: KDE was meant to be under the GPL license (that means, the applications and higher-level libraries), but they used a middle-level library that is license-wise incompatible with the GPL. Shipping such software is illegal (except when you ship sourcecode only, not ready-to-run applications, which isn't the right thing for the end-users a desktop is targeted at).

The KDE folks could have changed their license to a non-GPL one, which would solve the problem with the middle-level license. But the GPL with its virus character would still damage such a project. For a desktop software framework like KDE, it is a requirement to take existing applications and change them in a way that the user interface (and other features) are compatible with the rest of the KDE desktop, so that the user finds familiar with all applications on his/her desktop. But if the application to be integrated is licensed under the GPL, it would in turn be illegal to put it together with the imagined non-GPL KDE system. So, the level of "fault" changes, but the result is the same: You cannot legally ship your complete ready-to-run desktop package.

Actually before KDE Jihad I used to support GPL and never thought much about it's more subtle properties[Bezroukov1999a] But it is perfectly true that connection to Anarchism implicitly brings to GPL the level of intolerance that is so common among radical movements.  Just reread the history of Bakunin feuds.  So it's not accidental that somewhat similar occurred in a form a campaign to damage or eliminate KDE as a competitor to Gnome desktop by political means.  Some people think that "KDE Jihad" was accidental and some attribute it to a bad character of Richard Stallman (see Toxic managers  for more details on this personality type), some to the KDE's team refusal to adopt dual licensing with the second license more suitable for their current needs and views  (like Artistic license). But there were several similar less publicized cases including FSF attacks against scripting languages that broke the party line when FSF in the figure of Stallman attacks a free/open product just for the change of the license (that often hypocritically is praised by RMS in public speeches).

The latest one can be called Sun Driver Kit Case; in this case Becker, the author of many Linux Ethernet cards drivers, played the role of  RMS. Sun's driver kit takes any Linux drivers and converts them into Solaris x86 drivers in binary format. Although drivers are under GPL license, but that' perfectly legal to process them with an automatic tool (that can be considered some kind of compiler). It even does not matter if this tool is freely available or proprietary. If we assume that the driver kit is pretty similar to GCC then this respect it no more "encourages" license violations than GCC does. Of course, one needs to distribute the source to Becker's drivers if it distributes binaries (for any system), but that's the user problem, not Sun's problem.  For Sun it was important that the kit lets Solaris users on Intel platform to use a substantial pool of Ethernet cards drivers available for Linux. Formally kit is just a tool and anyone using its kit is responsible for ensuring that how they're used doesn't violate licenses.

This episode also contain an interesting detail that can be considered as the first documented case of GPL attack on the fair use principle. When Sun started showing the kit to developers, Becker one of the main contributors of Linux drivers was one of the first to get it and for some reason he was really upset by the discovery that the kit used his Linux eepro100 and Tulip drivers as examples (which can be considered as an example of fair use). Yes, he wrote and placed his drivers under GPL, but, as we discussed before, GPL by definition does not support any author intellectual property rights. But he became so upset that Sun never asked his permission to use them that he wrote a letter of protest charging Sun with releasing a kit that "was both contributory infringement, and an inducement to infringe" the GPL.

This nice "legalize" wording suggests pretty evolved stage of GPL purity debates. The GPL, Becker says, does not permit distributing the ported drivers as part of non-GPLed code for commercial use. After he consulted "GPL-gurus"  including Bruce Perens it become more and more clear that Sun acted perfectly legally as there are explicit exceptions in the GPL allowing for Sun's ported drivers "as long as the drivers are runtime loading and are not distributed with the kernel."  

Time wise this Sun's "contributory infringement, and an inducement to infringe" coincided with the Napster lawsuit. You can think about Sun approach as a kind-of Napster but in the domain of  kernel drivers. Remember, that the GPL advocates share typical Anarchist believe that Napster is only a channel and it's not Napster's problem that users violate copyright with the service. OK, let's assume that it's not Napster's fault to create a channel for unauthorized distribution of copyrighted works. Then it's really clear that Sun even morally cannot be held accountable for much less problematic and perfectly legal operation and that it did with GPLed software. Sun toolkit is just a toolkit. Any other position looks like a pure hypocrisy. That case also raises questions for the authors of Windows programs that use GPL and proprietary compliers like Microsoft Visual studio.  Although FSF GPL FAQ claims that such usage is perfectly acceptable, fear, uncertainly and doubt remains (after all C and C++ compilers contains macro generators and "impure" Microsoft headers are mixed with the "sacred" GPLed code in the process ;-). That means that from the point of view of its social dynamics GPL is restricting the developers in the use of development tools.

All-in-all the cases discusses above suggest that by adopting/preserving GPL license for a successful product a developer can easily step on the rake of the negative marketing complains that will damage his and/or his company credibility even if in fact GPL was never violated  explicitly. Moreover those cases make the implicit pro-cooperative stance of GPL look rather fuzzy, especially in the ability to other developers to projects that achieved a mature stage.  Commercial developers are well advised to think twice even if the do not plan to reuse any of the contributed code. This GPL "feature" was pointed out by   Guido van Rossum in his paper Python Licensing Issues:

In any case we don't want to use *just* the GPL for Python, because there are many proprietary software developers in the Python community who don't want to work with the GPL. Python has always had a BSD'ish license which was perfect for them. I see no reason to suddenly confront everyone in the Python world with the GPL.

Conclusions

The main idea of the paper is to provide to free/open developers some additional context about possible consequences of choosing BSD license or GPL for their products. The analysis remains incomplete and fragmentary (that's why the paper was called "Notes") but I hope can provide initial framework for further more complete analysis of issues involved. I think it is important to understand that the social roots of GPL and BSD licenses are connected with concept of programming intelligentsia. Also software licenses should be viewed  not statically (as a something that has forever fixed properties), but dynamically in the context of the programming project life cycle and social environment of the developer. I feel that the following ideas of the paper might serve as useful starting points for future researchers:

• One can view any license including BSDL and GPL as a dynamic social process (or even an algorithm) that behaves differently depending on a stage of the development of the programming product and the social environment of this development.  There are certain dangers in use GPL as soon as the project involves more then one developer (many projects never reach this stage). 
• GPL may provide some (limited) advantages on the early stages of the development of the product especially for authors who are working in the corporate environment, while BSD is more suitable for academic developers (especially working of research project sponsored by the government) and for mature stages of the projects. Thus the developer may benefit from switching of dual licensing scheme due the changes in his environment and/or at the appropriate point of the development cycle. Several such cases were documented in the literature and all proved to be successful.
• Neither BSD nor GPL addresses some important concerns of the free/open software developers including but not limited to such the vital for free/open community questions as:
  • Adherence to standards (Stallman successfully used "embrace and extend tactic" in GCC and other products)
  • The idea of the conformance to interface specifications (for example for GUI programs) or at least to the reference implementation. For example one of the problem in more widespread usage of Linux on desktop is that Linux GUI applications are a huge mess because each of then has their own set of hot keys and the idea of the interface; this variety is less in applications specifically written for Gnome or KDE, but still it is exists. 

All-in-all my analysis suggests that the comparative advantages of each license in the BSD-LGPL-GPL line might be significantly influenced by three factors:

• Types of programming projects. The closer the product is to a reusable component (for example, library) the less attractive GPL became. For example the approach advocated in the paper suggests that GPL serves very well for gcc, reasonably well for Linux kernel and bad for Gnome. A well known version of GPL called LGPL was created specifically to fix this issue for the libraries and might be useful as a compromise license for intermediate stages of the development of the project. 
• Developer's programming environment. Licensing issues seems to depend whether the developer belongs to the academic environment or a corporate environment. Paradoxically it might be that the latter provides some incentives for GPL usage in the initial stages of the project. 
• Stage of the software life cycle the project is in. As the software product mature the BSD license became more and more attractive and free/open developers of important GPLed products should consider the possibility of moving to this license.  The author think that GPL is a promising "abandonware" license and can be successfully used in opening of some types of commercial software.

This approach is extendible to other licenses.  The key idea here is that the value of the license should be measured by its ability to improve chances for the success for the free/open software and no license should be considered as a sacred cow.

The considerations raised in the paper suggest that Perl's idea of Artistic license and dual licensing represent an important and novel approach to overcoming some of GPL's problems and may be further extended to provide a balancing approach to free/open licensing; for example Perl's ideas can be easily extended along the lines of Sun Industry Standards Source License (SISSL) to improve the adherence of standards for derivatives, the requirements that is very important to free/open developers.

Dual licensing also might help to better balance the conflicting requirements of  four major categories that compose social environment of the free/open project: the author, co-developers, creators of derivative products and the users. The latter question will be further analyzed in the next part of the paper. It's a safer way to adopt a new license for already GPLed product .

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019