License Proliferation

Executive Summary

• OSI's strategy for its first seven years has been successful at making open source a magnet for innovation in business and government.

• As a result, the main challenges open source faces today are the problems of success, not of failure.

• License proliferation has become a significant barrier to open-source deployment.

• But, contrary to some recent representations, the sky is not falling on us. The license proliferation problem is manageable with good policy.

• OSI is responding by instituting stricter criteria for license approvals.

• From now on, approved licenses must meet three new criteria of being (a) non-duplicative, (b) clear and understandable, and (c) reusable.

• We will be moving to a three-tier system in which licenses are classified as Preferred, Approved, and Deprecated.

• The class of asymmetrical corporate licenses that began with Mozilla was a worthy experiment that has failed. The new policy will discourage them.

• OSI has designed a public-comment process to include community stakeholders in grading licenses.

• A goal of the new policy will be to promote unrestricted reusability of code.

The Background

Seven years ago, in 1998, OSI began evaluating licenses for compliance with the Open Source Definition. Our goals in doing this were: (1) to articulate the social contract that knits together open source software developers, (2) to create a nexus of trust between developers and the corporate and government world that would facilitate more cooperation, and (3) to knit the hackers and the suits together into a larger and stronger open-source community.

At that time, when OSI was still struggling to build its credibility and neutrality to both groups, the best policy seemed to be a completely non-directive one. Build as many bridges across the divide as possible -- approve as many OSD-compliant licenses as presented themselves -- and trust that time would sort out which bridges attracted traffic and sightseers.

In fact, the community did reveal rather definite preferences in its behavior. While there are more than fifty OSI-approved licenses only a handful of those are actually in wide use; in fact, just two licenses (GPL and BSD) cover over 70% of all projects.

This policy of complete laissez-faire accomplished several useful goals. OSI built credibility among all its stakeholders. It encouraged a period of license experimentation in which people tried out a lot of different bridge designs. Both the hackers and the suits became much more aware about the kinds of issues that licensing raises, not only within their own end of the community but at the other end as well.

Meeting those goals furthered the mission. Open-source software has become the lynchpin of many a Fortune 500 corporate strategy to a degree that would have been unimaginable a decade ago; the suits now understand that they can make a contract with the hackers and have it honored. Governments around the world have also responded to the open-source message with procurement initiatives and funding. Thousands of hackers get supported to do what they care most about, without having had to give up the values and ideals that drew them to the community in the first place. Both groups have been well served by the exchange. Our entire economy and the society around it has benefitted as well, as the new and larger open-source community gave software consumers and technology users everywhere a whole new range of choices.

Yesterday's Problems

There are three major economic and structural problems around software. One is development -- how to produce high-quality, innovative, and reliable software. The second is distribution -- how you reduce the friction cost of getting software from where it's developed to where it needs to be used. The third is deployment -- how you manage the technical and legal complexity of software in use.

The original Open Source Definition, and the laissez-faire licensing policy that OSI adopted, proved very successful at fostering a new and dramatically effective approach to the development problem: tear down the walls around software projects, let the light of process transparency and the power of distributed peer review work for you.

In 1998, the theory that open-source developers would as a matter of course out-code and out-innovate proprietary competition seemed radical, even shocking. Today, we can very nearly take that insight for granted. OSI is proud of its role in developing that understanding, and we will continue to take that message wherever it is needed. But the difficult phase for that kind of evangelism is already over, with opponents of open source in an increasingly defensive and losing position.

By insisting on licenses that support the right to free distribution without mandatory fees or vendor lock-ins, we also addressed the distribution problem. Open-source licensing and the explosive growth of the Internet combined into a mutually-reinforcing attack on software distribution costs. Today, technology for incremental on-the-fly update of open-source software is approaching the point at which distribution will be a solved problem. The trends that will take us the rest of the way there are past the tipping point and self-reinforcing.

The problem the Open Source Definition did not specifically address was deployment. Because we tackled the other problems so effectively, deployment issues that would have seemed marginal in 1998 are now perceived as large challenges. At the center of many of those issues is the proliferation of open-source licenses.

Today's Problem

OSI's approach on the development and distribution problems involved building as many different bridges as possible between developers and the corporate world. In doing this, we accepted a proliferation of new licenses. This is a problem in that although physical bridges between communities don't interfere with each other, licenses do. Interference between different open-source licenses is now perceived as a sufficiently serious problem that OSI has become as a victim of its own earlier success.

This interference affects all the aspects of software: development, distribution, and deployment.

The central activity of the open-source community is to create, re-use, and re-combine source code. Our development practice is built on recombination; we write modules, service libraries, plugins, and programs to be combined into larger aggregates -- larger programs, CD-ROM anthologies, entire operating-system distributions.

One of the results of recombination is that code written under different licenses gets mixed together -- combined in new source code, linked in the same runtime, called from the same script, included on the same media. Combination can leave software developers, users, and distributors uncertain what their rights and responsibilities are. That uncertainty has a chilling effect; even the perception of legal risk forecloses a lot of activity that would otherwise be productive.

Even pre-OSI, managing the interactions between GPL and everything else was already a significant headache. As the number of OSI-approved licenses goes up, we get a combinatorial explosion in the number of possible license collisions. This is a potentially serious problem at all three levels; people worry that they have to consult lawyers before moving, the friction costs of using open source go up, and everyone is injured.

The fact that the overwhelming majority of projects use one of just a few "classic" licenses does not prevent this problem. Just one odd license in a critical service library or component can create an unboundedly large amount of confusion; thus, the rarely-used licenses have negative effects out of all proportion to the amount of code they cover.

OSI has long been aware that license proliferation is a problem. The steps that we have already taken have not headed off enough licenses. But we exist to serve our community, and our community -- from both the hacker and suit sides -- has been telling us loud and clear that it wants this problem solved.

The problem can indeed be solved. It will take a huge amount of work and trust, but OSI is up to that task. The technical difficulties are surmountable; the real problems in stemming the tide of license proliferation will be political. They stem from two related though distinct phenomena; the license as tribal flag, and the license as corporate monument.

Hackers have a long history of using licenses as tribal flags. Anyone who has followed the GNU-vs.-BSD dispute, or any one of a dozen others, knows that these licenses have emotive and symbolic significance beyond their instrumental function as legal documents. There is some tradition of large projects writing their own new licenses as an assertion of identity. There is more tradition of license disputes becoming proxies in ideological wars. Hackers can get intensely, even pointlessly, territorial about their licenses.

In the land of suits, the parallel is the license as corporate monument or vanity project. Corporate lawyers find it easy to to conclude that all the existing ones are flawed, and that what their employer really needs is a brand-new license full of ruffles and flourishes that convince everyone that serious work has been done here. For their employers, publishing a new license is also a demonstrative act, providing many opportunities forpublic relations maneuvers aimed both at the developer community and outside it. And, of course, no corporation will ever use any other corporate license. Thus, suits can get intensely, even pointlessly, territorial about their licenses.

The hard truth is this: in order to address the problem of license proliferation effectively, both sides will have to give up their vanity projects. The day of the open-source license as tribal flag or corporate monument will have to come to a close. OSI will need the support and forbearance of all quarters of the community to make this happen.

Towards a Solution

OSI is taking action, beginning today, to address this problem.

Our first step, effective immediately, is a procedural change in the criteria we use to approve licenses. Going forward, we will be auditing license submissions not just with regard to the Open Source Definition but with regard to three new criteria:

1. The license must not be duplicative. That is, it is up to the submitter to demonstrate that the license solves a problem not sufficiently addressed by an existing approved license. Approval may be denied to any submitted license, even a technically OSD- conformant license, if OSI deems it duplicative.

2. The license must be clearly written, simple, and understandable. Open-source licenses are written to serve people who are not attorneys, and they need to be comprehensible by people who are not attorneys. OSI may deny approval to licenses which, though technically correct and OSD-compliant, are so obscure and complicated that an intelligent layperson cannot be assured of knowing his or her rights and liabilities after reading them. The burden of engineering this clarity falls on the submitter.

3. The license must be reusable. If the license contains proper names of individuals, associations, or projects, these must be incorporated by reference from an attachment that declares the names of the issuer and any other cited parties, and which can be modified without changing the terms of the license. As the sole exeption, the license may name its owner and steward.

Our aim in applying these criteria will be to approve only the new licenses that, in OSI's informed judgment, solve a problem or combination of problems not effectively addressed before. OSD conformance, by itself, will be necessary but no longer sufficient.

To complement these new filtering criteria, we will be instituting a multi-tier classification of licenses. We will begin sorting licenses into three categories: "Ordinary", "Preferred", and "Deprecated". The goal will be to define a small enough set of Preferred licenses to make the interactions among them manageable.

We are defining a process for sorting licenses. We will conduct a series of public discussions on specific issues in the construction of licenses. These issues will include but not be limited to:

• Drafting quality of license language
• Jurisdiction and choice-of-law issues
• Hardcoded trademark and brand references
• Patent-defense clauses
• Symmetry of rights among parties
• Termination clauses and their triggers
• Ownership and stewardship

For each identified issue, OSI will develop a policy about what kinds of provisions are desirable, and how to grade licenses on that basis. The policy discussion will involve as wide a range of stakeholders as choose to contribute.

We expect that as individual policy issues are sorted, the grades they imply for each of the existing corpus of approved licenses will clearly separate the best from the worst, and both extremes from a broad middle of the pack. When OSI observes that the grading process is converging on a stable three tiers, we will announce the results by reclassifying them to Preferred or Deprecated, as appropriate.

We will have another, overarching criterion in mind: promoting the reusability of code, and discouraging licenses which, while strictly OSD-conformant, nevertheless tend to create semi-gated communities attached to a single firm or vendor. In the past, OSI has resisted such licenses less than we might have. We believed that it was better to invite corporate players into the sunshine and let them see the benefits of giving up proprietary control gradually than to present them with a demand that they give up all control immediately and scare them into a defensive crouch.

That strategy worked well in 1998, as a way of giving people a place that felt safe within which to rethink their assumptions. But seven years later, we think it is is significant that the original corporate open-source license, the Mozilla Public License, has been dropped by its originating organization in favor of the GPL. It is becoming increasingly clear from this and other examples that the "middle way" represented by Mozilla and other corporate open-source licenses is not a stable, effective solution even from the point of view of selfish corporate agents.

These licenses put a hard brake on the growth of development communities around their products without actually delivering measurable advantages in revenue, market control, or risk management. Because these licenses have largely failed to deliver, the same corporate players that originally promoted them are now among those voicing the loudest complaints about the proliferation of licenses and the legal complexity created by license collisions.

Therefore, we believe that the best way for us to serve the corporations and the entire open-source community is to go back to first principles and insist on reusability without qualifications and a general flattening of legal barriers.

When we publish the classification of existing licences, we will encourage repository sites such as SourceForge and Berlios that use OSI approval as a filter to tighten their criteria for acceptable licenses on new projects. We will encourage the increasing number of local, state, and national governments that rely on OSD approval to do likewise.

We do not expect the Preferred category to hold any real surprises. Because the vast majority of the more than sixty thousand open-source projects fall under a very few well-established licenses such as GPL, BSD, and MIT, it is unlikely that a more than a few hundred projects would actually be inconvenienced even if we were to deprecate a score of other licenses.

Nevertheless, in applying the new criteria and applying multi-tier approval, we expect to annoy and even anger some people. That is the inevitable price of having a more normative policy, but it is a necessary price if we are to address the proliferation problem with any seriousness at all. We trust that those who have been most insistent in their demands that we address proliferation will also be the most supportive of the new policy.

OSI, as an independent and widely trusted standards body, is positioned as no other organization can be to lead the community towards licensing practices that will promote its future health and growth. But we will invite the participation of other stakeholders such as OSDL and FSF and key leaders of major projects in developing our anti-proliferation policy. The mailing lists and fora on which the discussions take place will be open to all. We exist to serve the entire community, and hope for the widest possible representation from it.