Current Articles | RSS Feed
The Open Source Initiative (OSI) currently lists 68 approved open source licenses. Sounds like more than enough to suit any needs? Think again. Jilayne Lovejoy, corporate counsel at OpenLogic, says, "We have more than 1,000 licenses cataloged in OLEX," and "we are constantly adding new licenses or variations on existing licenses that we find in the course of performing audit and scanning services." Are all these licenses necessary? And why are there so many in the first place?
Lovejoy says, "The OSI, as a governing body, provides a starting point and touchstone for open source software license understanding and acceptance for the FOSS community and enterprises alike. It would be ideal to use the FOSS licenses in existence and discourage license proliferation. However, some FOSS licenses can become outdated due to changes in techology or litigation, resulting in a judicial opinion that alters how licenses are interpreted. Thus, while license proliferation is discouraged, it is inevitable that we will see new FOSS licenses develop."
A lot of oddball licenses are what some of us call "corporate vanity licenses," because they were written for a single company's use. Luckily, the OSI started worrying about license proliferation in the mid-'00s and managed to pare down the number of licenses it listed as both approved and in common use. Since then, requests for the OSI to approve news licenses have slowed from a torrent to a trickle. More important than the OSI's nonproliferation efforts, though, may be the fact that open source software has gone from a phenomenon that only a small number of programmers and IT enthusiasts knew about to an everyday part of almost every company's IT infrastructure, which in turn means the issue of licensing has received more attention from organizations that want to "get it right."
Why does the number of open source licenses matter? Compatibility. If your company's code is distributed under The Apple Public Source License 2.0, is it compatible with code distributed under The Ricoh Source Code Public License?
What if you downloaded code distributed under the Ricoh license, which includes this wording: "The contents of this file are subject to the Ricoh Source Code Public License Version 1.0 (the 'License'); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.risource.org/RPL." That URL is dead and gone. So, it seems, is the Ricoh license, although no license completely dies. There are surely some code snippets still out there somewhere that carry the Ricoh Source Code Public License Version 1.0, which means it is possible that someone, somewhere, will need to test its compatibility with, for example, the widely used Apache License.
It turns out that an awful lot of the 1,000+ open source licenses tracked by OLEX are what open source proponent Bruce Perens calls "crayon licenses," "taking a line from an old Monty Python sketch about a dog license with the word 'dog' crossed out and 'cat' written in, in crayon." This happens when developers ask their corporate lawyers to approve the release of some of their software under the well-known GPL 2.0 or MIT licenses, and the lawyers say, "Um, okay, but we need to change this and that in the software license to conform with our corporate policy." So each set of corporate lawyers crosses out a few words here and adds a few words there and calls their minor license revision The BigCorp Super-Duper Open Source License or something equally unwieldy.
And then, more often than not, BigCorp management is astounded by the lack of outside programmers willing to work on their pet projects for free, so the BigCorp open source software projects gradually faded away, often because other projects spring up that carry generic, well-known licenses – and are generally useful, rather than only fitting the needs of a single company.
Once upon a time, several Bluefish developers wanted to keep that project licensed under the GPL but deny its use by the US military and military contractors as a protest against the US invasion of Iraq. Restrictions like this are not compatible with the GPL or any other truly open source license. But over and over, year after year, companies and people have written to the OSI License Review and License Discuss email lists with questions about how they can make their software open source while keeping this group or that group (usually competitors) from using their code. One person I know actually sought approval (back in 2002) for a GPL 2.0 modification that would have kept a single person he didn't like from using his code. This sounds funny today, but in the early days of open source, this sort of thing happened often, and resulted in the promulgation of licenses that the originating people or companies called open source but really weren't.
In 2000 or 2002 a corporate lawyer presented with an open source license may never have seen one before. Today, open source software is so common that – at least according to a recent survey – 73% of all companies now use open source.
Fortunately, says long-time open source advocate John Mark Walker, the situation has become self-policing. "Last I checked there were really five or six that are used often, and the rest form a very long tail. The software market seems to be enforcing that on its own. Almost all new projects use an existing license, and does not create a new one."
Walker notes that activity on the OSI License-Discuss list has died down over the last two to three years "because there are fewer licenses being proffered for approval, because there aren't many new licenses to be considered. And by now, most people have formed pretty solid opinions about existing licenses. But my opinion is that focusing on licenses or licensing kind of misses the broader point. In many cases the license choice matters less than the community processes and dynamics. Should there be fewer than 68 licenses? Probably, but that's not as important to me as teaching organizations how to run their communities better."
Allowed tags: <a> link, <b> bold, <i> italics