Door 1, 2, or 3

Three open source licenses is more than enough.
Another day, another open source license. Or at least that’s how it seems.
There’s the venerable GPL and the less restrictive LGPL; the MIT, BSD, Mozilla, and Apache licenses; the variants that vendors such as Trolltech (the QPL), Sleepycat (the SL) and Sun (the CDDL, SISSL, SPL) use; and as if that list wasn’t enough, there’s roughly fifty more open source licenses on the Open Source Initiative’s (OSI) list of OSI “approved” licenses (see http://www.opensource.org/licenses/). It’s like alphabet soup, and the sheer number of licenses makes counseling (the leather sofa kind) and counsel (the leather wingtip kind) seem like bargains.
Of course, this rather long list of licenses (and I’m sure my list is far from complete) didn’t spring into existence overnight. Much like source code, open source licenses — and the underlying philosophies and legal theories behind them — evolve. Over time, licenses face legal challenges and are revised to clarify and refine the intent of the licensor, and it’s unrealistic to expect one license to fit all: Sun’s interests are not IBM’s interests are not Richard Stallman’s interests. And developers, take comfort: lawyers succumb to Not Invented Here disease, too.
It’s easy to have perfect hindsight: perhaps a different precedent should have been set way back when. A statement on the OSI web site (which I’ll paraphrase for brevity) concurs:
“[To build as many]bridges as possible between developers and the corporate world… we accepted a 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… OSI has become as a victim of its own earlier success.”
Since we cannot reform the past — nor would we want to, as the success of open source can be directly attributed to many of the licenses that OSI still promotes — a new precedent is needed the future. Or precedents, but no more than three canonical licenses: one without any encumberances; one that’s reciprocal; and one that promotes sharing, but is otherwise stewarded.
The first license — no encumberances (except to give credit where credit is due) — would be similar to the BSD license. It’s the Gonzo” Here’s the code, go crazy” license. A project could choose this kind of license to allow others complete freedom.
The second license, where a developer can use the code freely, but must reciprocally provide the code if he or she improves it, would be similar to the GPL — well, it’d be the GPL, probably V2. The GPL allows developers to stand on the shoulders of others provided others can climb atop your shoulders, too.
The third license is probably the most restrictive of the three: you can use and modify the source code for your own purposes, and even share your improvements, but you cannot distribute variants based on that code. The intent of this license is to further a standard implementation, probably under the direction of a governing body. End-users can create customizations and share them, which promotes adoption; end-users can also lobby the governing body to incorporate modifications into the standard. In a sense, this license is a formalization of the Linux kernel development process, and it seems suitable for software such as Java, Solaris, Qt, even Windows.
OSI is mumbling about efforts to reduce its expansive menu of licenses down to three. Perhaps the cases shown above are the most common and all other scenarios should be recast into one of those molds.
CA proposes a “Template License” that works like a AAA Triptik: arrange the previously constructed pieces into a license and go.I doubt that such a document could be realized, and even if it were, the end-result of death by a thousand variables be no better than the plethora of permutations developers must struggle with now.
Whatever the solution, it must be simple. Simple to choose, simple to understand.
Let’s make a deal so open source can continue to succeed: Pick Door Number One, Door Number Two, or Door Number Three.
Everyone goes home a winner.

Martin Streicher is the Editor-in-Chief of Linux Magazine.

Comments are closed.