Book Review: Open Source Licensing

Lawyers and programmers have at least one thing in common: their day-to-day work puts them in contact with issues that seem obscure and esoteric to the general public. That makes the terms of open source licenses doubly difficult to understand, but Lawrence Rosen does an admirable job explaining them in his book.

Published by Prentice Hall in 2005, the book obviously doesn’t contain any open source license versions that were created after that time. So the latest revision of the General Public License (GPL), created in the wake of a Microsoft-Novell deal with disturbing implications for open source software, is not in here. But that hardly matters; this book is about the principles on which open source licenses are based. While those can certainly change, they haven’t changed enough since the time this book was published to make it any less relevant today.

There is no question that Lawrence Rosen is the right person to have written this book. He is a founding partner of a California-based technology law firm specializing in intellectual property protection, licensing and business transactions for technology companies. The Open Source Initiative (OSI) has benefited from his expertise, as have the Apache Software Foundation and other open source projects. But before he turned to law, Rosen belonged to the world of computers; he managed computing activities and taught computer programming and database design at Stanford University; he also worked in industry where he coordinated the design, development, manufacturing and marketing of data communications products. If anyone can understand the intersection of the legal and technological worlds brought about by open source licensing, surely it is Rosen.

In his acknowledgments he mentions that he had "the great good fortune to learn about open source from the leaders who created it" and lists some of most prominent names in the open source software movement, including Bruce Perens, Eric Raymond, and Richard Stallman. That gives Rosen added authority when he takes apart various open source licenses later in the book and talks about their creators’ intentions.

The book covers the topic in 13 main chapters, plus extensive appendices that include verbatim copies of every license covered in the book. There is also a fairly complete index.

{mospagebreak title=Setting the Context}

If the open source movement were a person, he’d not only be old enough to drink, his mother might be wondering why he wasn’t at least dating seriously yet. It was born in 1989, with Richard Stallman’s release of his GNU project software under the first version of the GNU GPL. Bill Joy released a free version of UNIX under the University of California’s Berkeley Software Distribution (BSD) license. Not surprisingly, these two licenses are among the first ones discussed by Rosen, but before we can get that far, there are certain concepts we need to understand. Rosen builds the foundation we need in the first four chapters of the book.

You see, as Rosen explains, "This book is about the law but it is not written for lawyers." It is written for programmers, and it’s apparent that Rosen hopes to provide some clarity for those who are thinking of contributing to or even starting their own open source software projects. These are important decisions with legal consequences, and any programmer who doesn’t understand the legal concepts before contributing to or starting such a project may be courting disaster.

The first, fairly short chapter focuses on definitions. In particular, it explains what is meant by "software freedom" and how it is different from other legal concepts, as when an item is said to be "free of defects." It also explains the necessity of coining the term "open source," and gives the ten-point Open Source Definition from the OSI. He then simplifies things for his readers by explaining five open source principles that are consistent both with the OSI’s definition and the Free Software Foundation’s principles. He refers to these five key principles throughout the book.

In the next chapter we enter the legal world. Specifically, Rosen discusses the principles and key concepts surrounding intellectual property. He uses the metaphor of left brain and right brain to help explain the difference between what can be copyrighted and what can be patented, and why software can be said to have elements of both. This of course leads to a discussion of the rights of copyright holders and patent owners, collective and derivative works, the chain of title for patents, and so forth. Rosen’s writing style makes it much more engaging than it sounds.

The third chapter is devoted to distribution of software and the unique issues that open source software faces in this regard. "What is unique about the open source process is that once software has been licensed under an open source license, the collaborative process is no longer tied to a single individual or company." Rosen explains the implications of this difference, and also has some reassuring words for those of us who merely use open source software rather than create or distribute it ("All open source software, whether licensed under academic or reciprocal licenses, can be freely used by anyone, anywhere, for any purpose whatsoever.").

The fourth chapter provides the legal meaning of "license," as well as related terms. Here we delve into contract law and touch on warranties as well as issues of offer, acceptance, and consideration. Now we’re ready for the rest of the book.

{mospagebreak title=The Licenses}

Rosen spends the next five chapters discussing the major open source licenses, spending an entire chapter on each type. The first type he covers is academic licenses, the BSD license being the most famous example. He talks about the GPL in chapter six, the Mozilla Public License in chapter seven, the Common Public License in chapter eight, and the OSL and the AFL in chapter nine.

Of all of the types of open source licenses, academic licenses are the least restricting. Software created under such a license can be used in almost any way; licensees can even take such software and use it later in proprietary products. Rosen strongly contrasts that with what he characterizes as the reciprocity bargain of the GPL, which he paraphrases as "You may have this free software on condition that any derivative works that you create from it and distribute must be licensed to all under the same license." It’s because of the GPL, he explains, that we have two rather than one public commons of free commons. Software licensed under an academic open source license can be incorporated into a GPL project, but not vice versa.

Rosen also capably covers the political stance of the creators of the GPL, despite the fact that it is, he admits, irrelevant to the legal issues. Rosen also covers the Lesser GPL, designed to address the distribution of software libraries, something the regular GPL does not handle well. This is where the distinction we learned in chapter three about derivative works vs. collective works comes into play. He even touches on the economics of the GPL, since it specifies that derivative works must be licensed at no charge; as it turns out, there is an escape clause of sorts.

The other three chapters cover the continuing evolution of open source licenses, as programmers became savvier about the law; for instance, the MPL was one of the first licenses to explicitly grant a patent to licensees as well, and in fact deals with patents much more thoroughly than the open source licenses that came before it. Rosen has some good words for the CPL; unlike the GPL and BSD licenses, this much more modern open source license was actually created by lawyers (IBM’s lawyers, to be exact), so its use of the language is particularly clear – in a legal sense, in any case. For example, "the words shall and must and may not always mean something mandatory, and the word may is always permissive." His discussion of the OSL and the ASL is more intricate in some ways than his earlier chapters, because those two licenses were intended to bridge the academic/reciprocal divide; still, he compares them point by point to each other and to other licenses, which helps in comprehension.

{mospagebreak title=Decisions and Hazards}

The final four chapters cover choosing an open source license for your projects; licensing models other than open source; open source litigation; and open standards. In the first of these chapters, Rosen talks about what issues are usually taken into consideration when choosing an open source license for a project. In particular, he deals with the free-rider problem and how to make money from open source projects. Themes that were discussed earlier in the book (i.e. collective vs. derivative works, license compatibility, etc.) also reappear here.

In the second chapter of this section Rosen talks about alternatives to open source licenses. He covers Microsoft’s shared source; public source, which allows licensees to make copies, create derivative works, and distribute their works, but draws the line at commercial uses for the software; and several other models as well. Rosen even discusses the special issues of combining licensing models, as Jabber has done with its instant messaging software (the client versions are open source, but the server versions are not).

Obviously, anyone thinking of licensing an open source project should read the chapter on open source litigation. Rosen covers SCO’s litigation near the end of the chapter (though keep in mind the publication date of the book) but before that he takes a look at the likeliest issues to come up. He ends this chapter with the comforting knowledge that "as long as licensees honor the conditions of the licenses for software they accept, there is little reason to fear it will be taken away through litigation."

In the final chapter Rosen discusses open standards, distinguishing them from open source. He covers what open standards are, and how they interact with open source software. He also explains how open standards are enforced, how forks are discouraged, and more.

Rosen writes in an engaging, approachable style that can make even the subtlest distinctions clear. With the popularity of open source software and open source projects continuing to grow, this book belongs on the shelf of any programmer who desires to contribute to, or start, an open source software project.

Google+ Comments

Google+ Comments