Rosen_fm Page i Wednesday, June 23, 2004 9:04 PM

Open Source Licensing

Rosen_fm Page ii Wednesday, June 23, 2004 9:04 PM
Rosen_fm Page iii Wednesday, June 23, 2004 9:04 PM

Open Source Licensing

Software Freedom and
Intellectual Property Law

Lawrence Rosen

PRENTICE HALL PTR

Upper Saddle River, NJ 07458
www.phptr.com
Rosen_fm.fm Page iv Thursday, January 13, 2005 9:27 AM

Library of Congress Cataloging-in-Publication Data

Rosen, Lawrence E.
Open source licensing : software freedom and intellectual property law /
Lawrence Rosen.—1st ed.
p. cm.
Includes bibliographical references and index.
ISBN 0-13-148787-6 (pbk.)
1. Open source software—Law and legislation—United
States. I. Title.

KF3024.C6R67 2004
346.7304'8—dc22 2004050558

Publishing partner: Mark Taub

Editorial assistant: Noreen Regina
Marketing manager: Robin O’Brien
Production: BooksCraft, Inc., Indianapolis, IN
Cover designer: Mary Jo DeFranco

Original book copyright © 2005 Lawrence Rosen

Foreword copyright © 2005 Lawrence Lessig

Published by Prentice Hall Professional Technical Reference

Upper Saddle River, New Jersey 07458

Prentice Hall books are widely used by corporations and government agencies
for training, marketing, and resale. For information regarding corporate and
government bulk discounts please contact:
Corporate and Government Sales
(800) 382-3419
[email protected]

Company and product names mentioned herein are the trademarks or regis-
tered trademarks of their respective owners.

The author distributes an online version of this book under the Academic Free
License version 2.1, an open source license described in this book. This printed
version of the book is not so licensed and you may not copy, modify, or distribute
this printed version (which includes copyrighted work contributed by the pub-
lisher) without the prior written approval of the publisher.

While this book is written by an attorney, you are not my client and I am not
intending this to be legal advice. You are encouraged to show this book to your
attorney and obtain his or her independent advice about how to proceed.

Text printed in the United States on recycled paper at Courier in Stoughton,

Massachusetts.
Second printing, February 2005

ISBN 0-13-148787-6
Rosen_fm Page v Wednesday, June 23, 2004 9:04 PM

For Harry Adams

who shared this open source madness
with me
Rosen_fm Page vi Wednesday, June 23, 2004 9:04 PM
Rosen_fm_Kim.fm Page vii Wednesday, January 12, 2005 5:28 PM

Acknowledgments 1

I will be forever grateful for the encouragement and assistance

of Michael Einschlag, my mentor, my law partner, and my
friend of many years. He’s the most brilliant attorney I know,
and his counsel about patent and contract law through many
drafts of this book was invaluable.

We stand on the shoulders of giants. I had the good fortune to

learn about open source from the leaders who created it. I want
to thank them all but can only name a few special ones who in-
fluenced me and taught me about software freedom and open
source: Bruce Perens, Peter Deutsch, Eric Raymond, Russell
Nelson, Brian Behlendorf, Richard Stallman, Eben Moglen,
Danese Cooper, Guido van Rossum, and Michael Tiemann.
Anyone who knows these players knows that we disagree
among ourselves about more than a few licensing matters, but
we all agree that software freedom is a grand goal. I couldn’t
and wouldn’t have written this book without them.

It is impossible to name all the contributors to the various li-

censing lists I monitor, but thank you all for expressing your-
selves so eloquently. I’ve stolen many of your (unpatentable)
ideas for this book. Special thanks go to John Cowan, Mårten
Mickos, Scott Peterson, Mark Webbink, Dietmar Tallroth,
Tim O’Reilly, Brian Fitzgerald, Dan Ravicher, and Rod Dix-
on, who may not realize how important their help and inspira-
tion have been for writing this book. Thanks.

vii
Rosen_fm Page viii Wednesday, June 23, 2004 9:04 PM
Rosen_fm_Kim.fm Page ix Wednesday, January 12, 2005 5:29 PM

Contents 1

Foreword xv 2

Preamble xix 3

Chapter 1 Freedom and Open Source 1

The Language of Freedom 1
Defining Open Source 2
Open Source Principles 8
Chapter 2 Intellectual Property 13
Dominion Over Property 13
Right Brain and Left Brain 15
Acquiring Copyrights and Patents 17
Original Works of Authorship 19
Works Made for Hire 20
Exclusive Rights of Copyright and Patent
Owners 22
Copies 24
Exceptions to the Exclusive Right
to Make Copies 25
Collective and Derivative Works 26
The Chain of Title for Copyright 28
The Chain of Title for Patents 30
Joint Works 32
Assigning Ownership 33
Duration of Copyright and Patent 36
Trademarks 37
Exceptions to Intellectual Property Protection 39
Chapter 3 Distribution of Software 41
Contributors and Distributors 41
Distribution 42
Open Source Collaboration 43

ix
Rosen_fm Page x Wednesday, June 23, 2004 9:04 PM

x Contents

Contributor Agreements 45
What About Users? 49
Chapter 4 Taxonomy of Licenses 51
What Is a License? 51
Bare Licenses 53
Licenses as Contracts 57
Patent Licenses 66
Template Licenses 68
Types of Open Source Licenses 69
Chapter 5 Academic Licenses 73
The BSD Gift of Freedom 73
BSD License as Template 77
The BSD License Grant 77
Source and Binary Forms of Code 79
Conditions under the BSD 80
Warranty and Liability Disclaimer 83
The MIT License 85
The Right to Sublicense 87
The Warranty of Noninfringement 89
The Apache License 91
Protecting Trademarks 92
The Apache Contributor License Agreement 93
The Artistic License 95
License Preambles 96
When Amateurs Write Licenses 97
Big Picture of Academic Licenses 101
Apache License Version 2.0 102
Rosen_fm Page xi Wednesday, June 23, 2004 9:04 PM

Contents xi

Chapter 6 Reciprocity and the GPL 103

The GPL Bargain 103
Copyleft and Reciprocity 105
Policy Objectives 107
The Preamble to the GPL 109
GPL as Template 112
The GPL Applies to Programs 113
Linking to GPL Software 115
Copyright Law and Linking 119
The LGPL Alternative 121
GPL Grant of License 125
Access to Source Code 128
“At No Charge” 131
Other Obligations in the GPL 133
The GPL and Patents 134
Accepting the GPL 136
Chapter 7 The Mozilla Public License (MPL) 141
The Mozilla Story 141
The MPL Reciprocity Bargain 143
Contributors and Modifications 145
The MPL and Patents 147
Defending Against Patents 154
Other Important MPL License Provisions 156
Other Corporate Licenses 159
Chapter 8 The Common Public License
(CPL) 161
CPL as a Template 161
A Digression about Well-Written Licenses 162
Rosen_fm Page xii Wednesday, June 23, 2004 9:04 PM

xii Contents

Grant of Copyright and Patent Licenses 163

Reciprocity under the CPL 167
Exception to Reciprocity 168
Patent Defense 170
Defend and Indemnify 173
Ownership of the CPL License 176
Chapter 9 The OSL and the AFL 179
Academic or Reciprocal? 179
Initial Paragraph of OSL/AFL 182
1. Grant of Copyright License 184
2. Grant of Patent License 188
3. Grant of Source Code License 190
4. Exclusions from License Grant 192
5. External Deployment 194
6. Attribution Rights 196
7. Warranty of Provenance
and Disclaimer of Warranty 198
8. Limitation of Liability 202
9. Acceptance and Termination 206
10. Termination for Patent Action 209
11. Jurisdiction, Venue, and Governing Law 218
12. Attorneys’ Fees 220
13. Miscellaneous 222
14. Definition of “You” in This License 223
15. Right to Use 224
Copyright and Licensing Notice 225
Chapter 10 Choosing an Open Source
License 229
How Licenses Are Chosen 229
The Free-Rider Problem 230
Rosen_fm Page xiii Wednesday, June 23, 2004 9:04 PM

Contents xiii

Making Money from Open Source 231

In-Licensing 232
Out-Licensing 235
Contributions to Projects 238
License Compatibility for Collective Works 241
License Compatibility for Derivative Works 243
Relicensing 252
Chapter 11 Shared Source, Eventual Source, and
Other Licensing Models 255
Alternatives to Open Source 255
Shared Source 256
Public Source 259
Dual and Multiple Licensing 262
Eventual Source and Scheduled Licensing 264
Combining Licensing Models 267
Chapter 12 Open Source Litigation 269
Owning a Cause of Action 269
Damages 271
Injunctions 274
Standing to Sue 276
Burden of Proof 277
Enforcing the Terms of a Contract 280
Disputes over Ownership of Intellectual
Property 283
Disputes over Derivative Works 284
Patent Infringement Litigation 289
SCO vs. Open Source 290
Chapter 13 Open Standards 295
Defining Open Standards 295
Open Specifications 296
Rosen_fm Page xiv Wednesday, June 23, 2004 9:04 PM

xiv Contents

Enforcing the Standard by Copyright

Restrictions 298
Licensing the Test Suite: The Open Group
License 299
Discouraging Forks: Sun’s SISSL 301
Patents on Open Standards 303
Reasonable and Nondiscriminatory 304
Royalty Free 306
The W3C Patent License 307
Justifying Open Standards and Open Source 310
The Open Source Paradigm 313
Appendices 315
Index 385
About the Author 397

4
Rosen_fm_Kim.fm Page xv Wednesday, January 12, 2005 5:29 PM

Foreword 1

by Lawrence Lessig†

Open source resources are completely common within our so-

ciety. Yet open source and free software remain a mystery. Sci-
ence, public highways, city parks, language—these are at the
core of any free society. Commerce gets built upon them. Cul-
ture flourishes through them. Yet the same ideas applied to
software puzzle many people. Language can be free, and the re-
sults of science open to all, yet to many, software is, or should
be, proprietary.

Why code must be proprietary is a question whose answers

have changed over the past ten years. At first, the reasons were
technical: no free or open source project, it was said, could de-
velop the highly complex and robust code necessary for mod-
ern software applications. But when the GNU/Linux project
began to produce an operating system that rivaled Microsoft’s
in robustness and efficiency, this technical argument began to
fade.

† Professor of Law, Stanford Law School, and author of Code and Other Laws of Cy-
berspace (Basic Books, 2000); The Future of Ideas: The Fate of the Commons in a Con-
nected World (Vintage Books, 2002); Free Culture: How Big Media Uses Technology and
the Law to Lock Down Culture and Control Creativity (Penguin Press, 2004).

xv
Rosen_fm Page xvi Wednesday, June 23, 2004 9:04 PM

xvi Foreword
Contents

In its place, many offered an argument of commercial necessi-

ty: No free or open source project could survive commercially,
given the high costs of quality programming, and the inability
to exclude others from the benefits of that quality. But again,
when companies such as IBM and HP began to invest billions
in free software development, this argument too began to
weaken. And as the embedded systems market began to take
off, built as it is upon open and free software, it became clear
to most disinterested observers that open source and free soft-
ware were elements of a different business model, not oppo-
nents to business. Whether this different business model will
produce more profits for the technology sector generally is an
empirical question we rely upon markets to resolve. But that it
does make money for some is no longer subject to doubt.

Having failed to convince the world that propriety software is

technically necessary, or commercially necessary, the oppo-
nents of free and open source software now argue against it on
the basis of legal necessity. At the most extreme (and absurd),
SCO President Darl McBride argues that free software licensed
under the GPL is “unconstitutional.” At the center are those al-
lied with Microsoft, who argue that the licenses supporting the
most popular free and open source projects are “dangerous”
and “unproven.”

In this beautifully clear and accessible work, Lawrence Rosen

defuses this last, and equally fallacious, argument against open
source and free software. While he doesn’t waste trees respond-
ing to the ridiculous claims of McBride, this book builds a
framework within which the family of free and open source li-
censes can be understood. And in a rare talent for a lawyer,
Rosen succeeds in making these points about the law meaning-
ful and understandable to anyone at all.

This is the great value of this perfectly timed book. As open

source software is among the fastest growing and most impor-
tant software produced, it has become necessary for a wide
Rosen_fm Page xvii Wednesday, June 23, 2004 9:04 PM

Foreword
Contents xvii

range of people to understand the foundations upon which it

is built. Businesses and investors, as well as technologists and
scientists, need to understand how pedestrian the legal frame-
work is within which open source and free software are ground-
ed. Policymakers need to see that this distinctive model for
creating and spreading knowledge about code is neither com-
munism come to the digital age, nor a binary version of Tho-
mas More’s Utopia.

The need for this understanding was never more clear to me

than when I read about our own government’s view about open
source and free software. In July 2003, the United States gov-
ernment vetoed a request that the World Intellectual Property
Organization (WIPO) hold a meeting to discuss “open collab-
orative models for producing public goods,” including open
source and free software. Lois Boland, director of international
relations for the U.S. Patent and Trademark Office, explained
“that open-source software runs counter to the mission of
WIPO, which is to promote intellectual-property rights.” As
she is quoted as saying, “To hold a meeting which has as its
purpose to disclaim or waive such rights seems to us to be con-
trary to the goals of WIPO.”

This statement is astonishing on a number of levels, and Ros-

en’s book demonstrates why. Most obviously, open source and
free software is not “counter to the mission of” an organization
that “promote[s] intellectual property rights,” as open source
and free software generally relies upon intellectual property to
achieve their effect. The most important open source and free
software is not software in the public domain. It is instead, like
Microsoft’s software, software protected by intellectual proper-
ty law and licensed to users on the terms chosen by the property
owner.

No doubt the property owners in an open source and free soft-

ware project “disclaim or waive” some of their rights. But
again, it is puzzling why property owners choosing how to ex-
Rosen_fm Page xviii Wednesday, June 23, 2004 9:04 PM

xviii Foreword
Contents

ercise their rights could ever be “contrary to the goals of

WIPO.” Is it against the property system generally when Bill
Gates gives $20 billion to help the poor in Africa? Are public
highways latent communism?

Boland’s view is grounded in a mistaken understanding of the

way open source and free software function. In my view, no
one who understands what this book teaches could have any
principled opposition to this business model competing with
any other. There will be a great deal of social wealth created by
this family of licensing. There will be an even greater amount
of knowledge and freedom that is spread by this legal arrange-
ment. Rosen has done us all a great service by making under-
standable the legal tools that make these goods possible.
Rosen_preamble.fm Page xix Wednesday, January 12, 2005 5:32 PM

Preamble 1

In February 1989, Richard Stallman first released his GNU

project software for UNIX under version 1.0 of the GNU Gen-
eral Public License (GPL). In June of that same year, Bill Joy
first released a free version of UNIX software under the Uni-
versity of California’s Berkeley Software Distribution (BSD) li-
cense. These relatively quiet events signaled a new era in
software licensing. Almost imperceptibly at first, but with in-
creasing speed and energy, this licensing revolution, now wide-
ly referred to as open source, spread around the world.

By the first year of this century, approximately 17,000 open

source projects were active on the SourceForge servers
(www.sourceforge.org). Four years later there are over 74,000
such projects and more than 775,000 registered SourceForge
users. The majority of that open source software is currently li-
censed under the GPL or BSD licenses; the rest use one of
about fifty other licenses based on the same open source
principles.

Open source is now dominating many of the market conversa-

tions in the software industry. While software companies con-
tinue to release valuable and high-quality products under

xix
Rosen_preamble.fm Page xx Wednesday, January 12, 2005 5:33 PM

xx Preamble

proprietary licenses, most are also embracing open source

product development and distribution models as well as the
software licenses that make those models possible.

This book is about the law but it is not written for lawyers. You
will not find citations to case law or rigorous academic analyses
suitable for publication in a law journal. This book is written
for my friends in the open source community who write and
distribute software and who are confused about which licenses
to use. It is also written for our customers who are concerned
about how software licenses may affect them and their busi-
nesses. It seeks to dispel myths and fears about open source
software licensing and to explain the legal context in which
open source software exists.

Open source is built upon a foundation of intellectual property

law, particularly copyright law. Open source software is owned
by its authors, who license it to the public under generous
terms. Open source licenses do not seek to destroy or steal in-
tellectual property. The first chapters of this book explain the
intellectual property laws that make open source licensing
possible.

The following chapter describes the first broad category of

open source licenses, what I call academic licenses to acknowl-
edge their heritage in universities. These academic licenses al-
low software to be used, copied, modified, and distributed,
even with proprietary software—and their source code is in-
cluded. These licensors generously donate their software to the
public for use by anyone.

The GPL—and the MPL, CPL, and OSL licenses that fol-
lowed it—strike what I call a reciprocal bargain. Licensor and
licensees share a public commons of open source software, but
any modifications to that software must be distributed under
Rosen_preamble.fm Page xxi Wednesday, January 12, 2005 5:33 PM

Preamble xxi

the same license. These four licenses are much more complex
than the academic licenses and so I devote a chapter to each of
them.

Choosing a license to apply to your open source software is not

an easy decision and so I devote an entire chapter to it. The an-
swer depends intricately upon your business model, on your
software and product architecture, and on understanding who
owns the intellectual property in your products. If you expect
a checklist method to select a license, don’t bother reading this
chapter; it cannot be so easy.

Eventually, a licensor or licensee may need to enforce the terms

and conditions of an open source license. I devote an entire
chapter to satisfying the curiosity of those who may want to
sue—or who are afraid of being sued—under an open source
license.

Finally, I begin to address a potentially bigger issue than open

source. Open standards are really the battlefield on which we
will determine whether software can truly be free and open.
That topic deserves a book of its own someday; this isn’t it, but
I’m making a start.

Turning a software license into interesting reading is probably

an insurmountable challenge. There is no other way than read-
ing the words of a license to understand what it means. And so,
for those of you who won’t actually plod your way through the
detailed explanations of licenses herein, I want to give you the
conclusion.

As a user of open source software you may go forth and live

free. None of the licenses in this book restricts in any way your
use of open source software.
Rosen_preamble Page xxii Thursday, June 24, 2004 11:14 AM

xxii Preamble

But if you are more directly involved in the creation, modifica-

tion, or distribution of software, or if you manage or advise the
in-licensing of software into your company, you should at the
very least consult your attorney to make sure you don’t commit
to more than you’re willing to deliver. This book may help you
ask your attorney the right questions.
Rosen_ch01 Page 1 Tuesday, June 22, 2004 7:35 PM

1
Freedom and Open Source

The Language of Freedom

Open source licenses promise to everyone what many in the
community refer to as software freedom. The terminology of
freedom is emotionally satisfying, but it has proven to be very
confusing.
Freedom is an important subject in law school. Constitu-
tional law courses address such topics as the free speech clause
of the First Amendment to the U.S. Constitution. But free-
dom seldom comes up as a topic in classes devoted to business
issues such as contract or tort law, or software licensing. Law
school courses on intellectual property deal with copyright
and patent, but they don’t teach about freedom, referring
instead to the rights of the owners of those legal monopolies.
As a result, there is no easy conceptual basis for integrating the
language of freedom into the legal language of software
licenses. For example, where the word free is currently used in
software licensing contexts, it usually means zero, as in free of
charge or free of defects. Neither of these meanings is intended
by open source licenses.
Not that software freedom isn’t definable. The Free Software
Foundation lists four essential kinds of software freedom:

1
Rosen_ch01 Page 2 Tuesday, June 22, 2004 7:35 PM

2 Open Source Licensing

1. The freedom to run the software for any purpose

2. The freedom to study how the software works

and to adapt it to your needs

3. The freedom to redistribute copies of the

software

4. The freedom to improve the software and

distribute your improvements to the
public
That list, it turns out, can be satisfied by many different
software licenses. Both the GPL and the BSD licenses, the ear-
liest open source examples from the late 1980s, ensure those
four kinds of software freedom, although they do it in vastly
different ways.
Proprietary software vendors love the software freedom pro-
vided by the BSD license, but some of them hate and fear the
software freedom guaranteed by the GPL. So once again, the
concept of freedom by itself is only marginally helpful to
understanding open source licensing.

Defining Open Source

Confusion about the term freedom was the very reason the
term open source was created. The newer term refers to an
important concept well understood by anyone who has ever
written computer software: Programmers write source code to
direct computers to perform specific tasks, while the computer
itself takes care of the routine task of translating the source
code into an executable program. For a computer program-
mer, understanding and modifying software requires access to
the source code. The source code must be open—made avail-
Rosen_ch01 Page 3 Tuesday, June 22, 2004 7:35 PM

1 • Freedom and Open Source 3

able for all to see—in order that the software can be studied,
changed, and improved.
Open source code is an essential requirement for software
freedom, a technical prerequisite. Software freedom is the goal;
open source is the means to that goal.
The term open source has caught on in the media and in
public discourse. It is now possible to ensure that open source
licenses promote software freedom without using the confus-
ing word freedom at all. We now mostly refer to open source
software when we also mean free software.
Simply changing the name we call something, however,
doesn’t eliminate existing ambiguities. We still need a defini-
tion—a brief set of open source principles—that summarizes
what open source means and provides guidelines for open
source licenses.
In 1997, Bruce Perens proposed the Debian Free Software
Guidelines to reflect the new open source terminology, to
avoid confusion about the term free software, and to clarify cer-
tain other issues about acceptable licenses. Those guidelines
were refined in a month-long email discussion and finally
adopted by consensus as the Open Source Definition. (Perens
wrote about this history in Open Sources: Voices from the Open
Source Revolution. [O’Reilly 1999].) Originally consisting of
nine criteria for licenses, the Open Source Definition had a
tenth guideline added in 2002.
Licenses that meet these criteria are approved by the Open
Source Initiative (OSI) board of directors. Software that is dis-
tributed in source form under such approved licenses is OSI
Certified open source software. License approval has become a
prerequisite for widespread adoption of software by the open
source community; such organizations as SourceForge, for
example, will only permit software licensed under an OSI-
approved license to be hosted on their website.
Rosen_ch01 Page 4 Tuesday, June 22, 2004 7:35 PM

4 Open Source Licensing

Here, in summary form, is the most recent version of the Open

Source Definition (OSD) from the website of OSI, www.open-
source.org.

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.
2. Source Code
The program must include source code, and must allow dis-
tribution 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, prefer-
ably downloading via the Internet without charge. The
source code must be the preferred form in which a program-
mer 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.
3. Derived Works
The license must allow modifications and derived works,
and it must allow them to be distributed under the same
terms as the license of the original software.
4. Integrity of the Author's Source Code
The license may restrict source code from being distributed in
modified form only if the license allows the distribution of
"patch files" with the source code for the purpose of modifying
the program at build time. The license must explicitly permit
Rosen_ch01 Page 5 Tuesday, June 22, 2004 7:35 PM

1 • Freedom and Open Source 5

distribution of software built from modified source code. The

license may require derived works to carry a different name
or version number from the original software.
5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or
group of persons.
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the
program in a specific field of endeavor. For example, it may
not restrict the program from being used in a business, or
from being used for genetic research.
7. Distribution of License
The rights attached to the program must apply to all to
whom the program is redistributed without the need for ex-
ecution of an additional license by those parties.
8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the
program's being part of a particular software distribution. If
the program is extracted from that distribution and used or
distributed within the terms of the program's license, all par-
ties to whom the program is redistributed should have the
same rights as those that are granted in conjunction with the
original software distribution.
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that
is distributed along with the licensed software. For example,
the license must not insist that all other programs distributed
on the same medium must be open source software.
Rosen_ch01 Page 6 Tuesday, June 22, 2004 7:35 PM

6 Open Source Licensing

10. License Must Be Technology-Neutral

No provision of the license may be predicated on any indi-
vidual technology or style of interface.
This Open Source Definition has itself created some confu-
sion. It replaced certain vague concepts in the Free Software
Guidelines with some equally vague concepts about discrimi-
nation, authors’ integrity, and software redistribution. Public
discussions about license approval sometimes become argu-
ments about what the OSD itself means.
Lawyers point out that the OSD uses words like shall not
and must and may in inconsistent ways. For example, the
phrase must allow means different things in the two places it is
used in one sentence.
The license must allow modifications and derived works,
and must allow them to be distributed under the same terms
as the license of the original software. (OSD # 3.)
The first part of this provision is interpreted to mean that a
license must allow a licensee to create derivative works. The sec-
ond part, however, is interpreted to mean that a license may
require (but need not require) that the same license be used to
distribute those derivative works and also that a license may
not forbid licensing derivative works under the same license.
Even the two sentences of OSD # 1, with their uses of shall
not restrict and shall not require, confuse many new visitors to
open source. One of the most frequent first questions people
ask is, “Is all open source software zero price?” No. Most open
source licensees will be glad to take your money for your first
copy of a piece of software. But you never have to pay a royalty
or license fee for the right to make copies. It would be better if
OSD # 1 phrased this point better.
Rosen_ch01 Page 7 Tuesday, June 22, 2004 7:35 PM

1 • Freedom and Open Source 7

The Open Source Definition is in some respects mandatory

(e.g., under OSD # 1 and 2, licenses must permit copying of
the software and the creation of derivative works) and in some
respects permissive (e.g., under OSD # 4, a license may pro-
vide mechanisms to protect the author’s integrity). Some sug-
gest that an OSD provision that is merely permissive should
be left to market forces and should not be part of a definition
of what constitutes open source.
The word discrimination in various places in the OSD is
also confusing. Every software license discriminates in favor of
those who accept and honor its terms (the licensees) and dis-
criminates against those who use the software but don’t accept
and honor its terms (the infringers). The word discrimination
has colloquial meanings that may not have been intended by
the OSD. For example, because certain reciprocal licenses like
the GPL are unacceptable to certain proprietary software com-
panies, the license has been said to discriminate against those
proprietary software companies; others say that is merely dis-
criminating against nonlicensees who refuse to accept the
license terms and conditions.
While most in the open source community agree that non-
discrimination is a commendable goal in the abstract, the
community has been unable to agree about what constitutes
discrimination. In many jurisdictions around the world, dis-
crimination on the basis of race, age, religion, national origin,
sex, sexual orientation, health status, and other personal char-
acteristics is always illegal. How does discrimination against
field of endeavor in OSD # 6 fit into that list? The laws of
some countries may prohibit the use of certain software by
persons or groups (e.g., the export control laws of the United
States are discriminatory on purpose); don’t such laws mandat-
Rosen_ch01 Page 8 Tuesday, June 22, 2004 7:35 PM

8 Open Source Licensing

ing discrimination override the anti-discriminatory provisions

of a mere software license? Is such software still open source?
Certain provisions of the OSD have proven to be of no
great importance. In OSD # 7, because the reference is to an
additional license, it is not clear what role this OSD provision
can ever play, as a practical matter, when reviewing this license
for approval. As to OSD # 8, the Open Source Initiative web-
site mysteriously says only that this provision “forecloses yet
another class of license traps.” This issue has never arisen con-
cerning any present open source license. Furthermore, OSD
# 9 is probably unnecessary because it protects against some-
thing that would probably be illegal on antitrust grounds
wherever it really mattered. Its use of the phrase other programs
distributed on the same medium is far too narrow to adequately
describe what a distributor actually does with software.
Many OSD provisions deal with the distribution of software.
Some have criticized the OSD because it doesn’t directly
address the use of software. This is not entirely valid because the
rights to copy, to create derivative works, and to distribute are
essential for the use of open source software. But nothing in
the OSD actually makes that point directly.

Open Source Principles

In preparing this book, I found that the official Open
Source Definition was simply too confusing to focus readers
on what really matters most about open source licenses.
Therefore, I have chosen to rely on a somewhat different set of
Open Source Principles to describe software that is open source.
These Open Source Principles are different from but consis-
tent with the official Open Source Definition and with the
Free Software Guidelines quoted earlier.
Rosen_ch01 Page 9 Tuesday, June 22, 2004 7:35 PM

1 • Freedom and Open Source 9

They guide us to what I believe are the key things to look

for in open source licenses—and the key things we’ll find
missing in non–open source licenses.
It will be useful to keep these Open Source Principles in
mind as I describe specific open source licenses later in this
book. You may also find the brief explanations of each principle
helpful later in this book as I explore various actual open source
license provisions and the laws relating to licenses and contracts.

1.
Licensees are free to use open source software
for any purpose whatsoever.
An open source license may not interfere in any way with
the use of the software by licensees. Restrictions on use, such
as “for research and noncommercial purposes only,” are not
allowed in open source licenses. The phrase free to use is also
intended to mean “without any conditions that would impede
use,” such as a requirement for the licensee to report uses to
the licensor, or to disclose the means or manner of internal
uses of the software. Note also that the first word, licensees,
means that open source software is only available under the terms
of a license to which each licensee must agree.

2.
Licensees are free to make copies of open source
software and to distribute them without payment
of royalties to a licensor.
This principle does not mean that a licensor cannot sell
open source software. It merely says that a licensee need not
pay the licensor for additional copies he makes himself, even if
those copies are distributed to others. As a practical matter,
Rosen_ch01 Page 10 Tuesday, June 22, 2004 7:35 PM

10 Open Source Licensing

this open source principle drives the price of mere copies of

open source software toward its marginal cost of production
and distribution.

3.
Licensees are free to create derivative works
of open source software and to distribute them without
payment of royalties to a licensor.
Quality software is built upon the foundations of earlier
software. Many advocates of free and open source software
contend that the requirement for open source licenses to per-
mit the unhindered creation and distribution of derivative
works is essential to meet the goal of the intellectual property
laws as stated in the U.S. Constitution, “to promote the
progress of science and the useful arts.” Under this open
source principle, a licensor cannot charge a royalty for the
privilege to create and distribute derivative works, or require a
licensee to pay a royalty for copies of a derivative work that are
distributed, or impose any restrictions on the type or character
of those derivative works.

4.
Licensees are free to access and use the source
code of open source software.
Source code is written in a human language to instruct a
computer how to perform certain functions. Since the source
code must be changed in order to instruct the computer to
perform different functions, access to the source code is essen-
tial to make the third open source principle—the freedom to
create derivative works of open source software—a practical
reality. Source code is a means to an end, not the end itself.
The phrase free to access merely requires the licensor to make
Rosen_ch01 Page 11 Tuesday, June 22, 2004 7:35 PM

1 • Freedom and Open Source 11

source code available to licensees upon request at zero price,

not necessarily to distribute the source code to everyone.

5.
Licensees are free to combine
open source and other software.
Open source licenses may not impose conditions or restric-
tions on other software with which the licensed software is
merely combined or distributed. This prevents restrictions
regarding what other software can be placed on computer stor-
age media or in computer memory. Open source is but one of
many possible business and licensing models for software dis-
tribution, and customers must be free to select and use those
software alternatives. This open source principle does not
mean that licensors cannot impose reciprocal conditions upon
licensees who create and distribute derivative works, for the
activity of creating derivative works is not the same as merely
combining software on media or on computers.
Rosen_ch01 Page 12 Tuesday, June 22, 2004 7:35 PM
Rosen_ch02 Page 13 Tuesday, June 22, 2004 7:37 PM

2
Intellectual Property

Domi