Have you ever had to comply with the chicken dance license? For me, the WTFPL is a better option any day:
How many of those are out there? Is it possible that somewhere deep in one of your projects lies a license that requests you treat the coder to a beer? Can I create a binding open source license that sets me up for a life of free nachos and margaritas?
Back in the early days, the OSI encouraged organizations and developers to create open source licenses to suit their needs, hoping this would enable more open source development and adoption and help the community grow. At the time, there were only a handful of open source licenses: GNU, BSD, MIT, Mozilla, and a few others.
As open source adoption grew, so did the number of licenses: hundreds of open source licenses were created – from corporations that adopted open source code while their lawyers made sure they kept as much control over it as they could, stay safe from litigation and boast an open source badge – to developers like the creators of beer-ware, that wanted to make a point, or just keep it weird. As the open source license pool got bigger, only 80 were OSI-approved and only 20 of them were OSI-recommended.
Confused? So was everyone else: the growing list of licenses created an exponentially larger list of compatibility issues, which in turn created more billable hours for lawyers, more headaches for developers and risked making open source seem like quite an effort for corporate executives looking at the bottom line.
The initial need to make open source an accessible resource for free market dynamics became damaging to the open source community. Something needed to be done.
The OSI License Proliferation Project came together to define criteria and enforcement, in an attempt to reduce license proliferation, protect the open source community and help nurture its growth.
The project’s 2006 license proliferation report listed three critical problems that arose when enabling free market dynamics to engage in open source licensing:
1. Individuals and smaller companies complained that there are too many open source licenses: it’s too hard to choose which one to work with, the number should be reduced.
Larger companies typically added that:
2. Some of the licenses in the list are incompatible with each other.
3. The variety of so many individual licenses makes it hard to understand what exactly is covered in a multi-license distribution.
While the OSI understood, and were sympathetic to the challenges facing organizations, they held firm in the that they cannot and will not dictate which license should or should not be used, or how to combine them.
The OSI’s solution was to divide their existing list of approved licenses into 5 groups:
1. Licenses that are popular and widely used or with strong communities
2. Special purpose licenses
3. Licenses that are redundant with more popular licenses
4. Non-reusable licenses
5. Other/Miscellaneous licenses
The first two groups, composed of licenses that the OSI determined were to be clearly written, simple, and understandable, reusable and not duplicative – were recommended for use. This narrowed down the OSI-approved list to a group of manageable 12-15 open source licenses.
Did this really help the open source community? Some open source advocates argued that while a list of 12-15 recommended open source licenses may help corporations and the lawyers that they are paying, it wasn’t any help to the open source community – it was actually reducing options for developers.
Granted, they said, there were hundreds of licenses when the OSI launched the proliferation project – but who said that was a bad thing? Most developers, then and now, stick to the same 20 open source licenses: clearly, they aren’t confused by the variety and the restrictions might narrow their options. If they want or need to use something out of the box, why should their options be reduced to make corporate lawyers more comfortable? Especially considering that to this day, one of the original issues of open source licensing persist: look at how little of the shared repositories on GitHub are missing any type of license.
While the OSI solution provided the lawyers in large organizations an easier system by which to decide what developers can use or not and how their code can interact, the recommendation to stick to a handful of licenses reduces the variety of open source components for developers and therefore reduces our ability to enjoy the community work.
Another sticky issue is that the list of 80 approved open source licenses remains, and can still be used. Some of those licenses were incorporated into projects but are not under the recommended category: this means that corporations are likely to avoid them, and they can create quite an issue for developers without corporate legal counsel.
Looking at the situation today, the OSI’s license proliferation project did not solve problems for the open source community. The project helped corporate lawyers stake their claim in the bazaar, while developers were requested to play by their rules.