Welcome

Dear Reader,

Name an open source license. Most readers of this magazine would think of the GNU Public License (GPL), but other licenses also occupy a portion of community attention. For instance, most seasoned Linux users are aware of the BSD license and the Apache License, as well as the Mozilla Public License and the Lesser GPL. Each license serves a slightly different need, so each license is slightly different.

A menu of different open source licenses is actually healthy, because it gives users flexibility in choosing a license based on the project's priorities and needs. But seriously, how big does this menu really need to be? The Open Source Initiative (OSI) lists 103 licenses that meet the Open Source Definition [1]. 17 of the licenses on the list are marked as retired or superseded, but that still leaves 86 active licenses that all qualify as open source. As you can probably guess, most of these licenses are hardly ever used, but they still meet the definition, so they found their way onto the list.

Open source scions have been concerned for some time about the dangers of license proliferation. Too many licenses adds confusion and detracts from the clarity and unity of purpose that is so fundamental to the spirit of open source. It also makes it more difficult for an average user to understand the rules for using a software product. Linux users mostly know what the GPLv2 is, and when they read that an application is licensed under the GPLv2, they know what that means. They don't necessarily know what the Sybase Open Watcom Public License 1.0 is and why it is different, so a user who is conscientious about learning the rules that apply to the software needs to spend more time pouring over the legal fine print. Ultimately, if too many unfamiliar licenses are in circulation, using an open source product would lead to the same kind of "OK…whatever" absent acquiescence that is so common in the closed-source world, with users agreeing to EULAs they haven't even read.

The Open Source Initiative has its eye on the problem of license proliferation, and they are taking steps to address it. First of all, they publish a list of licenses they call "popular and widely-used or with strong communities" and encourage developers to use one of these licenses as a first option (see the box entitled "OSI's A List"). To encourage reuse, they insist that all OSI-approved licenses are clearly written and don't include language that limits the use to a single project or industry. In spite of these efforts, the number of OSI-approved licenses has roughly doubled from the approved list of 50 that existed in 2004.

Is all this heading the way they want it to go? Not so much. OSI announced this month that they will convene a License Listing working group to study the licensing process and make recommendations about any changes that would lead to a better and more orderly outcome. According to the OSI website, "The mission of the License List working group is to find ways to ensure that the OSI's license list is appropriately comprehensive while also continuing to encourage the use of a smaller set of well-known, well-understood licenses" [2]. The group will look at the criteria for approving licenses and will even consider whether there is a need for another process to de-certify a license that is no longer needed or is too similar to another.

Interestingly, OSI also raises the question of whether a preoccupation with license proliferation has led to some worthy licenses not making the list. One of the topics the group will study is whether "…a desire to discourage license proliferation may have prevented some suitable licenses from obtaining OSI approval."

OSI says the License List working group will not consider changes to the official Open Source Definition, but everything else about the approval process is on the table. Open source software has way more stature and visibility than it did back in 1998 when the OSI was founded. Open source licensing is actively desired by many projects, which should strengthen the hand of the OSI when cleaning up the license list and defining a more practical approach. With any luck, the end result should be a more sensible process and a comprehensive list of core licenses that will leave fewer reasons for future proliferation.