Open Source Licensing (Book Review)

February 2005

Open Source Licensing: Software Freedom and Intellectual Property Law by Lawrence Rosen;

Prentice Hall Professional Technical Reference $39.99; 396pp

Readers looking for a quick background on the issues can look the two licensing chapters in my Open Source: the Unauthorized White Papers, now on line at The first chapter of the book gives a short history of Open Source.

A Complete and Thorough Book

"One of the challenges to writing about licensing in a book not specifically written for licensing professionals is to make a very dull subject interesting," (p. 142). Lawrence Rosen has met that challenge in his exciting guide to the zoo of Open Source licensing. As an extra benefit he offers a set of five Open Source Principles so clear and brief that the Open Source Initiative (OSI) would be well-advised to adopt them, and two new licenses intended to solve not only weaknesses of some of the current Open Source licenses, but also resolve the many problems that revolve around the Free Software Foundation’s (FSF) GNU General Public License and Lesser General Public License.

This clear book spends 314 pages in detailed discussion of more legal issues than this review can mention. The author has the advantage of having trained and worked as a programmer and so as a lawyer he is not flummoxed by complex technical issues. He is also uniquely qualified by his long tenure at the Open Source Initiative, where he served as General Counsel and as Executive Director, participating in many discussions there on licensing and building a wealth of experience to mine for this book. Everyone involved at all with Open Source software should read the first three chapters as background to understanding its larger issues, and the remainder of the book should be mandatory for all persons and firms actually producing Open Source software, whether as coders or as managers.

The book approaches the licenses in chronological fashion, showing early starts and subsequent improvements. To oversimplify, the BSD License began by imposing no limits on the licensee; the MIT, or X License added clear copyright language; and the GNU General Public License added the requirement that code be shared. Subsequent licenses have added patent defense and warranties of code provenance. Over fifteen years later we are faced with dozens of licenses and conflicting opinions (none of them judicial) about how software developers and firms are supposed to stitch together code under them.

The book is quite lucid as Rosen takes the reader through such basics as that different laws apply to the intellectual property (IP) of software and to the tangible copies of software, that copyright does not protect the ideas in software (patents do that), and that there is a difference between a (bare) license and a contract (containing a license). Along the way important points emerge: although a bare license (like the GNU GPL) can be revoked because it is not a contract for which consideration has been received (typically a payment), the law would recognize the user’s dependence on the software to act as a substitution for that consideration, so that in practical terms the license could not be revoked (p. 56). Of even more fascination for Open Source developers is the discussion of joint works vs. collective works: if developers agree among themselves (contract) to undertake a project, then as owners they can each license the entire joint work to others as they individually see fit; if there is no such contract, the work is a collective work (a collection of unmodified pieces), each of which is under its author’s respective license. Most Open Source projects are joint works, and generally speaking Rosen sees no reason for the typical project to assign copyrights rather than retaining them individually. In the case of a collective works, the collector is the author and can license and distribute it, but only if he has license to distribute from the authors of the constituent pieces themselves.

Neither joint nor collective works are derivative works. A derivative work is a new work by an author that is based on a pre-existing work. The author of the derivative work can license and distribute the derivative work provided he has license for the pre-existing work to create a derivative work from it and to distribute that derivative work. These distinctions are of crucial importance in Rosen’s views on the Free Software Foundation’s interpretation of its GNU General Public License (GPL).

But it is not simply the examining and clarifying of these and many other topics that is the heart of the book; it is Rosen’s relentless categorization of the licenses into types and categories, such as Template Licenses (Apache, BSD, MPL) that may be used by others simply by changing the names; and the most important division among them: Academic vs. Reciprocal Licenses. Briefly, Academic Licenses originated in institutions of higher learning (Berkeley, MIT) and sought to provide the widest distribution possible for the software; there are no real restrictions on its use, rewriting, and dissemination. Reciprocal Licenses (most famously the GNU GPL) require that anyone distributing the software offer the source code for the entire work as distributed, including all changes. Rosen regards Academic/Reciprocal as the heart of software freedom, and most likely to lead to rapid technological advance and increased productivity for everyone.

To promote this software freedom, Rosen has developed Five Principles of Open Source Software. Although Rosen modestly indicates that the five principles are for the convenience of the reader of his book, they obviously have wider application and deserve wider dissemination. As stated briefly on the cover, they hold that "Open Source licensees are free to

Use open source software for any purpose

Make and distribute copies

Create and distribute derivative works

Access and use the combined source code

Combine open source and other software."

It is worth examining how Rosen’s extensive experience with Open Source licensing and the OSI and his study of the development of these licenses have led him to his Five Principles and to the two new licenses he introduces in the book. From the point of view of lawyers and businessmen (who engage lawyers to ensure the legality of their actions), Open Source licenses originally lacked provisions and protection for important IP areas such as a clear chain of licensing, trademark protection, patent defense, and standards.

Rosen develops the term chain of licensing from the real estate "chain of title," which must be proved good for the property to safely change hands. For software it describes the ownership of a derivative work of OSS; what the latest modifier is allowed to do depends on whether he has a license to do so from the copyright holders of the work he modifies. Most Open Source projects simply point to a place where a license is easily obtainable, but don’t bother to grant it specifically. Furthermore, it is often difficult to determine exactly what software is covered by the license, thanks to vague language, such as the MIT License’s reference to "this software." As a consequence, the cautious developer or company will need to explore the whole chain of licenses to determine exactly what is covered and under what license.

The GNU GPL deals with this problem by granting all licenses directly from the copyright holder; this solution turns out to be awkward because it does not provide for sublicensing, which would itself provide a clear chain of licensing from original author to latest modifier. A number of licenses do not address the problem at all because they neither take the GPL nor provide explicitly for sublicensing. Notice that there are different solutions to securing the original right to license the software: The Free Software Foundation requires that copyrights for contributions to its projects be turned over to become the property of the Foundation, giving it clear title and right to license the software; the Apache Software Foundation (ASF), on the other hand, leaves the copyrights in the hands of its contributors, and requires from the contributor only a license for the ASF to distribute the contributed code under the Apache License.

All of this discussion of the chain of licensing is central to another issue that businesses have with Open Source software: the usual Open Source disclaimers of any warranties and liability. This approach works in a narrow community focused mostly on internal software development, but as Open Source becomes the motor not only for software businesses, but for all businesses, the questions of software provenance, warranty for that provenance, and liability for falsely asserting that warranty become burning questions. And yet warranties and liabilities for only the provenance of the code are not enough; there must be also be assurance that the licensed code does not infringe any copyright or patent. As software companies know, the copyright part is easy but the patent part is the devil. In the absence of a patent warranty the recipient of the code must either do his own due diligence or buy insurance (and yes, that niche is being filled, initially by The Mozilla Public License (MPL) was the first to address the patent defense question, and a few others have since followed.

Finally, trademark protection goes unprovided for in a number of licenses. The Apache License was the first to do so: one must distribute modified Apache code without calling it Apache; only software directly from the Apache project (and exact copies of it) may use the name.

Having been diligent about the license, the software provenance and chain of licensing, and the warranty and liability questions, the developer who wishes to modify Open Source code comes to the Big Question: Under what license(s) may the resultant software be issued? Are any of the licenses compatible with each other? This is the toughest question in the book, and before we get very far into it, we need to take a look at how we ended up in this situation.

The Ancient Legacy

Outsiders might think otherwise, but Free or Open Source software has been around a long time. The Free Software Foundation and its GNU General Public License go back to 1985, Linux first emerged on the Internet in 1992, and the Open Source Initiative (from which Open Source software takes its name) was formed in 1998. In terms of the speed of technological development and particularly of Open Source, these are long times indeed. Unfortunately the two institutions that originated to promote Free and Open Source software have lagged behind. While neither needs to be abolished, they both need reformation.

Open Source Initiative

The Open Source Initiative was founded to overcome the business community’s mistrust of Free Software; their correct reading of the manifesto at the head of the GNU General Public License was that the Free Software Foundation hoped for the eventual disappearance of proprietary (binary-only) software (explicitly in Recognizing that Linux would never become mainstream so long as business were allergic to the GNU GPL, the OSI was formed to evangelize the benefits of source-code availability, and to point out that there were other licenses besides the GPL, licenses that offered the ability of open-source software to combine with proprietary software.

Although the Open Source promotion campaign had no budget to speak of, it was a major impetus in moving Linux into the mainstream of business use and the term so deeply into the language as to lose its capitalization in much modern usage. But the OSI moved from evangelism to ecclesiasticism, and in the course of creating a rival to the narrowness of the Free Software Foundation ended up creating a cathedral where software must send its licenses for blessing. The Open Source Definition (OSD), ostensibly adopted because it "spells out the essential qualities of open source software" (, evolved from a guide to become a decalogue to determine what was and what was not Open Source. The OSI regretted that the term "Open Source" could not be trademarked and turned into a brand, and another approach to control was found: "Since the community needs a reliable way of knowing whether a piece of software really is open source, OSI is registering a certification mark, OSI Certified, for this purpose." It was to mark software "distributed under an OSI approved license."

Although the chronological existence of the OSI has been short, it has managed with limited resources and enthusiastic volunteer help to officially approve nearly sixty software licenses. This has led to confusion in the very industry that the OSI is trying to convert to Open Source software. But this is not the only fence the OSI must straddle: the tension between openness and centralization also reflects itself in the process by which licenses are approved and disapproved. There is a discussion list where the merits and failings of candidate licenses are discussed, but the approval decision is not reached there, and the new Sun license for an open source Solaris has never appeared there. Presumably the OSI Board makes these decisions, for there is no decision committee listed. The Board itself has five members, of which three are employees of Sun, IBM, and Red Hat (and two new OSI attorneys have just been added to the Board). There is no list of rejected licenses, and thus no reasons for their rejection, leading the uninitiated to believe that any license or software not bearing the OSI certification mark is not Open Source. Adding exclusivity and secrecy to licensing proliferation is a poor way to promote the Open Source message of freedom and do-it-yourself.

But there is hope for change within the OSI. It has tweaked the definition of its Open Source Definition over ten times over the years, showing a capacity for adaptation and improvement. More significantly, among the many licenses it has approved are Rosen’s OSL and AFL, which offer great hope for the logjams presently occurring between proprietary and Open Source software. In fact, the OSI places the content of its Web site under both licenses, take your pick. It only remains now for the Board to quietly retire the Open Source Definition and to adopt Rosen’s Five Principles in their place, and to recover its original evangelism by drawing the world’s attention to Rosen’s OSL and AFL licenses.

The Advantages of Rosen’s Five Principles and his New Licenses

The Five Principles incorporate the spirit of the Open Source Definition, and have the virtues of brevity, both in number and wording; simplicity of expression (as opposed to the restrictive detail of the OSD), and the force of legal experience and opinion behind them. The licenses themselves are concise and address all the legal problems that Open Source software faces in a world of sharp-eyed managers and attorneys. The Principles should not provoke long discussions of their exact shades of meaning, as do the articles of the Open Source Definition.

Until this point in Open Source software licensing, Academic Licenses (such as BSD, MIT) and Reciprocal Licenses (such as GPL) have gone down separate paths. Rosen’s Open Source License (OSL) and his Academic Free License (AFL) have very similar wording in order to cross-pollinate between the two categories, and to make simple and clear the differences between the two licenses. Each of the pair addresses issues of great concern to businesses and their attorneys. Both deal straightforwardly with many issues often or completely neglected in Open Source licenses until now: trademarks, patents, contract vs. bare license, provenance (the chain of licensing), warranty, and application service provider (ASP) software, all the while providing recognizable continuations of the Academic and Reciprocal licensing traditions.

They differ only in the OSL’s demands for reciprocity; otherwise

Both are unilateral contracts: the licensor makes promises and sets conditions that must be met in order for the licensee to enforce the promise.

Both require distributors of the software to "make a reasonable effort . . . to obtain express consent" to the licensing terms

Both cover all five rights under copyright: to make copies, to prepare derivative works, to distribute those copies and derivative works, and in the case of content to perform publicly (music, drama) and to display publicly (art).

Both grant patent licenses for the original software.

Both expressly:

allow "you" to use the software; the definition of "you" includes corporate entities

allow authors to license the work under other licenses in addition to the OSL/AFL

require retention of copyright/patent/trademark notices in the work

warrant provenance of the work (the licensor warrants that he has the right to license to you) and disclaim other warranties (the software is accepted AS IS).

Both require that appropriate documentation accompany the source code (just as in a software escrow agreement)

Both allow copyright law and courts to define what a "derivative work" is, thus bringing a long legal tradition to apply to Open Source software

The short way of telling the licenses apart is to remember Rosen’s distinction between Academic licenses (maximum freedom of reuse) and Reciprocal licenses (if you distribute or modify, you must share modifications and all the source code). This distinction between the two licenses is established by making only two changes in significant wording between the OSL and the AFL:

The OSL requires that all copies of the original work and derivative works be distributed under the OSL

The OSL adds a definition of external deployment embracing all distribution, even if the original or derivative work is "made available as an application intended for use over a computer network." The definition of "you" in both licenses makes clear that distribution within a company is not "distribution" that would invoke the reciprocity clause in the OSL, but its "network" language makes it clear that a company may not modify OSL-covered software and then make its use available as ASP to those outside the company.

The simplicity and elegance of these licenses attests to Rosen’s years of experience in these matters, and the attention to ASP distribution in the OSL is not only derived from the ASP provision in the RealNetworks Public Source Licenses (, but solves the very issue that the FSF has spent years wrestling as it tries to finish version 3.0 of the GNU GPL.

Toward a GNU GPL 3.0

The GNU General Public License (GPL) is the ancient legacy weighing most heavily on the wider acceptance of Open Source software by business. The license hampers not only because of its political polemics, but also because of its idiosyncratic interpretation of copyright law. So difficult is the license to understand that the FSF holds seminars for lawyers to explain the GNU GPL to them, and presumably to explain the Foundation’s views on copyright law. Additionally the FSF has been trying for years to write a new version of that license that will reduce circumventions, match previous versions seamlessly, and take new software technologies and practices into account. But all of these difficulties could be overcome and the Free Software Foundation could achieve its goals of Software Freedom ( while assuring much wider use of software presently covered by its two licenses, the GPL and the LGPL. In addition, the essential redundancy of the LGPL would be eliminated.

The shortcomings of many of the Open Source licenses generally have been touched upon above. The FSF licenses share many of these traits, and their effect is compounded by the FSF’s rigid refusals to accept licenses such as the Apache as compatible with the GNU GPL. The Foundation rejects the Apache license’s simple statement of the facts of trademark law (no use of Apache trademark without permission if the software is modified) and its patent language. The long list of licenses found to be incompatible with the GNU GPL ( necessarily limits the combination of GPL’d software with much Open Source software. As a result, businesses users remain skeptical of using software under FSF licenses. The GPL’s preferential terms for "noncommercial distribution" add further to the unease because the term the term "noncommercial" is not defined. All these features (or defects) of the GPL add to the drag in adoption that Open Source software is currently feeling.

The root of all these problems is the attitude of the FSF toward derivative works, which it does not distinguish from collective works. Treating collective works as derivative works is part of the FSF strategy to pull proprietary software into the Free camp by requiring a GPL license for software that links to software under the GPL. The simplest demonstration of this proposition is its exception: the LGPL. It is the FSF’s pact with the devil. In its desire to see the GNU C library (glibc) widely used, the Library General Public License was devised to enable proprietary software to link to this GNU software. The downgrading of this license’s name to Lesser General Public License, and the strong advice not to use it at all ( are part of the FSF strategy to unlock proprietary software. This overreaching zeal has led the FSF into the legally untenable ground of forbidding linking to GPL’d software, and it is time for the FSF to pull back and align itself with copyright law concerning derivative works, a topic well-known to copyright lawyers and courts. The FSF’s interpretation of what constitutes a derivative work is a fork from copyright law, a fork that needs to be healed and the FSF pulled back into the main tree of the copyright laws upon which all GPL’d software depends for its licenses.

Rosen is too polite to call for replacing the FSF licenses with his own, but in his Chapter 6: Reciprocity and the GPL, he makes many observations, including:

1) The FSF’s refusal of outside improvements to the GPL and its denunciation of them as "restrictions" handicaps the GPL in the courts: "Their avoidance of restrictions has delayed the adoption of new and useful licensing concepts for open source software." (p. 106). These "restrictions" are actually items such as clear grants of patent licenses and the like.

2) The FSF language about software "containing" GPL’d software tries to turn collective works into derivative works, and is contrary to the usual practice of copyright law (p. 114).

3) Further instances of unclear language that vary from simply untrue (the GPL mandate that "you must give the recipients all the rights that you have," says Rosen, "is unnecessarily frightening and is not true"--because you still have the right to give the work to others, p. 111) to inept (the provisions for linking to LGPL’d code is "an impenetrable maze of technobabble," p. 124).

4) The FSF’s ideas about linking to GPL’d software (see 2) and 3) above) conflict with copyright law and practice to the extent that there is no need for the LGPL because a user who does not modify a GPL’d work of software, but simply incorporates it into a collective work and distributes it, is well within copyright law. This means, simply, that one can link to GPL’d software and distribute the collective work. If the software has a use, simply using it is permitted under copyright law.

The problems resulting from the FSF’s unwillingness or inability to bring their GPL/LGPL licensing into conformity with copyright law, and with modern software licensing practice under that law, will lead it into eventual disrepute. So far the FSF has been scrupulous about avoiding court, relying on quiet persuasion that moves over to loud public indignation and pressure on the infringer from many quarters, and it has been successful so far. But its reputation for ferocious fanaticism frightens away not only those who would abuse the GPL, but also those who can’t come to terms with the FSF’s interpretation of its licenses. By holding the opinion that a collective work is actually a derivative work (and therefore violates the GPL) the FSF invites gradual and then wholesale violations of the GPL, and increasing difficulty in determining which cases will be defensible and which will have to be ignored in order not to expose the FSF’s interpretations to adjudication.

In cases in which the FSF is not the copyright holder, and therefore lacks standing in court, the actual copyright holders will have to reach the same decision about bringing an infringement suit. The worst case would be that of distributing binary-only software linked to unmodified GPL’d software. A good prediction of the outcome would be that the GPL will be found invalid in some way. First, for its ambiguities: courts decide in favor of licensees if the licensor has not written a clear license. Second, for its clear misinterpretations of copyright law. Rosen believes that the courts will favor the GPL’s restrictions on derivative works, but not on collective works. Beyond this fairly clear risk is any additional court finding concerning the GPL, for no one ever really knows what a court will decide.

In any case the GPL will have been exposed as a paper tiger, the result of a too-wide stretching to achieve the death of proprietary software. No one in the Open Source world wants a public and legal repudiation of an archetypal Open Source license. The sensible thing would be for the FSF to adopt Rosen’s Open Source License, and for everyone who has put out software under the GPL to relicense it under the OSL.

The FSF believes that the current version of the GPL has problems, but does not see the issues raised above as problems. Instead it is troubled by evasions of the intent of the FSF in the form of object-oriented programming and ASP applications. For some years now the FSF has been at work in secret (outsiders may not see drafts) on a version 3.0 of the GPL trying to solve these problems while still keeping version 3.0 with the two previous version. The FSF likewise believes that all of these problems are the result of its efforts to keep code Free in the sense that received source code must never be distributed (modified or not) in a binary-only form; source code must always be available (that is, Free).

But the FSF could with one stroke solve all of these problems. It could clear up its anomalous stand on derivative works, encourage the wider use of Free software by ceasing to frighten potential users (it is at the point now that software suppliers for OEM use must warrant that there is no GPL’d software in the offering), and still keep the source code Free. This requirement for source code availability is what Rosen calls Reciprocity, and the simple step would be for the FSF to replace the GPL and LGPL with the OSL for all of the software on which it holds the copyrights, and to encourage parties using the older licenses to relicense under the OSL. By this means the FSF would gain respect, avoid the inevitable court struggle, and promote the spread and creation of Free software. Acknowledging that it is legal under copyright law for GPL’d libraries to be called by proprietary software would accelerate business use of Open Source software and increase software productivity ( "Rolling your own software" is now increasing thanks to Open Source and the decline of the big CRM vendors.

There may be an opportunity for the FSF to make this move. Although it has rejected an earlier version of the OSL as incompatible with the GPL, the FSF has not yet spoken on version 2. But since the copyrights to the vast majority of software currently under the GPL are not held by the FSF, its approval of the OSL, while desirable, is not necessary. Not only can copyright holders re-license from the GPL to the OSL, bold parties wishing to call the APIs of GPL’d software can simply exercise their rights under copyright law and wait to see who will object in court. Open Source software has long since moved beyond the hobbyist and enthusiast stage and, as many of its creators and proponents have dreamed, is spreading in wider circles of freedom and productivity around the world.

Now that the OSI and and FSF have had recent changes in leadership, this would be a good time for both to catch up with rapidly-moving world around them. The OSI needs to move away from license proliferation to its original promotional purpose, this time emphasizing the Five Principles and the OSL and AFL. The FSF that its problem is not Reciprocity, but the GPL, and move to the OSL.

The great service of Rosen’s book is not just in explaining Open Source licensing, copyrights, patents, and standards; it is offering the evidence and opportunity to take great steps forward for the propagation and use of Open Source software.

Donald K. Rosenberg is president of Stromian Technologies, a marketing consulting firm specializing in OEM software licensing and Open Source licensing and marketing issues. He is the author of Open Source: The Unauthorized White Papers, (Wiley), a book taking a business approach to Open Source software, now on the Web at and
Don has twenty years of marketing experience and has worked with companies large and small in the U.S. and Europe, both in Open Source and proprietary software licensing and marketing. Besides consulting on these issues, Don has given talks about them at USENIX, ALS, LinuxWorld (San Francisco, Frankfurt/M), Wizards of OS (Berlin), CeBIT (Istanbul), Comdex (Las Vegas, Basel), and in Taiwan and Slovenia. His column, Rosenberg's Corner, deals with Open Source and business issues

© 2005 by Donald K. Rosenberg

Return to Rosenberg's Corner -- Topics