Licensing HOWTO

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; they should not be considered advice of counsel. The standard caveat applies that you should seek advice from a professional attorney if in doubt.

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.

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 infriging 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 (this has not been itested 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 threatend 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 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 parents 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 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 quuotes 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 rmployees 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-trsde-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.

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 use, 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 Initiative 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:

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.

In October 2002, an appellate ruling Specht v. Netscape Communications Corp., 01-7860 narrowed the terms of validity of click-wrap licenses. The court ruled that where the License is scrollable on the second page of an installation wizard but not visible, downloading users are not bound by its terms. So courts are taking the requirement of assent seriously.

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 most 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.

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.

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 joint-work model — 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 copyrights 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.

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.

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

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