OSI's strategy for its first seven years has been successful at
making open source a magnet for innovation in business and
As a result, the main challenges open
source faces today are the problems of success, not of
License proliferation has become a significant barrier to
But, contrary to some recent representations, the sky is not
falling on us. The license proliferation problem is manageable with
OSI is responding by instituting stricter criteria for license
From now on, approved licenses must meet three new criteria of being
(a) non-duplicative, (b) clear and understandable, and (c)
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
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.
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
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
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.
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
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
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
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
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:
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.
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.
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
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
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