The long-delayed and much-awaited Open Source Initiative report on open-source license proliferation has been released, but the current licenses have been placed into three broad categories and have not been ranked beyond that.
The License Proliferation Committee was set up in 2005 in response to the growing concern that license proliferation was harmful to the success of open source.
In fact the OSI, which approves licenses that meet the Open Source Definition, said at the time that “interference between different open-source licenses is now perceived as a sufficiently serious problem.”
The first draft of the committees report, initially expected by the end of 2005, was submitted to the OSI board late in July, said Diane Peters, the general counsel for the Open Source Development Labs and a member of the committee, at an interview at the annual LinuxWorld Conference & Expo in San Francisco on Aug. 16.
The Licensing Proliferation committee was also originally tasked with dividing the licenses into “recommended,” “non-recommended” and “other” tiers.
But as they started to do this, it soon became clear that there was no one open-source license that served everyones needs equally well.
“We struggled with even categorizing the licenses into three categories and came to the realization that the various business models had different needs and there needed to be some flexibility there,” Peters said.
As such, the report categorizes all the currently approved OSI licenses into three categories: those that are popular and widely used or with strong communities; special purpose licenses; and those licenses that are redundant, which includes those that are non-reusable and other miscellaneous licenses.
The decision to switch to more descriptive terminology was made as the committee felt it would be more productive and helpful to potential users of these licenses to describe the characteristics of these and what made them attractive and appropriate for which uses, Peters said.
The full draft report can be found here.
As a result, the committee did not prioritize the various licenses within each of those categories, instead leaving that controversial process to the OSI board.
“While the licenses themselves are not ranked, it is worth noting that the report encourages developers to consider using one of the nine licenses in the widely used and strong community category,” she said.
“So that will be the next piece for the OSI board, which is considering two further actions: one, how to fit new licenses into these categories and, secondly, if there is a recommendation that can be made around the category or the licenses inside them,” Peters said.
A discussion list has been opened to get feedback from the community on the report, which will be followed by a final recommendation to the board that will then be adopted and published.
“The comments have been fairly light so far, and I havent seen a lot of disagreement, which Id like to think means we did a good job,” she said.
Next Page: A spectrum of licenses.
A Spectrum of Licenses
The committee also wanted to reflect a spectrum of licenses, from a strong copyleft one to a very permissive one in each category, she said.
There are nine licenses in the “popular, widely used category,” including the Apache License 2.0, the new BSD license, the GNU GPL (General Public License), the LGPL (“Lesser” General Public License), the MIT license, Mozilla Public License 1.1, Common Development and Distribution License and Eclipse Public License.
There are also nine licenses that are categorized as “redundant with more popular licenses,” including the Academic Free License, and the Attribution Assurance License.
Among the 24 non-reusable licenses are the Apple Public Source License, the Computer Associates Trusted Open Source License 1.1, the IBM Public License, the PHP License, the Sleepycat License and the Sun Public License.
The goal of the Licensing Proliferation committee was never to recommend the removal of any existing licenses, Peters said, but rather to help drive people to a smaller subset of those licenses.
But, at the same time, the committee also realized that licenses needed to be upgraded from time to time and so there will be new licenses that come out and new versions of licenses approved, such as the upcoming GPL version 3.0.
“Our goal has never been to eliminate licenses per se,” she said.
Peters also criticized the ever-growing list of boutique licenses that are springing up, such as the SugarCRM Public License, which are not approved by OSI as meeting the open-source definition.
“Having people in different places saying that their licenses are open source when they are not OSI-approved could ultimately undermine open source,” she said.
The second piece of the committees draft report was a recommendation that the OSI board create a license wizard that allows users to go through and identify the characteristics that they feel are important for their particular model. That helps them then narrow down the selection, Peters said.
The draft report notes that volunteers from University of Southern California law school and the San Francisco State engineering department are currently working on this Web-based wizard, which will allow people to see which open-source licenses meet criteria that they find important.
“For example, if a user indicates that having a copyleft license with explicit patent grants is important, the wizard will look through the OSI-approved licenses and output a list of licenses that meet [or almost meet] those criteria,” it says.