Catherine Olanich Raymond

This is a DRAFT of an OSI working paper. It has not yet been
formally approved by OSI's board, though OSI and its legal counsel
have approved the direction of the work.

This document explains how U.S. copyright and licensing law applies
to open-source software projects. It compares the strengths and weaknesses
of the existing open-source licenses, and gives guidance on how to choose a
license for your project. It also explains the legalities of changing a
project's license. It suggests new practice for coping with today's
high-threat legal environment — this part is a must-read for all
project leaders.

Introduction

Purpose of this document

This document aims to teach developers the basics of how the law of
copyright and licensing applies to open-source software projects, and to
give guidance on how to choose an appropriate license. Unfortunately, the
`folk theory' most hackers seem to carry around and express in their
behavior is confused and wrong in many respects, and that confusion could
be dangerous in today's high-threat environment; this document is intended
as a corrective.

Some portions of this document dealing with copyright assume that you
are resident in a country with laws conforming to the
Berne Convention on copyrights (this includes the United States and
139 other countries). Other portions assume that you are under the
jurisdiction of the
U.S. Federal Code; these are usually marked with
references to "USC". If you are in a non-US jurisdiction, your laws may
vary. However, since U.S. rules tend to be the most elaborate and restrictive,
following them will often be safe.

Disclaimer: Eric S. Raymond is a hacker, not a lawyer ("Dammit, Jim,
I'm a doctor, not a bricklayer!"). Legal assertions made in this document
were researched by Catherine Olanich
Raymond, Esq., a shareholder of the Philadelphia law firm Christie
Mortensen Pabarue & Young; however they should not be considered advice
of counsel. The standard caveat applies that you should seek advice from a
professional attorney if in doubt. That said, only a tiny handful of
attorneys actually understand open-source software licensing issues at
present.

Feedback and corrections

If you have questions or comments about this document, please feel
free to mail Eric S. Raymond, at
esr@thyrsus.com. We welcome any suggestions or criticisms. Do not
email us legal questions! Eric is not a lawyer, and Cathy's services must
be applied for through her firm.

Answers to frequently-asked questions

This section is intended to collect the most practical advice and
answer the most frequently asked questions, with a minimum of legal theory.
Pointers to more detailed legal analysis in the remainder of the HOWTO
are included.

Can an open-source license be enforced against people trying to close up the code?

A:.

That depends on what you mean by `enforced'. Most open-source
licenses are not the GPL and don't have a strong copyleft property.
Non-copyleft licenses (like BSD's) don't require people making derived
works from the code to reveal source. What keeps most projects open-source
isn't the threat of lawsuit, it's that taking open-source code closed is an
expensive way to lose lots of money as your handful of salaried in-house
developers tries to keep up with a much larger pool of open-source
contributors.

Are copyleft licenses enforceable? We believe they are, but there
hasn't been a court test yet. There are some promising precedents in case
law pertaining to shrink-wrap licenses. See our extended analysis.

Q:.

If open-source licenses can't be used to keep people from closing up code, what good are they?

A:.

Licenses function as social contracts among groups of developers.
Whether or not a license is legally enforceable, your choice of an
open-source license conveys a message about the development practices you
want to use, the community you want to be part of, and the intended
audience of your software.

Licenses can also serve legal functions other than keeping the code
open. The liability disclaimer in a license may shield developers from certain
kinds of legal action, for example. The grants of patent use and other
rights in a license may give the code's potential audience the legal
security they need to use it.

Q:.

When I contribute to a project, what rights do I acquire in the project as a whole?

A:.

Rights to do what? Most of the rights you could ever want are
already ceded to you by the terms of any open-source license. You can
redistribute the code, modify it, or even fork the project.

When people ask this question, they are usually inquiring about a
right either to change the license of the project or prevent others from
doing so. That is, the right to control the terms of distribution.

In general, contributing to an open-source project won't give you any
enforceable right to do either, not even if you register a copyright on
your portion of the code. You may acquire the right to distribute a fork
of the project under a license of your own choosing; whether that is so
depends on some murky legal issues which we analyze in detail later.

Q:.

OK, so who can change the license on a project?

A:.

First, we need to be clear on what `changing the license' means.
Licenses attach to instances or versions of code; they don't magically affect
other copies, even if those other copies are bitwise identical aside from
the license. So when you speak of changing the license on a project, you
cannot suppose some sort of magical action at a distance that retroactively
changes the terms on all existing copies. That is not possible (though you
can do what the Free Software Foundation does and write a license that
gives licensees the option of conforming to later
versions).

So to "change a project license" is to just change the terms that
will apply on future versions that you and
other parties who agree to the change distribute.

Also, note that when the law gives you the right to issue a version
of some work under the license of your choice, that does not necessarily
bar other people who already have that right from continuing to issue under
licenses of their choice.

With these things in mind, here's an answer. If you are the
distribution maintainer and hold a copyright on the distribution as a
whole, you can issue the code under under the license you choose. Other
contributors' individual copyrights and licenses on individual parts do
not, under most circumstances, effectively limit your right to do that.
This is the situation if the code is what U.S. copyright law calls a
"collective work".

There is a competing theory that software projects are "joint works".
Under that theory, any contributor has the right to
redistribute under terms of his or her choosing. U.S. courts have
leaned away from the joint-work theory, but it is still possible that
a judge might apply it.

You right to choose a license may, theoretically, be limited in a
different way. It might be that court would consider an implied contract
to exist between you and the developers that limits the licenses you can
issue under. Community practice being what it is, this is not likely to
become an issue unless you ship a version under a closed-source license, or
under a license like the BSD that allows others to create proprietary
derivative works. Changing from one reciprocal license to another (e.g.,
GPL to OSL or vice versa) or from one academic-style license to another
(e.g., BSD to AFL or vice versa) is unlikely to contradict the implied
expectations of any open source contributor.

What is my risk of getting sued for
intellectual-property rights violation over violating an open-source
license?

A:.

Unless you try to hijack or take closed an entire project that
has registered a collective-work copyright on its code, the risk that you
will ever be sued for infringement over a copyright on open-source code is
probably rather lower than your risk of being struck by lightning.
For detailed discussion of why it is highly unlikely, see
our discussion of copyright law and
the preconditions for infringement lawsuits.

The exception is important, however. Open-source developers want
their code used; small-scale reuses of open-source code in ways that
technically infringe on its license are likely to be winked at. The flip
side is that they will react with great anger to deliberate attempts to
permanently wall off or proprietize code that was developed as part of
the commons.

In general, if you give back value to the community and don't
willfully behave like a thief or a spoiler, you won't attract
the kind of attention that could lead to a court action and many
boatloads of bad publicity.

Q:.

As a project contributor, should I take any
special actions to protect my contribution?

A:.

If you intend to donate your contribution to an open source project,
then don't waste your own time or money registering your copyright. Most
projects can probably rely on your "implied license to use the contribution
for any purpose." Let the project leadership decide how best to protect
its own interests in your contribution and the contributions of others;
that's their job. If they ask for it, consider executing a written
copyright assignment to them so they have total legal freedom of action
regarding your contribution.

Q:.

As a project leader, should I take any
special actions to protect my rights?

A:.

Yes If you are a project leader, you should assert a collective-work
copyright on your project codebase as a whole. You can do this by putting
text something like the following in the file describing the project's
licensing terms:

This collective work is Copyright (C)2002 by Eric S. Raymond
Individual portions may be copyright by individual contributors, and
are included in this collective work with permission of the copyright
owners.

By convention, this file should be called LICENSE
or COPYING and live in the root directory of your
source distribution. It is not necessary to include a copy of the
license in every source file, but it is a good idea for the header
comment to refer readers to the license file with a comment like
this:

Keep reading. The remainder of this document goes into much more
detail. and has links to primary sources including the U.S. Federal
Code. While you're learning, follow the suggestions on
best practice.

Basics of intellectual-property law for hackers

Copyright

A copyright confers a legal right to control the distribution of
copies of a creative work that you have produced. Copyright protects only
the expression of ideas, not the ideas itself; thus, you can copyright the
plans for a better mousetrap, but to protect the concept that the plans
express you would have to patent it. Under U.S. law (17 USC
302(a)), computer programs can be copyrighted as `literary works',
and the copyright holds good for the life of the author plus 70 years (for
a work of corporate authorship, the shorter of 95 years from publication,
or 120 years from creation).

Anything that is not public domain has a copyright, possibly more
than one. Under the Berne Convention (which has been incorporated into
U.S. law since 1978), the copyright does not have to be explicit. That is,
the authors of a work hold copyright even if there is no copyright
notice.

In U.S. jurisdictions, however, it is essentially impossible to sue
for infringement of your copyright unless you have
registered it (the only exceptions to this rule are
certain kinds of audio and visual works that are not software). That is,
you must have sent the appropriate form and $30 filing fee to the United
States Copyright Office together with a copy of the work (see 17 USC
411(a)).

If a published work is registered in a timely fashion (within three
months of publication and before the infringement occurs), a copyright
holder who prevails in an infringement lawsuit may ask the court for
statutory damages (see 17 USC 504(c))
and attorney's fees (it's also possible for the court to issue an
injunction preventing the infringing code from shipping). If the published
work had not been registered in a timely fashion, the copyright holder must
prove actual damages — a difficult task. `Actual damages' is a legal term of art that
means the plaintiff must show he or she has suffered actual monetary loss;
more rarefied consequences such as loss of reputation, exposure to
hypothetical legal risk, or anticipated future monetary losses do not clear
the bar.

For unpublished works, timely registration is defined as before
the infrigement occurs. However, open-source software probably qualifies
as `published' when it is released on the Internet (but this has not been
tested in court as of September 2002).

Some entire projects do in fact register copyright on their code.
The Free Software Foundation does this with its projects so that if someone
violates the GPL they can credibly be threatened with suit for
statutory damages.

But it is a safe bet that ordinary contributors to open-source
projects do not register their copyrights. What hacker is going to pay $30
or (horrors) fill out a form each time he ships a fix
to a project? Behavior that makes sense for novelists protecting
manuscripts would be utterly absurd with respect to the typical code patch.
Furthermore, as long as all the software remains open source it is
extremely difficult to see how any infringing action could cause the actual
damages required to give standing to a holder of
unregistered copyright. Finally, registering a
copyright on a patch would be ineffective as a practical matter under
both of the legal models ("collective work" and "joint work") that might
apply to an open-source project.

In fact, from a strictly consequential point of view, the profusion
of unregistered copyright claims that decorates a lot of open-source code
is close to being meaningless — the holders have copyright in law,
certainly, but their options to exercise that right under U.S. law are
scant. Besides the difficulties about showing actual damages,
copyright-infringement claims time out after three years (17 USC
507(b)).

This doesn't mean you can or should completely ignore other peoples'
copyrights, even on small patches. People want to be credited, having
their copyright on a piece of code makes a nice territorial marker, and it
would be bad form to remove the name. Being a member of the open-source
community is not just about doing anything you can legally get away with,
but doing the right thing as well. If you breach community practice,
you may well find yourself being flamed or shunned.

In the FAQ section, we advised you, if you are a project leader, to
claim a collective-work copyright on your project.Registering copyright
will protect your ability to set or alter the project's distribution terms
without securing the explicit consent of every contributor back to the
beginning of time. If you want to secure this right, the other thing you
should do is reject patch bands and submissions that carry explicit
licenses on them, so that the license associated with your collective-work
copyright is the only one in the distribution.

Trademark

Historical open-source licenses have tended to intermingle copyright
with trademark issues in confusing ways. Here is a brief primer on the
function of trademark law. Like the discussion of copyright, it assumes
U.S. jurisdiction, but trademark law does not vary much across developed
countries and most of the logic applies elsewhere.

Trademarks, not copyrights, are used to indicate the source or origin of
goods. The application of a trademark on goods by the trademark owner
allows him to indicate that he is the one who is responsible for the
quality of the goods. To the extent that his trademark is known and
respected by consumers, they will buy his goods instead of competing
goods by others not bearing that trademark. We all have experience of
this "brand" shopping when we go to the store.

The appropriation of a trademark on competing goods is illegal. This is
true whether the trademark is registered or is a common law trademark,
although there are other advantages for registering a trademark with your
country's registry of trademarks.

When someone takes Jello brand gelatin and incorporates it into a new
dessert, he is not allowed to call his dessert Jello because trademark
law prohibits that. He can, if he wishes, say that Jello was an
ingredient, but he does not have to, and he cannot imply by doing so
that the Jello company is the source or origin of his new dessert.

Copyright law serves a very different purpose. It is intended to
prevent the making of unauthorized copies or derivative works so that the
author can profit from his own work without competition. Derivative works
can also be prevented, primarily to allow the author to profit from his own
work, but also to prevent competitors from incorporating the expressive
content of the original into other works with which the original author may
disagree.

Copyright law is orthogonal to trademark law; the two don't serve
the same purposes.

Patent law

Patents, unlike copyrights, protect ideas rather than the expression
of ideas. In order to be patented an invention must be novel, useful, and
not of an obvious nature. A patent may be challenged on the basis of prior
art (proof that the idea in question is not novel). Term of patent was 17
years from date of issue before 1995, but is now 20 years from date of
application. The enabling legislation for patents is 35 USC.

That's the theory. In practice, the U.S. Patent and Trademark office
has proven so incompetent at skeptically evaluating software patent
applications that in the software world the novelty and non-obviousness
requirements are widely regarded as bad jokes. Application is expensive,
requiring the services of a patent attorney and patent-office fees; the
typical cost
is in the $8,000-$10,000 range.

Given those costs, it is very rare for open-source projects to
apply for patents. Use of the software-patent system has become a
near-monopoly of large corporations, who accumulate huge war chests
of junk patents and swap them in cross-licensing deals that make them
effectively immune to patent lawsuits while leaving the independent
developer totally exposed.

This is a looming, potentially very serious problem for open-source
development. It is typically impossible for developers to know what
patents they may be violating, and defending against an infringement
lawsuit can be prohibitively expensive. The League for Programming Freedom was
formed in 1989 to attempt to change the system, but has accomplished little
beyond giving warning of the danger.

The situation is not totally bleak. Legally, software licenses are
considered to convey an implicit grant of rights to patents held by the
licensor. With a few high-profile exceptions such as the Unisys GIF patent,
software patent holders have not brought or threatened infringement
lawsuits against open-source projects. This may be because a successful
obviousness or prior-art defense against an infringement lawsuit
invalidates the patent; thus, junk patents are more effective as bargaining
chips than actual weapons.

If you are ever threatened with a patent-infringement lawsuit, the
most effective thing you can do is probably to reply with a pointer to
source code that constitutes prior art with the threat that you will get the
patent invalidated if they actually sue. If this happens to you, raise the
alarm on a public forum such as Slashdot. Publicity and bad press may
help scare off the attacker.

Trade Secrecy

Trade secrecy law is the flavor of intellectual-property law least
likely to affect open-source projects and licenses; we discuss it here
briefly more for completeness than anything else. In the U.S, trade
secrecy is governed by state rather than federal law, but forty states have
adopted the same Uniform Trade Secrets
Act (UTSA); all quotes in this section are from the text of that
act. The key points of trade secrecy law in non-UTSA states are generally
consistent with UTSA and fairly constant, varying little across
jurisdictions and not in fact having changed much since the late 19th
century.

To maintain a trade secret, a firm must identify a “
formula, pattern, compilation, program device, method, technique, or
process, that: (i) derives independent economic value, actual or potential,
from no being generally known to, and not being readily ascertainable by
proper means by, other persons who can obtain economic value from its
disclosure or use, and (ii) is the subject of efforts that are reasonable
under the circumstances to maintain its secrecy.”. It has to be
valuable, its value has to be at least partly in its secrecy, and you
have to work at keeping it secret.

Unlike patents, there is no originality test, and several firms
may hold the same trade secret independently. Patent requires that
a description of the process be published, but trade secrecy forbids
it. Parents have a limited lifespan, but trade secrecy can legally
be maintained forever.

All that trade secrecy law normally does is give companies the right
to sue for misappropriation: “the acquisition of a trade secret by a
person who knows or has reason to know that the trade secret was acquired
by improper means.”. Under some circumstances, courts have been
known to issue restraining orders preventing violating products from
shipping.

Notably, the UTSA and its kin this do not
protect trade secrets against reverse engineering or independent
rediscovery. Again, this is unlike patents, which allow the patent-holder
to prosecute others who infringe regardless of the source of the
infringers' ideas.

Normally, therefore, open-source projects should not have to worry
about trade-secrecy violations. The very fact of publishing a technique in
open source abolishes the secrecy, The only potential exposure is if a
project member is an employee or contract partner of the secret-holder, or
receives privileged information from such an employee or contract
partner.

In the later case, all turns on how a court will apply the
“know or should have known” test. While courts have been
fairly willing to nail employees who misappropriated, successful
prosecutions of third parties who merely passively received trade secrets
(as opposed to, say, bribing an employee to procure them) are not
common.

In the early phases of the fight over the DECSS, the DVD Copy Control
Association sued in California state court under a theory that the release
of DeCSS violated vendors' trade-secrecy rights in their encryption
technique. This position became impossible to sustain when the DVDCCA's
lawyers published the DeCSS source code in evidence submitted to the court.
When they attenmpted to have the evidence of their blunder sealed, the
judge laughed them out of court and the misappropriation-of-trade-secrets
theory was dropped. The whole episode would have quite funny if the
DVDCCA's lawyers had not had the bigger gun of the DMCA to fall back
on.

License theory

The license you choose defines the social contract you wish to set up
among your co-developers and users. It does so by passing some of the
rights you have (as a copyright holder under 17 USC and the Berne
convention) to users and redistributors of the software.

By setting out the terms under which material can be used,
open-source licenses grant rights to the users that protect them from
certain arbitrary actions by the copyright holders. They can also protect
the copyright holders from the users, e.g, with disclaimers of
liability.

Copyrights are not licenses

Many hackers are confused about the difference between copyrights and
licenses. Start with this: if you put a copyright but no license on a
piece of software, you retain all rights and cede none. Nobody else can
legally redistribute it, or any derivative work of it, without obtaining
your explicit permission.

To grant rights to your users, you need to attach a license. The
license may be as simple as one line after the copyright that says "Use,
redistribute, and modify freely", but it has to be there or you don't have
open source.

You do not, in general, have the right to change or remove someone
else's copyright (whether registered or not). You may, under some
circumstances, have the privilege to override someone else's license (we'll
discuss those circumstances in more detail later).

Open source and copyrights

In proprietary software, the license terms are usually designed to
protect the copyright. The license terms are a way of granting a few
rights to users while reserving as much legal territory is possible for the
owner (the copyright holder).

In open-source software, the situation is usually the exact opposite;
the copyright is used to protect the license. The only rights the
copyright holder always keeps are to enforce the license terms. Otherwise,
most choices pass to the user. In particular, the copyright holder cannot
change the terms on a copy you already have. Therefore, in open-source
software, the copyright holder is almost irrelevant under
normal circumstances — but the license terms are very
important.

Normally the copyright holder of a project is the current
project leader or sponsoring organization. Transfer of the project to
a new leader is often signaled by changing the copyright holder.

Some projects choose to assign copyright to the Free Software
Foundation, on the theory that it has an interest in defending open source
and lawyers available to do it.

What qualifies as open source

For licensing purposes, we can distinguish several different kinds of
rights that a license may convey. Rights to copy and
redistribute, rights to modify for personal
use, and rights to redistribute modified
copies. All these right are recognized in the copyright
statyte, and by default reserved to the copyright holder. A license may
grant, restrict or attach conditions to any of these rights.

The Open
Source Definition is the result of a great deal of thought about
what makes software ``open source'' or (in older terminology) ``free
software''. Its constraints on licensing require that:

An unlimited right to copy be granted.

An unlimited right to redistribute be granted.

An unlimited right to modify for personal use be granted.

The guidelines prohibit restrictions on redistribution of
modified binaries; this meets the needs of software distributors, who
need to be able to ship working code without encumbrance. It allows
authors to require that modified sources be redistributed as pristine
sources plus patches, thus establishing the author's intentions and an
``audit trail'' of any changes by others.

The Open Source Definition (OSD) is the legal definition of the `OSI
Certified Open Source' certification mark, and as good a definition of
``open source'' as anyone has ever come up with. All of the historically
important licenses (MIT, BSD, Artistic, and GPL/LGPL) meet it (though some,
like GPL, have other restrictions which you should understand before
choosing them).

Note that licenses which allow non-commercial use or redistribution
only do not qualify as open-source licenses, even if
they clauses tacked on to GPL or some other standard license. Such
licenses discriminate against particular occupations, persons, and groups.
They make life too complicated for CD-ROM distributors and others trying to
spread open-source software commercially — is that `commercial use'
or not?

(This difficulty is not just theoretical. In Storm Impact Inc. vs.
Software Of The Month Club (13 F. Supp. 2d 782, 1998) a court awarded
$20,000 in damages for copyright infringement against a distributor of
shareware anthologies for violating a license that barred commercial
distribution.)

Are open-source licenses enforceable?

The short answer is: “Nobody knows. And the answer is not
obvious. But there is promising case law.”

As of September 2002, no open-source license has been tested in
court. The closest thing to precedent is Planetary Motion
vs. Techplosion, (2001 U.S. App.; 14 Fla. L. Weekly Fed. C
1159), in which an appellate court affirmed that the reputation incentives
in open-source development are grounds for holding a trademark even
when conventional “commercial use’ is absent.

The answer is not obvious because in law, licenses are contracts. At
law, contract must meet two tests: (a) there must be an exchange of value,
and (b) there must be a meeting of the minds between the parties. A
contract is an agreement to exchange; if either the exchange or the
agreement is not present, the contract is invalid.

An exchange of value does not require money to change hands.
Although money may not change hands, it is easy to see that the parties to
an open-source license are engaged in an exchange of value. The grantee is
acquiring the valuable right to use, modify, and redistribute the software.
The grantor is collecting a return in reputation, and achieving various
other goals which may have economic impact (e.g. by creating a service
market, promulgating a technical standard, etc.). Planetary
Motion is helpful here; it indicates that courts can notice
these effects and may rule based on them.

The ‘meeting of minds’ is a more problematic issue.
Classically, the law has required a verifiable gesture of assent, such as a
signature, to establish that an agreement has taken place. This is the
reason commercial software is so loaded down with shrink-wrap and
click-wrap licenses. By clicking on the pop-up displaying the license, you
give your consent to the contract terms in that license. Your gesture of
assent with respect to a shrink-wrap license is the act of breaking the
seal on the package. This is controversial, and some (state-level)
U.S. jurisdictions have declined to enforce various clauses of vendor
shrink-wrap licenses.

Implementing either shrink-wrap or click-wrap would pose severe
problems for the open-source community. It's not possible to shrink-wrap a
download. It's hard to see how to apply a click-wrap license to a non-GUI
program — still less something like a service library that doesn't
have an interactive interface at all. Taken to an extreme, “privity of
contract” might require a registration or click transaction to take place
the first time any shared library is loaded!

There is a fundamental conflict between the necessity of showing
individual consent to contract terms and our highly decentralized and fluid
channels of distribution. A developer may post software to several
distribution sites, unaware of who his users are or will be. A distributor
may download that code, patch it, and ship it on a CD-ROM. A user will
often receive it as part of a distribution of thousands of software
packages by different authors. Which parties in the chain could or should
be required to consent to the license, and how that consent could be
registered, is not at all clear.

The GPL attempts to get around this problem by not being a contract
at all. There is no "you agree" language in it. Instead, the terms
are tied directly to the copyright on the software. But many lawyers
think that the very fact that GPL is not a contract
will make it unenforceable in a U.S. or English court. European courts,
with a less contract-oriented legal tradition and a notion of authors'
"moral rights" under the Berne Convention, might be more likely to
affirm.

There is, however, case law under which the presence of a contract
can be imputed even if the meeting of the minds does not take place until
after the product is acquired. One is provided by ProCD,
Inc. v. Zeidenberg (86 F.3d 640, 5th Cir. 1996), one of the key
shrink-wrap cases. The product at issue was a compilation of data and
(original) software. The issue was the enforceability of the license on a
user who misappropriated some (uncopyrightable) portions of the
data.

The appeals court noted that there are common consumer transactions
where not all the terms of the agreement are known at the time of purchase
— insurance policies, which are delivered after payment; airline and
concert tickets, which have printed terms often seen only after they are
bought, and consumer electronics, which contain warranty disclaimers inside
the packaging. The court also considered the difficulty of conducting
phone or on-line sales if the terms of a license had to be read beforehand,
or the terms subject to invalidation later (a weaker version of the
open-source community's problem).

The appellate judge applied the concept that goods may be sold
subject to inspection and the buyer's right to reject. He allowed that
shrink-wrap licenses could be enforceable, provided the seller structured
the deal so that (a) acceptance of the contract takes place at the time the
license is inspected, and (b) at that point the user
has the option to accept the contract or collect a refund for the goods.
This is the reason Microsoft End-User License Agreement contains the refund
clause — though Microsoft has notoriously ducked and weaved about
whether it or its hardware OEMs is responsible for the refund.

The ProCD, Inc. v. Zeidenberg case makes the
critical point that the "meeting of minds" takes place at the moment that
the user or developer becomes aware of the terms of the license and chooses
to either discard the software or continue working with it. This point
suggests a different way to satisfy the consent criterion, one which is
in harmony with open-source community practice.

Open-source developers are primarily concerned with misappropriation
not of their runnable binaries but of their source code. We don't really
care whether we have a valid contract with the end-user, because our
licenses don't regulate use! (Indeed, under the Open Source Definition's
non-discrimination clauses, most kinds of use restriction would be
forbidden.) We are mainly concerned that developers
(especially developers who might be creating derivative works) know the
terms.

Therefore, to satisfy the ProCD,
Inc. v. Zeidenberg requirements in our context, it is especially
important that source distributions advertise their
license. Fortunately, community practice is already to do this.
Sites like Freshmeat and SourceForge make the license type a prominent
part of the package metadata. Putting the license in a root-directory
file with a standard name like LICENSE or COPYING is also good; so is
referencing that file from the README.

This is also an excellent reason for the community to move towards
having a small number of standard licenses. This would in itself make
it harder to sustain a claim that a user or developer was excusably confused
about what license terms applied to the code.

Copyleft and derivative works

Copyleft licenses like the OSL and GPL raise another issue: what, for
purposes of software, constitutes a derivative work? The question matters
because copyleft licenses require that any detrivative work of the covered
code be issued under the same license as the covered code.

‘Derivative work’ is an important term of art in
copyright law; see 17 USC 101 for
the statutory definition. There are (at least) four different theories
circulating among open-source developers on what constitutes a derivative
work in software.

The strictest theory holds that software B is a derivative work of
software A only when the source code of B includes an identifiable portion of
the source code of A.

The historical consensus theory among hackers also defines B as
a derivative work of A if B statically links to code compiled from
A.

The Free Software Foundation's theory adds dynamic linking; that is,
B is also a derivative work of shared library A if B calls services from
A. FSF has stated its willingness to go to court for this position.

Linus Torvalds has taken the position that any Linux kernel module (which
calls kernel services by a dynamic-linkage-like mechanism) is a derivative
work of the kernel and therefore comes under GPL terms.

There has been no court test. OSI takes no position on which of
these theories should be correct. However, the
authors predict that courts will uphold the strictest theory only.

To see why, consider the case of two scientific papers which
reference each other. The fact that paper B calls paper A (references it
for support) does not make B a derivative work of A. This remains true
whether B and A are published together in a symposium (analogous to static
linkage) or separately (analogous to dynamic linkage). Computer programs
are defined in 17 USC as literary works, and courts have in the past leaned
heavily on anthologies like the above.

Also, courts like bright-line tests. They
dislike tests which would get them into murky
definitional issues related to technology they don't understand.

We recommend playing by the FSF's stricter rules until court test;
they could be upheld. But we think it would be unwise for anyone in the
community to count on that happening, especially since the FSF's stance is
an interpretation of a license that may well not be enforceable at
all.

Choosing a license

Choosing an appropriate license for your project is not actually
very complicated. All you have to do is ignore a lot of history.
Otherwise you'll be distracted by a profusion of alternatives that are
either duplicative of each other, or inappropriate for modern conditions,
or tied to a particular corporation/institution/person/product, or more
than one of these.

The first and most basic decision you need to make is: do you want
a copyleft license or not? A copyleft license requires
that its terms be propagated to derivative works. Such licenses are
sometimes called `infectious' or `viral'. (The Free Software Foundation,
which champions copyleft licenses, dislikes these terms, and we
will not use them again.)

For some people, this is a matter of religious fervor,
Pro-copylefters tend to see open-source development as a crusade for lofty
moral principles, including opposition to many forms of intellectual
property. They see copyleft licenses as subversive tools to undermine
intellectual-property monopolies and promote sharing.

Anti-copylefters tend to be pragmatists more interested in good
engineering than in pursuing political or moral absolutes. Many are
offended by what they see as the intrusive nature of copyleft and regard
its spread as a sort of Borg-like coercion, forcing people to share
via legal trickery whether they really want to or not.

Historically, the most fervent pro-copylefters have gravitated to the
Free Software Foundation and the GNU Project. The culture around the BSD
operating systems, on the other hand, is traditionally strongly
anti-copyleft. The debate between these camps is a perennial flame-war
that goes back many years now.

But the picture can't be oversimplified. There are people (notably
Linus Torvalds, the inventor of Linux) who have chosen copyleft licenses
as a form of social engineering, but are not ideological about them.
On the other hand, pro-copylefters often choose non-copyleft
licenses when releasing code that they think too many people would be
frightened out of using otherwise — this is particularly true of
people who write function libraries.

Most developers seem to adopt a middle ground. They use copyleft
licenses like the GPL for standalone programs, but non-copyleft licenses
like BSD for code that will be linked from other code. OSI takes no
position on whether or not to use copyleft licenses for standalone
programs. OSI does, however, endorse using non-copyleft licenses for
function libraries and the code emitted by tools such as parser generators.
Too much confusion, uncertainty and dread is generated by concerns about
whether particular kinds of run-time linkage might deprive a developer of
rights he wishes to preserve.

There is a category of semi-copyleft licenses. These require that
derivative works that merge with the program be open source, but carve
out exceptions for certain kinds of closed-source module or extension.
The Mozilla Public License (MPL) is the archetype of this class. These
are useful for project sponsors who wish to retain (or be able to sell)
the right to make proprietary add-ons

OSI recommends that you choose from among our "Best Practice"
licenses: The Academic Free License (AFL), the Open Software License (OSL)
the GNU General Public License (GPL), and the Mozilla Public License. We
have been evaluating and thinking about licenses for years now, and we
judge these are currently best written and the legally most sound in their
respective functional categories (this evaluation may change as licensing
technology evolves). You can read a detailed comparison supporting this evaluation.

If you choose a copyleft license, your best-practice alternatives are
GPL or OSL. The choice between OSL and GPL is a delicate one. OSI believes
that OSL is more likely to be enforceable than GPL on strict technical
grounds; on the other hand, GPL has a large constituency, its own advocacy
organization, and lawyers with a history of successfully enforcing
compliance out of court.

If you choose a non-copyleft license, your best-practice choice
is the lightweight AFL.

If you want a semi-coplyleft license, we recommend MPL. It has
language relating to liability, indemnity, and patents that is mainly
relevant to commercial corporations with intellectual-property rights of
their own to protect.

A good rule of thumb is this: if you have a legal department to keep
happy, start by trying to get them to accept AFL. If they won't, fall back
to MPL. If you don't have a legal department, go with AFL and don't spend
energy worrying about it. None of these licenses has been tested in court,
and our "best practice" category has already been filtered by professionals
for licenses most likely to stand challenge and to protect you.

License compatibility and combination

Because open-source projects frequently combine code from many
different sources, the question of license combinations often comes up.
That is: what is the legal result if code under license X and license
Y are combined? What restrictions must developers observe?

With over a thousand possible two-way combinations, exhaustively
tabulating all of them would be a job for an army of lawyers and a sheer
nightmare for anyone else. However, it is possible to reason out
answers for the most important cases by thinking about what requirements
licenses on individual parts export to the rest of the program.

When two licenses A and B are combined, the following things can
happen: (1) A subsumes B, (2) B subsumes A, (3) A adds to B so that
you must observe the requirements of both, or (4) A and B clash —
they cannot both be satisfied.

Here are some rules for license composition:

The MIT license is like an identity element. It exports nothing.
Combine it with any other license X and you get the bundle of rights
and requirements that X implies.

The BSD license (and equivalents like NCSAOL, SCL, and VOSL)
exports only its no-endorsement clause. This clause is widely regarded as
a no-op, since all it does is caution grantees that they are not being
granted rights that the law says they didn't have to begin with.
Accordingly, BSD code is routinely combined with more restrictive licenses
without anybody giving it a second thought. This has never led to legal
trouble, and the community would rise up in unanimous wrath if anyone ever
tried to make legal trouble over it.

AFL plus a BSD-equivalent license gives you AFL terms, because
the AFL no-endorsement clause is equivalent to BSD's. Thus, AFL and
BSD code may be freely mixed.

AFL plus MPL gives you MPL terms.

Any two licenses with a different choice-of-law provision will clash.
That is, you cannot satisfy both conditions. It is a bad idea to mix
code under these circumstances. The summary table at the end of this
HOWTO tabulates information on choice-of-law venues.

The GPL is like aleph-null. If you combine anything else with it,
you'll get either GPL conditions or a clash. This case has been
well-investigated; the Free Software Foundation keeps a
compatibility
list and its conclusions have been checked by lawyers. The
summary table at the end of this HOWTO includes that information.

This, within the best-practice licenses the composition rules are
simple. GPL subsumes LGPL which subsumes MPL which subsumes AFL. The only
complicating factor is that GPL/LGPL avoid a clash with MPL only if the MPL
dual-licensing option is set to GPL.

It is also worth knowing that splash-screen and delta-notice
requirements are routinely ignored when people think about license
composition, and doing so is unlikely to lead to trouble. Delta notices
are a nearly universal community reflex even when licenses don't require
them. Splash-screen requirements have always been honored more in the
breach than in the observance, and are so easy to evade with command-line
switches and environment settings that they're unenforceable as a practical
matter. Anybody trying to enforce one against an open-source hacker's
right to design as he sees fit would be conceded legal correctness and
flamed to a toasty crisp anyway.

The tricky cases — composition of two corporate-style licenses
— seldom come up in practice.

Changing an existing license

For purposes of this discussion, we'll assume that the project
leader holds a copyright on the distribution as a whole. To the
extent project leaders have special rights, they are legally derived
from that copyright.

You can change the license on a piece of code under any of the
following conditions:

If you are the sole copyright holder

If you are the sole copyright holder, registered or unregistered, you
choose the license (the terms of distribution) and can change the license
at any time.

If you are the sole registered copyright holder

If all copyrights other than yours are unregistered, you may change
the license and no other copyright holder has standing to object, unless
they can show that the license change has caused them actual monetary
damages.

If you obtain the consent of all other copyright holders

This could be a large and ill-defined class. In theory under the
Berne Convention, anyone but you who has contributed code also has a
copyright in that portion of the work. In practice, only holders of
registered copyrights in the code are likely to even get standing
to object.

If no other copyright holder could be harmed by the change

First, suppose you are a holder of a registered copyright on
a project's code. The project lead changes the license. What are
your options?

To have a legal cause of action against the project lead for changing
the project license, you would have to demonstrate both as a matter of law
that you had the right to block the license change (e.g. a valid
copyright), and that the license change actually did an injury to your
interest. Where there is no injury there is no cause of action. (This
rule is applied everywhere in law, not just in copyright law.)

The strongest possible interest you as a copyright holder can have in
an open-source project is to continue to see it continue to be distributed
with the same grant of rights to licensees that obtained at time of
contribution, and with no more legal risk to yourself than existed at time
of contribution. Your interest might be less specific — for
example, many contributors are indifferent to specific license terms as
long as the license is open-source — but for purposes of figuring
potential injury we will reason about the strict criterion.

Under that criterion, it is harmless to change from one license to
another if doing so merely adds mutual protections for licensors or licensees
(things like an explicit rather than implicit patent grant) without
actually changing the grant of rights. It's also safe to change clauses
that are informational, such as warnings about export regulations. In
software terms, a license change that fixes implementation details without
changing the output cannot be a cause of action. Neither holders of
registered nor unregistered copyright would have standing to object.

In practical terms, this means that some license upgrades are legally
safe. MIT to BSD, for example: the only change is a no-endorsement clause
that merely affirms that the grantor is not lifting restrictions that were
already present in trademark law. BSD or ASL to AFL; for legal purposes,
AFL is a cleaned-up expression of the rights grant implied in traditional
academic licenses. GPL to OSL for standalone programs (differing
interpretations of whether linkage creates derivation make the case
unclear for libraries).

Note, however, that an `upgrade' from a copyleft license to a
non-copyleft license (or vice-versa) would be a different matter. If you
are a GPL partisan, you would be injured by a move to a non-GPL license,
and vice-versa. These changes are not safe and could be causes of legal
action for copyright infringement by a holder of
registered copyright (who therefore does not have to
meet the actual-damages test).
Holders of unregistered copyright would have no standung except by
registering the copyright after the fact of infringement, and then
would have to meet the difficult actual-damages standard.

Thus, the `no harm, no foul' rule does mean that project leaders do
have the discretion to make technical upgrades of licenses without having
to secure the explicit consent of all copyright holders.

If the license is attached to your collective-work copyright

Now the difficult case. What if you are the project leader but not
the sole copyright holder, and you want to change the license to one
substantively different? First, we'll discuss the legal situation. Then
we'll discuss the ethical problems.

The legal theory

In the past, the open-source community has generally believed that
the unanimous consent of all copyright holders, whether registered or
unregistered, was always needed to change the license on an open-source
project, making changes to licenses near impossible in practice. It turns
out this is not normally true, for at least two reasons.

First, only registered holders of copyright have standing to object
on statutory grounds; an unregistered holder must show actual (monetary)
damages from the license change. Second, the pertinent portion of the
U.S. Federal Code allows that software projects can be of two distinct
kinds with different allocations of rights that affect this question. But
under either theory, project leaders have the legal
privilege to issue the code under license terms of their choice. What
differs between these theories is whether contributors other than the
project leader also have that right.

The traditional hacker folk theory that unanimous consent is required
corresponds to what under the definitions of 17 USC 101 is
called a "joint work". In a "joint work", all copyright holders share the
same copyright on the work. Rights in the work are distributed
symmetrically, including the right to control license terms.

It turns out that in one important respect, though, hackers have the
"joint work" theory backwards. The intent of the law is that no joint
copyright holder can infringe against any other (House Report 94-1476,
pertaining to 17 USC 201). Therefore, any co-author of a joint work is
free to distribute the work on any terms he chooses — including
changing the license, and including taking a copy closed source!

But for reasons we will discuss in detail, the "joint work" model
probably does not actually apply to open-source projects. Rather, they
look more like what the law calls "collective works", a new category
created by the copyright-law revision of 1976. One of the purposes of the
1976 revision was to scupper a line of bad case law that overextended the
concept of "joint work", and courts have since shown a marked preference
for narrowing the conditions of joint work even further than statute
required.

A "collective work" is a creative work of a group of individuals who
do not share a common copyright in the result.
Individual portions of such a work may (and often do) have copyrights, and
there may also be a collective-work copyright on the work as a whole. The
difference is practically relevant because, according to 17 USC 201 the
holder of the collective-work copyright is legally privileged to set the
distribution terms for the package as a whole (in the statute, this
expressed negatively as a statement that the collective-work copyright
holder acquires only those rights).

In an unpublished case, Campbell vs. Lavery, 1997 U.S. App. LEXIS 754
(9th Circuit), the court's finding turned specifically whether a
collaboration between two programmers was a collective or a joint work.
The court observed that the project could have been found to be either a
collective or a joint work, depending on the intent of the programmers.
They found it to be a collective work based on the fact that (a) one party had
written only twenty lines of code, and (b) the behavior of both parties
showed no intent that they be regarded as coauthors.

Campbell vs. Lavery is appellate case law indicating that
collaboratively-written software is a collective rather than joint work
when programmers function in identifiable author/contributor roles. An
Albany Law Review article from the same year, A
Narrow View of Creative Cooperation: The Current State of Joint Work
Doctrine, shows that Campbell vs. Lavery is no fluke. They cite
numerous cases showing that courts have historically relied on the
intent-of-coauthorship test to distinguish joint works from collective
works, and continue to do so today. For the work to be joint, all coathors
must show an intention to regard and credit each other as coauthors.

This is, of course, not the case in most open-source projects.
Community practice recognizes a strong distinction between people who
contribute patches and co-authors. Indeed, community practice agrees with
the intent requirement — normally one becomes a co-author on a
project after applying for that status and having it granted by the
existing author(s), in recognition of major and continuing contributions
to the project.

In fact, if the rights structure of a large project even becomes an
issue, a court might well find it to be joint work with respect to core
contributors but a collective work with respect to patchers. But this
would make little practical difference. When we wrote earlier that
registering copyright on an ordinary patch is probably pointless, we
meant that it wouldn't convey a right to block distribution under either
the joint-work or collective-work theory.

The legal practice

We recommended earlier that if you are a project leader, you should
assert a collective-work copyright on the project. Now it should be clear
why. Project authors or coauthors have a legal basis for asserting that
under 17 USC 201 they have control of the project license and the authority
to change it, irrespective of the wishes of other contributors.

Note that changing a license attached by an individual contributor to
his or her copyrighted portion of the project is an entirely different
matter. Holding the collective-work copyright won't let you do that, unless
it's a no-harm-no-foul change of the kind discussed in the previous
section. even then, the change would apply only to the instance of the
code present in your distribution, not to other copies separately
distributed). But there is no law requiring you to accept contributions
with licenses attached to them, either — and in general, you
shouldn't.

Community practice on license changes

This section is not about the law. It is about the community
norms that have been evolving since the birth of the hacker culture in
the 1960s. (One author of this HOWTO has been observing these norms
since the mid-1970s, and has been writing about them since 1991.)

Historically, hackers have not developed a consistent theory about
who `owns' a project and controls the license for the project. In
reasoning about division of technical authority, project credits, and other
matters, we have tended to follow the "collective work" model. We routinely
cede great decision-making authority to project founders and
leads, treating them as editors of the collective work. We do not demand that
every person who has ever contributed a ten-line patch be listed as a
co-author.

On the other hand, in reasoning about licensing we have tended to
follow a model that is rather like an mirror image of joint-work —
assuming that any contributor can block a license change, and even taking
for granted (incorrectly) that that's what copyright law requires. This
attitude seems to spring from a deep-seated fear that if projects are not
indissoluably welded to their licenses, they could be hijacked into closed
source, or that contributors might otherwise find their work being
distributed on terms abhorrent to them.

That fear, and the community practice that springs from it, deserves
some respect. We have made a case that project leads do in fact normally
have the legal authority to control licensing, but that does not mean that
we think this authority should ever be exercised in an arbitrary or
high-handed manner. Project contributors are owed more than that,
ethically if not under the strict letter of the law. Anyone who abused
this privilege (by, say, moving a project to a closed-source license) would
be quite likely to have his project forked out from under him by enraged
hackers.

At the same time, the issue of upgrading licenses is more urgent now
than it has ever been before. As open-source development becomes more
important in the economy and more disruptive to various monopolies, it is
attracting powerful enemies. Those enemies (Microsoft, the RIAA, the MPAA
and others) are accustomed to using attacks through the legal system to
suppress competition and innovation.

The licenses we have traditionally used are not adequate to defend us
against these attacks. They have particularly serious weaknesses in the
area of patent liability. We need to upgrade — and we need to change
our community practice so that the license `software' we use to interface
with the legal system can evolve to meet future threats.

Solving this problem will require flexibility and new behavior
from everybody involved — project owners, project contributors,
and everybody in the community. We have some recommendations about
how to cope.

First: we need to stop treating project licenses as immutable sacred
texts, ideological banners, or territory, and start thinking of them as
functional software — which, like all software,
needs periodic upgrading.

In the past, we've had a strong tendency to organize our
sub-communities around licenses; Perl people think of the Artistic License
as part of their subcultural identity, BSDers are attached to the BSD
license, and Free Software Foundation partisans can't imagine life without
the GPL. The problem is that in the new high-threat legal environment
we now face, all these licenses are broken, or
at least less than the best license technology available.

The profusion of corporate open-source licenses has not helped. They
are all at best minor technical improvents on the MPL of 1998, and not
in general re-usable.

Thus, staying attached to our licenses as icons is likely to cost us
big-time. As a community, we can't afford to do that any more. We need to
learn how to adopt new license technology quickly and effectively.

Second: to solve this problem, we need to go beyond recognizing that
project leads have the legal authority to set licensing terms, and cede
them the ethical authority to do it as well. Informally we already do
this for small, single-user projects that are only patched by other
people. We need to adopt a similar policy about major multi-author
projects as well, projects as big as the Linux kernel or Apache or
SAMBA or the BSDs.

The authors have a specific recommendation about this. We recommend
that major projects elect a "license czar" whose job it is to keep the
project's licensing technology current, modify the project license when
needed, and keep in touch with other license czars and expert groups like
the Open Source Initiative.

We also recommend that project contributors no longer attach explicit
licenses of any kind to their patches or modules, and consent to having
existing contributor licenses removed. Bare copyright notices are OK, but
explicit licenses on contributions complicate the legal picture in
unhelpful ways. It's best if every project has one
license, incorporated by reference in its parts. (Practice has been
moving in this direction anyway.)

Third: we recommend that project leaders show respect for their
contributors by preceding major licensing changes with a public comment
period. It is important not just that the right thing be done, but that
the right thing be seen to be done.

Good licensing practice

Here's how to translate the theory above into practice:

Make yourself or the FSF the registered copyright holder

Make yourself the copyright holder if your primary concern is
maintaining the flexibility to choose and alter the license terms. Making
FSF the copyright holder will put some lawyers and funding on your side,
but the FSF will be reluctant to accept a non-GPL license, and might
at some future date change yours.

If you have a stable relationship with a sponsoring organization that
retains lawyers, you might wish to give copyright on your project to that
organization. Beware, however, that matters may become awkward if you ever
sever your ties with the sponsor.

Use a license conformant to the Open Source Definition

The Open Source Definition is the community gold standard for
licenses. The OSD is not a license itself; rather, it defines a
minimum set of rights that a license must guarantee in order to be
considered an open-source license. The OSD, and supporting materials,
may be found at the web site of the Open Source Initiative.

Don't write your own license if you can possibly avoid it.

The OSD-conformant licenses are part of a well-established
interpretive tradition. Developers (and, to the extent they care, users)
know what they imply, and have a reasonable take on the risks and tradeoffs
they involve. Therefore, use one of the `Best practice' licenses carried
on the OSI site if at all possible.

If you must write your own license, be sure to have it certified
by OSI. This will avoid a lot of argument and overhead. Unless
you've been through it, you have no idea how nasty a licensing
flamewar can get; people become passionate because the licenses are
regarded as almost-sacred covenants touching the core values of the
open-source community.

Furthermore, the presence of the interpretive tradition established
by the OSD itself may prove important if your license is ever tested in
court. At time of writing (late 2002) there is to our knowledge no case
law either confirning or denying the enforceability of any open-source
license. However, it is a legal doctrine (at least in the U.S., and
probably in other common-law countries such as England and the rest of the
British Commonwealth) that courts are supposed to interpret licenses and
contracts according to the expectations and practices of the community in
which they originated.

License analysis and comparisons

In this section, we compare and contrast the different
open-source licenses certified by OSI. We try to identify special
features of interest to potential users, but don't cover the details
of legal boilerplate such as warranty disclaimers and choice of law;
for that, read the licenses themselves.

Summary of license characteristics

The '#' column is the number of the generation the license belongs
to.

Table 1. Summary table

Full name

Tag

#

OSI status

GPL-compatible?

Choice of law?

Consider using:

Academic Free License

AFL

3

Best Practice

Yes

None

-

Apache Software License

ASL

2

Obsolete, still popular

No

None

AFL

Apple Public Source License

APSL

2

Not recommended.

No

None

MPL

Artistic License

AL

1

Not recommended.

No

None

AFL

Attribution Assurance License

AAL

2

Quirky. Interesting.

Yes

None

AFL

BSD License

BSD

1

Obsolete. Still popular.

Yes

None

AFL

Common Public License

CPL

2

Current

No

NY, USA

MPL

Eiffel Forum License

EFL

2

Not recommended

Unknown

None

AFL

GNU General Public License

GPL

1

Best Practice

Yes

-

GNU Lesser General Public License

LGPL

1

Not recommended

Yes

None

-

IBM Public License

IBMPL

2

Not recommended

No

NY, USA

MPL

Intel Open Source License

IOSL

2

Not recommended

Yes

AFL

Jabber Open Source License

JOSL

3

Not recommended.

No

CA, USA

MPL

MIT License

MIT

1

Obsolete. Still popular.

Yes

None

AFL

MITRE Collaborative Virtual Workspace License

CVW

2/3

Not recommended.

Unknown

None

-

Motosoto Open Source License

MOSL

3

Not recommended.

No

The Netherlands

MPL

Mozilla Public License

MPL

2

Best Practice

No

CA, USA

-

Nethack General Public License

NGPL

1

Obsolete.

Yes

None

GPL

Nokia Open Source License

NOKOS

3

Not recommended.

No

Finland

MPL

OCLC Office of Research Open Source License

ORPL

2

Not recommended.

No

Ohio, USA

-

Open Group Test Suite License

OGSCL

2

Not recommended.

No

None

-

Open Software License

OSL

3

Best Practice

No

None

-

Python License (old CNRI version)

CNRIPL

2

Obsolete.

Yes

VA, USA

PSFL

Python Software Foundation License

PSFL

2

Not recommended.

Yes

VA, USA

-

Q Public License

QPL

2

Not recommended.

Yes

Norway

AFL

Ricoh Public Source License

RPSL

3

Not recommended.

No

Santa Clara, CA, USA

MPL

Sleepycat License

SCL

1

Not recommended.

Yes

None

AFL

Sun Industry Standard License

SISSL

3

Not recommended.

No

CA, USA

-

Sun Public License

SPL

3

Not recommended.

No

CA, USA

MPL

Sybase Open Watcom License

SOWPL

2

Not recommended.

Unknown

None

-

University of Illinois/NCSA Open Source License

NCSAOSL

1

Obsolete.

Yes

AFL

Vovida Open Source License

VOSL

1

Obsolete.

Yes

None

AFL

W3C Software Notice And License

W3CL

1

Not recommended.

Yes

None

AFL

wxWindows License

WXWL

1

Not recommended

Yes

None

-

X.Net License

XNL

1

Obsolete.

Yes

CA, USA

AFL

zlib/png License

ZLIBL

1

Not recommended.

Yes

None

AFL

Zope Public License

ZPL

2

Not recommended.

Yes

None

AFL

Definition of terms

We will use some terms of art in describing these
licenses:

Glossary

academic license

A style of license that typically contains nothing more than
a warranty disclaimer and a grant of rights to
redistribute/use/modify limited only by the requirement that the
license itself (and associated copyright notices) be retained in modified
versions.

corporate license

Corporate licenses differ from academic licenses in that
they tend to include elaborate protections for the granting party on issues
like patents, warranty, indemnity, and choice of law. They usually contain
proper names, and give asymmetrical privileges to a named party.

copyleft

A copyleft license requires that it be propagated
to all derived works of the covered code.

contains proper names

This is a class of bug found especially in corporate
licenses. The license has the name of a particular institution, product, or
individual embedded in it in such a way that the license cannot be used
by others without modifications that make it legally questionable
whether the modified version is the same license.

Requires delta notices.

Requires sourcefiles modified from the original covered code
to carry prominent notice of modification.

Requires preservation of attributions.

Explicitly requires that the individual or corporate
credits to the author(s) of the baseline code be preserved in derived
works, in addition to the copyright notices.

Requires an identifying splash screen.

Requires that the software, if interactive, display a
splash screen identifying the authors of the baseline code and/or
the license under which it is issued.

Requires exhibit A.

Requires that the license be incorporated by reference
in each module of covered code using a specified form (usually appended
to the license text as an `Exhibit A').

Contains an explicit patent grant.

License conveys a royalty-free grant to use all of
grantor's patented techniques that are essential to the software's
function.

Contains patent mutual-termination clause.

Rights granted under the license terminate if
grantor brings action for infringement of patents essential to the
use of OSI-certified open-source software containing a mutual-termination
clause.

well-crafted

Used to describe a license that has received careful
review by lawyers and professional wordsmiths, and is therefore more
likely to hold up under court test. Some licenses, including (alas)
some rather popular ones, can only be described as `poorly
crafted'. Newer licenses tend to be better crafted than older ones
as the community has learned from experience.

first-generation

One of the pioneering open-source licenses. These
tend to be poorly crafted by modern standards (many were, for example,
written before software patents were understood to be a serious issue)
but often have large constituencies for historical
reasons. Usually originated pre-1990.

second-generation

One of the open-source licenses that was explicitly
crafted to address the inadequacies of a first-generation prototype
(usually the prototype was an academic license). Most of these were
composed in the experimental period between the Mozilla source-code
release in 1998 and the dot-com collapse in 2001.

third-generation

Third-generation licenses are based on experience with
the second generation, and incorporate explicit features to deal with
current issues like the submarine-patent problem and (in some cases)
mutual defense.

Detailed comparison of licenses

Academic Free License

The
Academic Free License (AFL) is the license designed by the legal
counsel of OSI in 2002 based on historical experience with the class of
"non-copyleft" licenses including BSD and
MIT, and ASL. These have traditionally been known after
their MIT and BSD prototypes as academic licenses.

Special features:

No-endorsement clause. Users of the software are barred
from using the name of the organization or contributors to endorse or
promote products.

Contains explicit patent grant.

The OSI recommends the AFL as a best-practice replacement for the
entire class of academic licenses. It is a well-crafted third-generation
license covering issues and vulnerabilities with respect to patents,
liability, and warranty of copyright ownership that the older ones cover
incompletely or not at all.

Apache Software License

The Apache Software
License (ASL) is an early second-generation license that was written
to address problems with the first-generation BSD and MIT
licenses. It is used by Apache and a small scattering of other
projects.

Functionally, ASL is a non-copyleft license in the academic
style. It is relatively well crafted, but OSI considers it
obsolete and recommends the AFL instead.
Additionally, ASL contains proper names.

Apple Public Source License

The Apple
Public Source License (APSL) is a second-generation semi-copyleft
corporate license used by Apple for various open-source portions of Mac
OS/X and other Apple projects.

Special features:

Requires delta notices.

A requirement to retain and reproduce all Apple copyright notices
in derivative works that appeared in Apple's original code.

Requires Exhibit A.

Contains explicit patent grant.

A rights-termination clause that triggers if you sue Apple over any
patent, whether or not it is on the covered code.

The APSL has been controversial since it was introduced in 1999.
Various factions in the community object to some of these special
features, especially the rights-termination clause. The 1.0 versions
contained a requirement that all changes to `deployed' code be
reported to Apple that produced huge flamewars.

The APSL is not GPL-compatible. It and the original Artistic License
are the only licenses certified by OSI that are not also considered "free" by
the Free Software Foundation. This evaluation, however, was based on the
1.0 version of the license including the now-discarded disclosure
requirement.

The OSI does not recommend use of this license for new projects.
Among other problems, APSL contains proper names.

Artistic License

The
Artistic License (ARTL) is, unfortunately, not a single license.
It occurs in at least two variant forms, both normally attached to Perl
distributions. In style they are first-generation academic licenses.

All variants are notoriously poorly crafted, with the possible meaning
changing radically depending on the interpretation of terms in the license
that are nowhere defined. Interestingly, the ambiguity was deliberate; the
author is a linguist who believed his purposes were better served by
artistic vagueness.

The Artistic License is not GPL-copmpatible. FSF holds that it is
too ambiguous to be a proper copyleft license.

The OSI does not recommend use of this license for new projects.
Consider using AFL instead.

Attribution Assurance License

The Attribution
Assurance License (AAL) is a second-generation license
template generalized from a one-off license used on a particular
software project. It resembles the BSD license.

Special features:

Requires preservation of attributions.

Requires an identifying splash screen.

Instances are required to be GPG-signed so their integrity can be verified.

This is a license for authors who want to make certain their
names are not separated from their code. Under most circumstances
this goal is effectively met by the open-source community's social
norms (enforced by flaming and shunning). If these means seem
sufficient, consider the AFL instead. The
use of GPG to authenticate the license is technically
interesting.

BSD License

The
BSD
license is one of the first-generation academic-style licenses. It is still
very widely used, especially in connection with the BSD family of
open-source operating systems. Pre-1999 versions (`old BSD' or `BSD Classic')
contained an advertising clause which was officially rescinded by
Berkeley, leading to a modern version (`new BSD') equivalent to the
MIT license except for the no-endorsement
clause.

Special features:

No-endorsement clause. Users of the software are barred from using
the name of the organization or contributors to endorse or promote
products.

This license is obsolete. Many variants contain proper names. It
was pioneering in its day and remains a cultural icon, but is poorly
crafted for modern conditions. The OSI recommends AFL instead; see the comentary attached to AFL for a
discussion of BSD's weaknesses.

Common Public License

The Common
Public License (CPL) is a second-generation semi-copyleft corporate
license with an explicit grant of patents and some disclaimer requirements
on commercial distribution. It is primarily used by IBM's developerWorks.
It is fairly well crafted, but OSI recommends use of the AFL instead (it's simpler).

Eiffel Forum License

The Eiffel
Forum License (EFL) looks like a minor second-generation
academic-style license. One clause looks like the license is intended to
be copyleft in a GOPL-like way, but neglects to stipulate that derived
works must themselves be distributed under EFL. It is associated with
Bertrand Meyer's reference implementation of Eiffel developerWorks. It is
poorly-crafted, vague, and contains proper names; OSI recommends use of the
AFL instead.

GNU General Public License

The GNU
General Public License (GPL) is a first-generation copyleft
license. Over half of all open-source projects use it, and for some
developers it approaches the status of a cult object. Others
(especially in the BSD camp) oppose it with equal fervor.

The GPL has some problems as a legal document. Though it is
better crafted than any of the other first-generation licenses, many
IP lawyers doubt that it is legally enforceable (the copyright-law
jiujitsu it uses to avoid being a contract is said to be
questionable). This may not matter; the GPL has such a huge following
that potential violators must genuinely fear the avalanche of bad
publicity they would reap, and the GPL's keepers at the Free Software
Foundation have been remarkably successful at enforcement by
jawboning.

Some of the practice around GPL is conditioned by the Free
Software Foundation's interpretation of technically ambiguous terms
in the document. In particular, the kinds of object-code linkage that
make any resulting binary a derived work of a part of it that is GPLed
are not defined in the GPL itself. It is generally agreed that static
linkage is derivation, but the FSF's position that dynamic linking is
also derivation is controversial.

Despite these problems, OSI recommends the GPL as a best-practice
license for those who wish a full copyleft license.

Special features:

Copyleft.

Requires an identifying splash screen.

Requires delta notices.

GNU Lesser General Public License

The GNU Lesser
General Public License (GPL) is a GPL variant intended for use with
libraries, and less is less strongly copyleft. It allows object-code
linking to LGPLed code without the entire binary becoming a derived work
under GPL terms. This license is often used for function libraries.

Special features:

Copyleft.

Requires delta notices.

OSI does not recommend the LGPL. The Free Software Foundation has
itself deprecated this license in favor of GPL or GPL with an explicit
exception clause (such as the Guile license). Also, OSI believes that the
degree of uncertainty about what kinds of linkage to libraries creates a
derivative work has undersirable effects, and recommends only non-copyleft
licenses as best practuce for libraries.

IBM Public License

The IBM
Public License (IBMPL) is a second-generation semi-copyleft
corporate license with patent grant provisions, similar to and derived from
the the CPL. It is designed for use by IBM
open-source projects. OSI does not recommend its use for new projects.
Among other problems, IBMPL contains proper names.

Intel Open Source Public License

The
Intel Open Source License (IOSL) is a BSD variant with an
export clause. OSI does not recommend its use for new
projects. Among other problems, IOSL contains proper names.

Jabber Open Source License

Quasi-copyleft. Derived works must be distributed under an
OSD-conformant license, but not necessary JOSL itself.

Requires Exhibit A.

OSI does not recommend the JOSL for new projects.
Among other problems, JOSL contains proper names.

MIT License

The
MIT
license is one of the first-generation academic-style licenses. It is still
very widely used, especially in connection with the the code for the
X window system.

This license is obsolete. It is poorly crafted for modern
conditions. The OSI recommends AFL
instead; see the commentary attached to AFL for a discussion of the
the MIT licence's weaknesses.

MITRE Collaborative Virtual Workspace License

The
MITRE
Collaborative Virtual Workspace License (CVW) is an
interesting experiment. It has almost no language of its own beyond
some low-level boilerplate about trademarks and govenment contracting
regulations; essentially, what it does is offer a choice of either
GPL or MPL
terms.

The implementation of this license makes it too specific to MITRE to
be useful for other projects (and it contains proper names), but the concept of
a thin envelope around a dual-licensing scheme is interesting.

Motosoto License

The
Motosoto Open Source License (MOSL) is a variant of JOSL (see for special features) tuned to operate
under Dutch copyright law. Not recommended for use in new projects; among
other problems, MOSL contains proper names.

Mozilla Public License

The Mozilla Public
License (MPL) is the license under which the Mozilla source code is
distributed. It was among the first of the second-generation corporate
licenses, and is still widely regarded as a model — in fact, it is the
only corporate license that has achieved a level of name recognition and
community approval comparable to the major first-generation
licenses.

MPL evolved substantially between 1.0 and 1.1. The patent-grant
provisions grew more explicit; also, the Exhibit A of 1.1 includes
language allowing the code to be dual-licensed.

Special features:

Semi-copyleft.

Contains explicit patent grant.

Requires delta notices.

Requires Exhibit A.

Includes user option for code to be redistributed under another license
specified by licensor.

OSI recommends MPL as a best-practice corporate-style license.

MPL 1.1 is potentially compatible with the GPL through its dual-licensing
provision, if GPL is cited as the alternate license. MPL 1.0 was not.

Nethack General Public License

NOKIA Open Source License

The The Nokia Open
Source License (NOKOS) is an early third-generation license, a
variant of JOSL (see that license for
special features). The OSI recommends against using it for new
projects; among other problems, NOKOS contains proper names.

Open Group Test Suite License

The Open
Group Test Suite License is a special-purpose license designed
by the Open Group (maintainers of major standards describing Unix) to cover
their conformance test suite. It is not really comparable to any of the
other licenses listed here.

Open Software License

OSI recommends the OSL as a best-practice license for those who wish
a full copyleft license. The OSL was designed to be useful for
documentation as well as code.

Special features:

Copyleft.

Has explicit patent grant.

Contains patent mutual-termination clause.

Python License (old CNRI version)

The
CNRI Python License (CNRIPL) is an academic-style license with a
clickthrough requirement. It formerly covered the implementation of the
Python language. It is obsolete (replaced by PSFL) and contains proper names. The OSI recommends
against its use with new projects.

Python Software Foundation License

The Python
Software Foundation License (PSFL) is a complex academic-style
license, actually a sort of historical pileup of three layers of academic
licenses. It covers the implementation of the Python language. It
contains proper names. The OSI recommends against its use with new
projects.

Q Public License

The Q Public
License (QPL) is associated with the Qt library. It contains
proper names. The OSI recommends against its use with new projects.

Ricoh Public Source License

The The
Ricoh Public Source License (RPSL) is an early third-generation
semi-copyleft license, a variant of JOSL (see
that license for special features). The OSI recommends against using it
for new projects; among other problems, RPSL contains proper names.

The Sleepycat License

The The
Sleepycat License (SCL) is a variant of BSD used for Sleepycat's open-source database
products. The OSI recommends against using it for new projects; among other
problems, it contains proper names.

Quasi-copyleft. Derived works must be distributed under an
OSD-conformant license, but not necessary JOSL itself.

Requires Exhibit A.

Clause 3.1 constrains the behavior of developers with the respect to a
standard described in an attached Exhibit B. It requires that if your
modifications do not conform to the applicable standard, you must publish
eunder open-source terms either (i) a description of the deviations and a
reference implementation of them, or (ii) your modifications in source
code.

The OSI recommends against using SISSL for new projects; among other
problems, it contains proper names.

Sun Public License

The The
Sun Public License (SPL) is another variant of MPL (see for special features). Not recommended for
use in new projects; among other problems, SPL contains proper
names.

Vovida Open Source License

The OSI does not recommend the use of this license for new
projects. Consider using AFL instead.

W3C Software Notice And License

The
W3C Software Notice And License (W3CL) is an academic-style
license used by the consortium that maintains interoperability
standards for the World Wide Web.

W3CL has several of the problems of first-generation academic
licenses such as BSD, including reliance on an implicit patent grant.
Theerefore the OSI does not recommend the use of this license for new
projects. Consider using AFL instead.

X.Net License

The
X.Net License (XNL) is a trivial variant of the
MIT license that adds a California choice-of-law
provision.

XNL inherits the problems of first-generation academic
licenses, including reliance on an implicit patent grant.
Therefore the OSI does not recommend the use of this license for new
projects. Consider using AFL instead.

zlib/png License

ZLIBL inherits the problems of first-generation academic licenses,
including reliance on an implicit patent grant. It also contains proper
names. Therefore the OSI does not recommend the use of this license for
new projects. Consider using AFL instead.

Zope Public License

The
Zope Public License (ZPL) is a simple academic-style license
resembling BSD, with a disclaimer of grant
of trademark privileges,

ZPL inherits the problems of first-generation academic licenses,
including reliance on an implicit patent grant. It also contains proper
names. Therefore the OSI does not recommend the use of this license for
new projects. Consider using AFL instead.