|Revision 0.8 DRAFT||2002-11-09||esr|
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.
Table of Contents
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.
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.
How should I choose a license for my project?
Can an open-source license be enforced against people trying to close up the code?
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.
If open-source licenses can't be used to keep people from closing up code, what good are they?
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.
When I contribute to a project, what rights do I acquire in the project as a whole?
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.
OK, so who can change the license on a project?
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.
You can read our detailed analysis of this question.
What is my risk of getting sued for intellectual-property rights violation over violating an open-source license?
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.
As a project contributor, should I take any special actions to protect my contribution?
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.
As a project leader, should I take any special actions to protect my rights?
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:
This program is open source. For license terms, see the LICENSE file.
Now register your copyright. This page tells you how to do it.
How do I learn more?
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.
U.S. copyright and patent law is founded on Article I, Section 8 of the U.S. Constitution.
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.
More about this in the section on changing licenses.
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.
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.
You can find more information on patent law here,
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.
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.
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).
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.
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.)
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 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 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.
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.
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, registered or unregistered, you choose the license (the terms of distribution) and can change the license at any time.
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.
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.
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.
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.
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.
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.
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.
Here's how to translate the theory above into practice:
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.
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.
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.
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.
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|
We will use some terms of art in describing these licenses:
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 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.
A copyleft license requires that it be propagated to all derived works of the covered code.
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 sourcefiles modified from the original covered code to carry prominent notice of modification.
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 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 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').
License conveys a royalty-free grant to use all of grantor's patented techniques that are essential to the software's function.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
Requires an identifying splash screen.
Requires delta notices.
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.
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.
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.
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.
The Jabber Open Source License (JOSL) is an early third-generation corporate license.
Contains explicit patent grant.
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.
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.
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.
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.
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.
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.
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.
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.
OGTSL is not recommended; it contains proper names.
Contains explicit patent grant from licensor. Implicit IPR grant is denied.
Requires delta notices.
Requires Exhibit A.
OSI does not recommend this licrnse for new projects.
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.
Has explicit patent grant.
Contains patent mutual-termination clause.
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.
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.
The Q Public License (QPL) is associated with the Qt library. It contains proper names. The OSI recommends against its use with new projects.
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 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.
Contains explicit patent grant.
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.
Contains explicit patent grant.
Requires delta notices.
Requires Exhibit A.
Implicit grant of IPR rights from APSL was deleted.
Requests a click-wrap confirmation, if feasible.
The OSI recommends against using SYL for new projects; among other problems, it contains proper names.
The OSI does not recommend the use of this license for new projects. Consider using AFL instead.
The OSI does not recommend the use of this license for new projects. Consider using AFL instead.
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.
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.
The wsWindows License (WXWL) is a LGPL variant.
Requires delta notices.
Differs from LGPL in that derived works in binary form may be distributed on the user's own terms.
OSI does not recommend the wxWindows license. Among other problems, it contains proper names. It also shares the potential enforceability problems of the GPL. It's a clever idea, though.
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.
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.