By Andrew M. St. Laurent
Price: $24.95 USD
£17.50 GBP

Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: Open Source Licensing, Contract, and Copyright Law

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Open source licensing and development approaches have been challenging and transforming software development for decades. Although open source licensing is often described as radical, it is built on solid, traditional legal foundations, including the rights granted by copyright under the law of the United States (and elsewhere), and the ways in which basic contract principles can alter and supersede those rights.

Under the laws of the United States (and of European countries, through the Berne Convention, and of members of the World Trade Organization through the WTO Agreement on Trade-Related Aspects of Intellectual Property Rights), copyright is automatically attached to every novel expression of an idea, whether through text, sounds, or imagery. For example, the words in this paragraph are protected by copyright as soon as they are written. This also applies to diary entries, letters, song lyrics, and drawings, even if they are only done "off the cuff," in the most casual of circumstances.

For example, a drawing of a dog made on a café napkin is copyrighted simultaneously with its creation and is the sole property—barring any contractual abrogation of the copyright—of its creator. This drawing cannot be copied, displayed, or otherwise commercially exploited by any person other than the creator for the life of the copyright. Among other things, no person other than the creator has the right under copyright law to create "derivative works"—works that depend upon or develop from the original, copyrighted work. This limitation is of particular significance to open source licensing, as will be explained later. In the United States, the period protected by copyright is very long indeed: the life of the creator plus 70 years, or in the case of works made "for hire" or by creators who are not identified, 95 years from the date of publication or 120 years from the date of creation, whichever is shorter.

This does not mean, of course, that the creator of this drawing has a monopoly on the depiction of dogs. Copyright law does not protect any particular idea. Rather, copyright protects only the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Basic Principles of Copyright Law

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Under the laws of the United States (and of European countries, through the Berne Convention, and of members of the World Trade Organization through the WTO Agreement on Trade-Related Aspects of Intellectual Property Rights), copyright is automatically attached to every novel expression of an idea, whether through text, sounds, or imagery. For example, the words in this paragraph are protected by copyright as soon as they are written. This also applies to diary entries, letters, song lyrics, and drawings, even if they are only done "off the cuff," in the most casual of circumstances.

For example, a drawing of a dog made on a café napkin is copyrighted simultaneously with its creation and is the sole property—barring any contractual abrogation of the copyright—of its creator. This drawing cannot be copied, displayed, or otherwise commercially exploited by any person other than the creator for the life of the copyright. Among other things, no person other than the creator has the right under copyright law to create "derivative works"—works that depend upon or develop from the original, copyrighted work. This limitation is of particular significance to open source licensing, as will be explained later. In the United States, the period protected by copyright is very long indeed: the life of the creator plus 70 years, or in the case of works made "for hire" or by creators who are not identified, 95 years from the date of publication or 120 years from the date of creation, whichever is shorter.

This does not mean, of course, that the creator of this drawing has a monopoly on the depiction of dogs. Copyright law does not protect any particular idea. Rather, copyright protects only the expression of that idea. The creator of the dog drawing has a right to the commercial exploitation of only that particular expression of "dog." This right is no limitation on the right of others to create, and to commercially exploit, their own expressions of "dog," whether through drawing or other media. This limitation to expressions excludes protection from copyright of creations that are not expressed in a tangible, reproducible medium. For example, a dramatic monologue read on a street corner is not protected by copyright. However, if a reading of that monologue is recorded, whether on audio or videotape or paper, it is subject to copyright protection.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Contract and Copyright

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the United States, all of the rights belonging to the creator of a work become theirs at the time of the completion of that work in a fixed medium. No registration is required, nor does any signed writing need to be executed in order to preserve those rights. Rather, these rights arise entirely from the operation of the statutory law.

Creators rarely take advantage of these rights by themselves, however. The production and distribution of works on a large scale has historically been capital-intensive, so creators of works have generally relied on others to produce the physical copies of their works and distribute them. The idea of copyright developed in parallel with the development of the printing press in the fifteenth century, and it originally protected the rights of printers to exclusively exploit works that they had commissioned. Legal enforcement, and, in particular, international legal enforcement, being what it was in the fifteenth and sixteenth centuries, copyrights were frequently disregarded. Of course, given the systematic violation of copyrights in many parts of the world today, it can be argued that the situation has not changed that much.

The relationship between the creator of a work and its publisher is often an uneasy one. The creator, naturally, wishes to retain both control over the use of the work and the income stream derived from commercial exploitation of the work. The publisher, whether a book company, a record label, or a film studio—to take three common examples—similarly wishes to retain exactly those same things: control over and income from the work. Because publishing (in whatever format) is a capital-intensive business, the dynamic tends to strongly favor the publisher over the creator of the work, except in the exceptional case of creators who have both a proven track record of generating income from their work and, perhaps more importantly, the ability to negotiate without restriction. The case of musicians and their battles with record labels is particularly well-known.

The most typical trade made between creators and publishers is the licensing of the work in exchange for payments, known as royalties. In the case of books, authors are generally entitled to royalties on every copy sold by the publisher. Music royalties are more complicated because there are more venues in which music can be sold or publicly performed, but the principle is the same. Royalties are generally owed to the songwriter for every copy of an album sold (mechanical royalties), for play on jukeboxes or on the radio (performance royalties), and for use on television or in films (synchronization royalties).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Open Source Software Licensing

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In part as a reaction to this distributor-driven model of copyright licensing, programmers developed what is now known popularly as "Open Source" licensing. The development of this manner of software development and licensing has been described well elsewhere and will not be repeated here. For more details on the history, read Free As In Freedom (Sam Williams, O'Reilly 2002), The Cathedral & The Bazaar (Eric S. Raymond, O'Reilly 2001), and Open Sources: Voices from the Open Source Revolution (DiBona et al., O'Reilly, 1999).

The fundamental purpose of open source licensing is to deny anybody the right to exclusively exploit a work. Typically, in order to permit their works to reach a broad audience, and, incidentally, to make some sort of living from making works, creators are required to surrender all, or substantially all, of the rights granted by copyright to those entities that are capable of distributing and thereby exploiting that work.

Because these entities, by their very nature, do not see work as work in the first instance, but rather as the source of an income stream flowing from its exploitation, they are jealous of their right to exclusive exploitation of the work. They are similarly reluctant to share any part of the value of the work with others. While the potential consumers of a literary or musical work will be limited by the costs of acquiring the work—costs that are set exclusively by the person or entity that controls the right to distribute it—market forces will tend to reduce prices so as to maximize returns to that person or entity. Because the marginal costs of mechanical reproduction are relatively low, selling more copies of a work (at lower prices) will generally result in a larger stream of income to the publisher.

As a result, publishers fiercely defend the copyrighted work from unauthorized distribution of copies of the work itself or creation of derivative works based on the work. In the case of artistic works, the problem of unauthorized distribution of the original work is more common. While unauthorized derivative works occasionally result in lawsuits or other disputes, the value of artistic or aesthetic works relies on their original form of expression: they are "non-dynamic." Consumers want to hear Bruce Springsteen's

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Issues with Copyrights and Patents

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

All of the licenses described in this book can be broken up into two parts. The first part asserts that the person granting the license, the licensor, has the right to license the work to which the license applies. This representation may be implicit or explicit, and may be limited to specific types of rights. A licensor may, for example, assert that he has only applicable rights under copyright to the licensed work and makes no representation about patent rights that may apply to it. The second part of every license is a grant (again, however limited) by the licensor to the licensee of rights to that licensed work.

Obviously, both parts of the license need to be there in order for the license to be effective. When the first part of the license is there and the licensor has all of the rights necessary to grant them to the licensee, the only question is the relationship between the licensor and the licensee under the terms of the license. However, significant complications arise when a third party has legitimate legal claims to the work purporting to be licensed.

In the case of copyrights, a creator of an original work (defined in the legal, not the artistic sense), can confidently license that work, at least to the extent to which it may be governed by copyright law. The creator (hopefully) knows that he or she has not plagiarized the work from another and therefore has the right to license it.

Patents, however, present more complicated issues. It is more difficult to obtain and retain a patent in the first place, and there is always a risk of possible, and possibly unknowing, infringement of a patented process by the licensor, and, accordingly, by his or her licensees.

Unlike copyright protection, which does not even require filing or a formal notice on the copyrighted work, obtaining a patent from the Office of Patent and Trademark requires filing of relatively complex and laborious paperwork, including, most importantly, some explanation of the novelty of the patent in question and how it differs from processes or mechanisms already known. This generally requires the participation of an experienced patent lawyer. But obtaining the patent is not even half the struggle. Because of the profitability of patent royalties, patent holders tend to be very jealous of their rights and patrol the boundaries of their patents vigorously, attempting through the courts to extend the boundaries of their patents as much as possible and at the same time to narrow the scope of patents held by others. This can be, as you may imagine, an extremely expensive and time-consuming ordeal.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Open Source Definition

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that we have examined the basic principles of copyright and contract and contrasted the operation of those principles with those of open source licensing, it is worth discussing in some detail the definition of open source licensing.

The Open Source Definition is the definition propounded by the Open Source Initiative, used to describe which licenses qualify as "Open Source" licenses. The Open Source Initiative also certifies licenses as OSI Certified to indicate that they fall within the Open Source Definition. We have already seen the basic principles of open source licensing: open source licenses must permit non-exclusive commercial exploitation of the licensed work, must make available the work's source code, and must permit the creation of derivative works from the work itself. Each of these principles is expressed in the Open Source Definition, and, as we will see later, in the open source licenses discussed later in the book.

The Open Source Definition begins as follows:

Introduction

Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:

1. Free Redistribution

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

This requirement embodies the open distribution principle discussed a moment ago, with the variation that free distribution is required only as part of an "aggregate software distribution." This relatively minor modification of the open distribution principle was made to include the Perl Artistic License described in Chapter 4, under the umbrella of open source. This modification may well be removed in future versions of the Open Source Definition.

2. Source Code

The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost-preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Warranties

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Warranty disclaimers, while not a part of the open source definition and not necessary for a license to function as an open source license, are nonetheless very common in licenses.

To understand the effect of the warranty disclaimer, it helps to have some understanding of what the terms used in it are and what it means to have a warranty associated with or implied by the acquisition of a particular work. The most obvious form of warranty is an express warranty . If upon the sale of a particular item, the seller explicitly states to the buyer that the item being sold, say, an answering machine, will perform a particular function, say, automatically answer incoming calls, the warranty is part of the sale. In the event the product does not perform as stated, the buyer has a remedy against the seller, generally either to have the price of purchase returned or to receive an equivalent but functioning item in exchange for the defective one. Express warranties are very common in sales of consumer goods. My stereo speakers, for example, were warrantied against defects for 10 years from the date of sale.

A warranty of merchantability is not an express warranty, but rather a variety of implied warranty , a warranty created by the operation of law, not by the seller's decision to make a particular representation. This type of warranty is generally applicable only to merchants, persons who make a business in the sale of particular goods. This warranty operates as a general guarantee that goods sold by a merchant are suitable for use as generally intended. A purchaser who buys rope from a hardware store, even if there is no express warranty, is nonetheless guaranteed that the rope will function as rope generally does. By contrast, if you buy a car from your cousin, who is not a car dealer, you have no guarantee that the car will run in a particular way, or even that it will run at all.

A warranty of fitness for a particular purpose lies somewhere between a warranty of merchantability and an express warranty. Like a warranty of merchantability, it is implied by law, and not by express guarantee; but like an express warranty, it applies to a particular function. Its name describes its function. For example, if you buy rope in a hardware store, and prior to the purchase you say to the person selling the rope, "oh and by the way I am using this rope to pull the car I just bought from my cousin out of a ditch," and the person selling it says, "oh yeah, it's strong enough for that," a warranty of fitness for a particular purpose is implied. If the rope does not work, the buyer, again, has a remedy against the seller.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: The MIT, BSD, Apache, and Academic Free Licenses

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The MIT and BSD Licenses were two of the earliest open source licenses. Because these licenses are relatively straightforward and illustrate some of the basic principles of open source licensing, they are described here first. The MIT (or X), BSD, and Apache Licenses are classic open source licensing software licenses and are used in many open source projects. The most well-known of these are probably the BSDNet and FreeBSD Unix-like operating systems and the Apache HTTP Server.

These licenses, as applied to the original licensed code, allow that code to be used in proprietary software and do not require that open source versions of the code be distributed. Code created under these licenses, or derived from such code, may go "closed" and developments can be made under that proprietary license, which are lost to the open source community. For the same reason, however, these licenses are very flexible and compatible with almost every form of open source license.

If you're interested in licenses that keep code from being used in proprietary software, look ahead to Chapter 3.

The Academic Free License is a somewhat more elaborate license, embodying many of the same provisions found in the MIT, BSD, and Apache Licenses; in addition, it includes certain clauses addressing the application of patent rights to open source software.

The MIT License, the simplest license in this book, begins as follows:

Copyright (c) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The <year> and <copyright holder> tags obviously refer to the date of publication of the code and the person in whom copyright is vested, which is generally going to be the creator of the code. This part of the license essentially surrenders all of the rights that the copyright holder typically receives, including, as discussed in the previous chapter, the exclusive right to commercially exploit the work and to develop derivative works from the work. In addition, the licensee may, but need not, permit its own licensees to exercise these same rights.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The MIT (or X) License

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The MIT License, the simplest license in this book, begins as follows:

Copyright (c) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The <year> and <copyright holder> tags obviously refer to the date of publication of the code and the person in whom copyright is vested, which is generally going to be the creator of the code. This part of the license essentially surrenders all of the rights that the copyright holder typically receives, including, as discussed in the previous chapter, the exclusive right to commercially exploit the work and to develop derivative works from the work. In addition, the licensee may, but need not, permit its own licensees to exercise these same rights.

This grant of rights is subject to two conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

And:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. [all caps in original]

The first of these two conditions is almost universal in open source licensing and serves the straightforward and necessary purpose of alerting future users of the work of the restrictions on it. (Copyright laws used to require that copyrighted works carry an explicit notice in published forms to receive copyright protection.) The second of the two conditions provides the warranty disclaimer described in the previous chapter.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The BSD License

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The BSD License, which is only slightly more restrictive than the MIT License, exists in a number of substantially similar forms. The following example is the UCB/LBL form, named after the University of California at Berkeley and the Lawrence Berkeley Laboratory.

This license, like the MIT License, begins:

Copyright (c) <YEAR>, <OWNER>

All rights reserved.

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

The copyright notice and the attribution are substantially the same as those in the MIT License. Again, the license should reflect the actual year of copyright and the correct name of the creator.

Prior to 1999, the BSD License contained the following provision:

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

This provision seems relatively innocuous. It seems both reasonable and natural that the creator, having surrendered the exclusive right to commercially exploit a work, should receive credit not only in the acknowledgment of rights but in the advertising as well. It does not challenge the essential premises of open source, as it does not limit the scope of the use of the software in any direct way. Nonetheless, the pre-1999 BSD License sometimes causes problems because of this clause. The principles of open source endorse the commercial exploitation of software, including the sale of software, manuals, and support for profit. Such commercial exploitation very well may include advertising and when an open source project draws from a number of predecessors, the requirement of including such references can become a real burden. The BSD License, however, was amended in 1999 and this clause was removed. The University of California rescinded this clause and to the extent it may still be found in BSD files licensed by the University of California, it no longer has any legal effect.

The remainder of the license largely mirrors the effect of the provisions of the MIT License already described, by conditioning distribution—whether in modified form or not—on the maintenance of the conditions already described:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Apache License, v1.1 and v2.0

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Apache License is very similar to the BSD and MIT Licenses already described. The Apache License, Version 1.1, follows substantially the same pattern as the BSD License in premising distribution and modification upon compliance with relatively unrestrictive terms. Version 2.0, a top-down rewriting of the license, was first published in 2004 and is described in detail later.

Version 1.1 is slightly longer than the licenses discussed earlier in the chapter, but it operates in much the same way.

Copyright (c) 2000 The Apache Software Foundation.

All rights reserved.

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

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

The copyright notice, the clause introducing the limitations on distribution, and the first two limitations are substantially identical to those in the BSD License.

3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)."

Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear.

The Apache License does not have the cumbersome advertising clause in the rescinded version of the BSD License, but it requires an acknowledgment of the creator's contribution to the work being distributed.

4. The names "Apache" and "Apache Software Foundation" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact apache@apache.org.

Like the BSD License, the Apache License contains a non-attribution provision, which protects the reputation of the creator.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Academic Free License

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Academic Free License is substantially similar to the Apache License, v1.1, in forbidding claims of endorsement by the work's creator, in requiring attribution to the creator, in disclaiming warranties, and in permitting distribution of the original work and derivative works subject only to certain limitations. The Academic Free License adds four more provisions that are not in the Apache or BSD Licenses, two of them pertaining to patent law, and two of them governing choice of law and shifting of attorneys fees.

As discussed in Chapter 1, the intellectual property rights at play in software licenses derive for the most part from copyright, protecting the expression of particular ideas. The Academic Free License also addresses the case in which a patent holder chooses to permit the open source use of that patent.

Paragraph 1 of the Academic Free License (v2.0) provides:

1) Grant of Copyright License. Licensor hereby grants You a world-wide, royalty-free, non-exclusive, perpetual, sublicenseable license to do the following: a) to reproduce the Original Work in copies; b) to prepare derivative works ("Derivative Works") based upon the Original Work; c) to distribute copies of the Original Work and Derivative Works to the public; d) to perform the Original Work publicly; and e) to display the Original Work publicly.

This is essentially the same bundle of rights granted by the Apache and BSD Licenses already discussed. Paragraph 2 distinguishes the Academic License by making it clear that patent claims owned or controlled by the Licensor are licensed to those working with this software.

2) Grant of Patent License. Licensor hereby grants You a world-wide, royalty-free, non-exclusive, perpetual, sublicenseable license, under patent claims owned or controlled by the Licensor that are embodied in the Original Work as furnished by the Licensor, to make, use, sell and offer for sale the Original Work and Derivative Works.

This paragraph grants the licensee a license to exercise patent rights without payment of royalties, so long as a) those patent rights are held by the licensor, and b) those patent rights are exercised in connection with the Original Work or a Derivative Work. Accordingly, this may be an appropriate license (or license provision) to be used for a work that its creator intends to be open source licensed that includes property subject to one or more patents.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Application and Philosophy

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

All of these licenses have been used in practice, both in licensing software maintained in the open source community and in providing the basis for commercial applications of programs derived from open source models. The BSD, MIT, and Apache Licenses, longer established and more frequently adopted than the Academic Free License, provide the examples described in this section.

Each of these three licenses has contributed to the widespread commercial adoption of the programs they license, frequently (though not always) through incorporation into products distributed under a proprietary license. This is completely consistent with the language and intent of the licenses. This also reflects their place of origin. For example, both Berkeley Unix and the X Window System were research projects; the goal of their creators was to explore technology, to provide a proof-of-concept implementation, and then to permit others to build on that work. Commercial applications readily followed successful implementations of research ideas.

BSD Unix became the basis for commercial versions of Unix ranging from Sun's Solaris to Apple's Mac OS X. BSD-derived proprietary versions of Unix outstripped the commercially licensed AT&T versions relatively quickly, and they dominated the commercial Unix market until the 1990s when Unix was challenged by GPL-licensed Linux distribution. The TCP/IP software stack that was part of the Berkeley networking release became the basis for almost all commercial TCP/IP stacks, including Microsoft's. The X Window System became the standard GUI platform for the Unix workstation market, displacing Sun's proprietary NeWS windowing system. In addition, even as these commercial implementations became available at the same time, open sourced implementations continued to be widely available and accessible for modifications and improvements by programmers.

Despite setbacks from a lawsuit from AT&T that was ultimately settled out of court in 1992, Berkeley Unix still has many million installations, running such well-known sites as Yahoo!, and it continues to be modified and improved. Moreover, and partly as a result, later commercial entrants such as Apple have tried to keep a better defined line between the open source foundations of their programs and their proprietary extensions.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 3: The GPL, LGPL, and Mozilla Licenses

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The licenses described in this chapter are very different from those described in Chapter 2. These licenses impose substantial limitations on those who create and distribute derivative works based on works that use these licenses. The GNU General Public License (the GPL License) explicitly requires that derivative works be distributed under the terms of the GPL License and also that derivative works may only be permitted to be distributed under the terms of the license. The Mozilla License imposes different and less restrictive terms on the licensing of derivative works. Both of these licenses (and a variation of the GPL License) are described in some detail in the following sections.

Before going into detailed descriptions of these licenses and their effects, it's a good idea to re-examine the limitations imposed by the licenses described in the previous chapter, if only for contrast.

The MIT License, probably the simplest of those licenses, imposes almost no restrictions on licensees and no meaningful restriction at all on licensees distributing derivative works. When the original work or "substantial portions" of it are distributed, the licensee is required to include a copyright notice and the notice giving permission to potential licensees of their rights to use the work. The licensee is not even required to include the disclaimer of warranties that was part of the original license. (Such licensees may, however, have good reason to include that disclaimer—in particular, to protect themselves from potential liability.)

The MIT License does not impose even these restrictions on licensees who choose not to distribute it or "substantial portions" of it, but rather only works derived from it. Such licensees need not include the copyright notice, the disclaimer of warranties, or the permission notice. As described in the previous chapter, this allows the creator of a derivative work to license that new work in any way that he may choose, whether under a proprietary license or under the MIT or another open source license.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

GNU General Public License

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The GNU's General Public License, or GPL, is one of the foundation open source licenses. Created by the Free Software Foundation (FSF), which has made many contributions to open source coding, it is the preferred license for projects authorized by the FSF, including the GNU Emacs Editor and the GNU C Compiler, among literally scores of others, including the GNU/Linux kernel.

The intentions behind the license and the premise underlying it are explained in the license's preamble, which is included here in its entirety. The preamble follows the copyright notice, and a notice that prevents modifications, ironically enough, to the license itself: "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." While the license permits the creation of derivative works from the licensed code, it does not permit the creation of derivative licenses from the license itself.

Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

Preamble

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software—to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

GNU Lesser General Public License

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The GNU Lesser General Public License (LGPL) is another license created by the FSF for the purpose of permitting a certain class of programs, generally subroutine libraries, to be licensed under an FSF license but be permitted to link with non-GPL software programs. Subroutine libraries provide various functions to other programs, and because as part of their function they link with such programs, the resulting program plus library could be considered as a legal matter to be a derivative work. Accordingly, if the other program were licensed under a proprietary license and the library under the GPL and the program and library were distributed together under the proprietary license, the GPL would be violated, as the program plus library would be considered a derivative work that would be subject to limitations on copying, distribution, and modification that are inconsistent with the GPL.

The LGPL provides an alternative license that preserves many of the benefits of the GPL model for such libraries—in fact, the Lesser General Public License was in its first incarnation known as the Library General Public License. LGPL-licensed libraries can be linked with non-GPL licensed programs, including proprietary software. However, libraries need not be licensed under the LGPL, and as the following preamble to the license points out, the preferable way to license libraries, at least under some circumstances, is under the GPL.

Preamble

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software—to make sure the software is free for all its users.

This license, the Lesser General Public License, applies to some specially designated software packages—typically libraries—of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Mozilla Public License 1.1 (MPL 1.1)

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In January, 1998, Netscape Communications decided to release the binary code of its Communicator web-brower for free. Less than 24 hours later, it decided to release the Communicator source code as well. As a result, at the same time that Netscape was addressing the many technical problems with transitioning Communicator into open source (including removing substantial amounts of code written by third parties who were unwilling to have their code "open sourced"), Netscape had to address the complex licensing issues involved.

The Netscape Public License (NPL) and the Mozilla Public License (MPL) were the result of these efforts. The NPL was substantially similar to the MPL, but it reserved certain rights to Netscape, most importantly, the right on the part of Netscape to relicense code developed by third parties that is derived from Communicator code under a proprietary or other license. Third-party modifiers of NPL-licensed code could thus lose any benefits that might flow from their contributions, without the guarantee, as for instance under the GPL, that their code will remain available to the community of programmers. The MPL does not contain the particular provisions embodying this grant of rights to Netscape.

The MPL constitutes an interesting hybrid of the ideas of the GPL and the BSD licenses already described. While code that falls within the scope of what the license describes as "Covered Code" is subject to many of the restrictions present in the GPL, such as the requirement that it be made available in open source form, the MPL, through its Section 3.7, also permits the use of such "Covered Code" in "Larger Works," meaning that MPL-licensed code can be combined with code licensed under another license. This latter result is expressly prohibited by the GPL and permitted by the BSD License. The MPL establishes something of a middle ground between the two licenses.

Thanks to its heritage as the product of a large American corporation, the MPL reads much more like a standard corporate contract, beginning with a long list of definitions, before going into another long list of numbered paragraphs and sub-paragraphs. Section 1 of the MPL consists entirely of definitions.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Application and Philosophy

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The GPL and MPL both have had symbolic as well as practical impacts in the world of software development. Those effects of these licenses, beyond their strict terms, are described next.

The impact of the GPL, and its offshoot, the LGPL, on the development of software cannot be overstated. The GPL project that grew up with the license, the GNU/Linux constellation of applications, better known simply as Linux, has seen its acceptance by users grow steadily from the early 1990s to the point where it now poses the only significant competitor to the Windows operating system.

This success, depending on your point of view, arises either because of, or despite, the fact that the GPL bars any development of software from GPL-licensed software that is not itself GPL licensed. The GPL seems to embody the maxim that "Freedom in a commons brings ruin to all." By requiring that all contributions to GPL projects be themselves GPL licensed, the GPL ensures not only that these contributions are available to other programmers (or at least those programmers willing to work within the GPL framework) but also encourages contributions from those programmers to whom it is important that their contributions be made, and remain, "free," as that term is used in the GPL.

The existence of such programmers is by now beyond dispute. Based on the success of the GNU/Linux project alone, the free software project has succeeded. Part of this success is due to the fact that the GPL has as important a symbolic purpose as a practical one. The restrictions of the GPL (and the LGPL) have greatly shaped the nature of development of software that is GPL-licensed. Programmers, by and large, respect the GPL and conform their behavior accordingly. The development of projects under the GPL depends on each participant adhering to the terms of the license by making his or her own contribution available to the community of developers. This adherence has resulted in the great success enjoyed by GPL-licensed projects.

But the GPL has an equally important aspirational purpose. Given that the GPL is often viewed as the "purest" form of licensing in nurturing and encouraging open development of software, development under this license has drawn programmers who take seriously the larger concept of open software development. This has had results beyond those caused by the terms of the license itself.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 4: Qt, Artistic, and Creative Commons Licenses

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter addresses two licenses closely associated with particular programs: the Q Public License (the Qt Toolkit) and the Artistic License (Perl). Each of these licenses has unique features, reflecting the specific terms that their creators wished to impose on users or modifiers of their work. Unlike the GPL or BSD licenses, these licenses are not frequently applied to programs other than those for which they were originally developed, and they tend to be adapted only for the code originally licensed under them and derivative works. Nonetheless, because these licenses are still in frequent use and because they provide some interesting contrasts to the licenses already discussed, they are described at some length in this chapter.

Also discussed is the Creative Commons license—the fruit of an effort to expand the open source model of development beyond software to literature and the arts. While its creators state that it is not applicable to software, it is a well-written license and has begun what will be an interesting experiment at the very least.

The Q Public License (QPL) was designed by the Norwegian firm Trolltech to govern the distribution of its software, the Qt Toolkit. The Qt Toolkit is a crossplatform toolkit for the development of graphical user interface (GUI) applications. It is used in KDE, a graphical user interface frequently used as a desktop environment for UNIX and UNIX-like operating systems, including many varieties of Linux. As KDE became more popular for use in Linux operating systems, concerns developed in the open source and free software community about the limitations imposed by the QPL. In reaction to this pressure, Trolltech agreed to cross-license the Qt Toolkit under the GPL as well as the QPL, after which the developers of KDE immediately shifted their license to GPL. Distribution of the Qt Toolkit and KDE has since been predominantly under the GPL.

The QPL provides a novel approach to a number of open source licensing issues. Among other things, the QPL permits distributions of modifications to covered software in the form of patches under less restrictive terms than modifications compiled with the original code, and provides certain rights applicable only to the initial developer of the licensed code.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Q Public License

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Q Public License (QPL) was designed by the Norwegian firm Trolltech to govern the distribution of its software, the Qt Toolkit. The Qt Toolkit is a crossplatform toolkit for the development of graphical user interface (GUI) applications. It is used in KDE, a graphical user interface frequently used as a desktop environment for UNIX and UNIX-like operating systems, including many varieties of Linux. As KDE became more popular for use in Linux operating systems, concerns developed in the open source and free software community about the limitations imposed by the QPL. In reaction to this pressure, Trolltech agreed to cross-license the Qt Toolkit under the GPL as well as the QPL, after which the developers of KDE immediately shifted their license to GPL. Distribution of the Qt Toolkit and KDE has since been predominantly under the GPL.

The QPL provides a novel approach to a number of open source licensing issues. Among other things, the QPL permits distributions of modifications to covered software in the form of patches under less restrictive terms than modifications compiled with the original code, and provides certain rights applicable only to the initial developer of the licensed code.

The QPL is presented in numbered sections following the first (unlabeled) section that is the introduction. This introduction includes the copyright notice for the license itself, permits distribution and copying of the license explicitly, and provides that the license applies to all software containing the appropriate copyright notice.

Copyright © 1999 Trolltech AS, Norway.

Everyone is permitted to copy and distribute this license document.

The intent of this license is to establish freedom to share and change the software regulated by this license under the open source model.

This license applies to any software containing a notice placed by the copyright holder saying that it may be distributed under the terms of the Q Public License version 1.0. Such software is herein referred to as the Software. This license covers modification and distribution of the Software, use of third-party application programs based on the Software, and development of free software which uses the Software.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Artistic License (Perl)

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Artistic (or Perl Artistic) License is named because of its stated intention to allow the initial developer to maintain "artistic" control over the licensed software and derivative works created from it. The Perl License is substantially identical to the Artistic License, but it includes an additional paragraph, which provides another option for commercial distribution.

Developed by Larry Wall in the late 1980s, Perl is a ubiquitous programming language, based on C (among other languages) and is found frequently in UNIX and UNIX-based systems. It is omnipresent on the World Wide Web, with thousands, if not millions, of web sites running combinations of Perl scripts over Apache web servers. Part of Perl's strength as a language is its ability to tie together different programs and languages that were not initially intended to work together.

Because of Perl's ubiquity and because Perl is licensed under both the Artistic License and the GPL, programmers and users are as likely to come across the Perl License as any other open source or free software license except the GPL, BSD, or LGPL. The core, the standard Perl libraries, the optional modules, and the documentation that make up Perl were initiated by Larry Wall but have involved the contributions of thousands of people, making Perl one of the most successful open source projects to date.

Unfortunately, the Artistic License is notoriously vague and confusing. This description and commentary will, hopefully, dispel at least some of that confusion.

Like the MPL and the QPL already discussed, the Artistic License was designed for use in connection with a particular program—Perl—and not as a generally applicable license, like the BSD or MIT Licenses, or the GPL, although it certainly could be used apart from Perl. (The Artistic License is frequently used for Perl modules, including many of those on the Comprehensive Perl Archive Network at http://cpan.org.)

The first section of the Artistic License is its preamble.

The Artistic License

August 15, 1997

Preamble

The intent of this document is to state the conditions under which a Package may be copied, such that the Copyright Holder maintains some semblance of artistic control over the development of the package, while giving the users of the package the right to use and distribute the Package in a more-or-less customary fashion, plus the right to make reasonable modifications.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Creative Commons Licenses

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Creative Commons series of licenses are the product of the Creative Commons Corporation, a not-for-profit organization founded in 2001 and currently based at Stanford University Law School. In December, 2002, inspired by the GPL, the Creative Commons Corporation issued a series of licenses designed to encourage creators of works to make their work available for public use. While not written for use in connection with software, the Creative Commons Licenses provide a solid basis for licensing the "open source" use of other expressions, including texts, music, web sites, and film. One of their licenses is described here to reflect that the ideas behind open source and free software licensing are applicable to more than just software. Additionally, the Creative Commons Licenses are solidly constructed and well-written: as such, they provide a good model for those who are considering drafting their own open source licenses.

In addition to the licenses, the Creative Commons Corporation provides two other services worth noting, at least briefly. First, Creative Commons offers a "Public Domain Dedication," a sort of ultra-permissive license that denotes the creator's surrender of all rights under copyright. As noted in connection with the Artistic License, the dedication of a work to the public domain is a simple and straightforward way to permit unrestricted use of a work. Second, Creative Commons offers the "Founder's Copyright," a contractual undertaking between the creator and Creative Commons that mimics the effect of the original copyright laws: copyright is granted for 14 years and is renewable for one additional 14-year period.

All the Creative Commons Licenses permit the free copying and distribution of the licensed work. Some variations also permit the distribution of derivative works, some on terms that require the creator of the derivative work to license that work under the same license, in the same manner as the GPL. The full variety of Creative Commons Licenses are available at creativecommons.org. The one described here is the "Attribution-ShareAlike" license that permits free distribution of the original work and creation and distribution of derivative works subject to the limitation that such works themselves be subject to the terms of the Creative Commons License. The license also requires that distributions of both original and derivative works contain attributions crediting the original author of the work. This license does not distinguish between commercial and non-commercial uses of a work: one of the more common limitations in Creative Commons Licenses is a bar on commercial use of works and derivative works. By contrast to the other licenses described in this book, this Creative Commons License governs the use of a written text, not a software program.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 5: Non-Open Source Licenses

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the previous chapters, we have examined open source and free software licenses, all of which permit, to varying extents, substantial inroads on the protections otherwise available under copyright or patent law. In this chapter, by contrast, we examine one variety of a classic proprietary license, as well as the Sun Community Source licenses and the Microsoft Shared Source Initiative.

The classic proprietary license needs relatively little explanation. The license does not need to distinguish, for example, between source and binary code: the source code is simply not made available. The license need not distinguish between distribution of derivative and original works: with one very narrow exception, neither is permitted. Proprietary licenses, like the one described below, may contain "open source" licensed software (under the more permissive licenses, like the MIT and BSD Licenses), but the code they license may not be included in any open source project, unless the code is licensed under a parallel non-proprietary license that permits such use.

The following license is the creation of the author. It licenses the hypothetical software of the Mildew Corporation, using terms found in virtually all proprietary licenses.

1. General. The software, documentation and any fonts accompanying this License whether on disk, in read only memory, on any other media or in any other form (collectively the "Software") are licensed, not sold, to you by Mildew Computer, Inc. ("Mildew") for use only under the terms of this License, and Mildew reserves all rights not expressly granted to you. The rights granted herein are limited to Mildew's intellectual property rights in the Mildew Software and do not include any other patents or intellectual property rights. You own the media on which the Mildew Software is recorded but Mildew and/or Mildew's licensor(s) retain ownership of the Software itself.

This provision provides that the software and associated documentation provided by Mildew are only licensed, not sold, to the consumer. This provision is substantially similar in effect to language used in the open source and free software licenses already described. The only rights granted are those specifically described in the license; all other rights are reserved.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Classic Proprietary License

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The classic proprietary license needs relatively little explanation. The license does not need to distinguish, for example, between source and binary code: the source code is simply not made available. The license need not distinguish between distribution of derivative and original works: with one very narrow exception, neither is permitted. Proprietary licenses, like the one described below, may contain "open source" licensed software (under the more permissive licenses, like the MIT and BSD Licenses), but the code they license may not be included in any open source project, unless the code is licensed under a parallel non-proprietary license that permits such use.

The following license is the creation of the author. It licenses the hypothetical software of the Mildew Corporation, using terms found in virtually all proprietary licenses.

1. General. The software, documentation and any fonts accompanying this License whether on disk, in read only memory, on any other media or in any other form (collectively the "Software") are licensed, not sold, to you by Mildew Computer, Inc. ("Mildew") for use only under the terms of this License, and Mildew reserves all rights not expressly granted to you. The rights granted herein are limited to Mildew's intellectual property rights in the Mildew Software and do not include any other patents or intellectual property rights. You own the media on which the Mildew Software is recorded but Mildew and/or Mildew's licensor(s) retain ownership of the Software itself.

This provision provides that the software and associated documentation provided by Mildew are only licensed, not sold, to the consumer. This provision is substantially similar in effect to language used in the open source and free software licenses already described. The only rights granted are those specifically described in the license; all other rights are reserved.

The sentence stating that Mildew does not license any property rights other than those that it owns is likely meaningless. By licensing the Software, Mildew is implicitly representing that it has the authority to license all of its components, whether those components are its own work or not. It seems unlikely that a court would hold that Mildew was not responsible for damages to a consumer arising from infringement if the Software turned out to infringe the intellectual property rights of a third party. After all, given the closed nature of the licensed software, consumers are not allowed to determine for themselves whether the software was infringing, even if they have the inclination or the resources to do so.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Sun Community Source License

Content preview·