OSI and License Proliferation

FOSSBazaar is no longer being updated. The information on this site is preserved for your convenience but may be out of date. Please visit Linux Foundation's Open Compliance Program for current information and activities.

tbm's picture

License proliferation has been a topic for discussion for quite a while now in the FOSS community and many would like to see the Open Source Initiative (OSI) fix this problem for good. In a license proliferation report, the OSI lists three problems that people generally see with license proliferation:

  1. Too many different licenses makes it difficult for licensors to choose: it's difficult to choose a good license for a project because there are so many.
  2. Some licenses do not play well together: some open source licenses do not inter-operate well with other open source licenses, making it hard to incorporate code from other projects.
  3. Too many licenses makes it difficult to understand what you are agreeing to in a multi-license distribution: since a FOSS application typically contains code with different licenses and people use many applications which each contain one or several licenses, it's difficult to see what your obligations are.

License proliferation is a hard problem because nobody wants to give up their favourite license and because it can be extremely difficult to relicense a piece of code when there are multiple copyright holders, as is the case in the majority of community projects.

It's a particularly hard problem for the OSI because of two conflicting interests. One the one hand, the OSI approves licenses as open source based on the Open Source Definition (OSD). Therefore, it seems natural that a license that fulfils the OSD should be approved as open source. On the other hand, because of the problems of license proliferation, it's beneficial to keep the number of open source approved licenses low.

At the OSI meeting in Portland a few weeks ago, the Board decided to tackle this problem again and split licenses into two tiers. The specific wording has not been finalized yet, but "recommended" and "compliant" have been suggested. This would make it clear which open source licenses are "merely" OSD compliant whereas a limited number are recommended for use in projects.

The discussion about the two tiers has just started, so there are no results yet. But it's definitely an important discussion that needs to take place.


The ones being recommended are going to be recommended based on what?
tbm's picture

That still needs to be

That still needs to be worked out... but it'll offer a range of licenses, from more to less permissive (i.e. copyleft or not). Popularity should also be taken account to some degree.

ernest.park's picture

License Proliferation - less is more, one is best

Chris DiBona from Google suffered the slings and arrows of the OSS community when he rejected the AGPLv3 license for Google Code repository, citing license proliferation as one of hte reasons. Looking back, Chris challenged the wisdom of OSI years ago when he was on their board, still at the time fighting against yet another license.

An open source software license is specifically a copyright focused on types of use permitted for electronic media.

By introducing yet another license, it create more complexity to explain, understand, and enforce the use of software governed by these licenses.

The reality is that lack of clarity and confusing, or internally contradictory terms, makes the license potentially limited in worth, as the cost to actually enforce that license increases.

If we look at any open source software license, we realize that they all are governing copyright specific to the use of software.

Use type -
1. Copying: This is the term popularized by Free Software Foundation to describe the act of moving the software from a point of distribution to a local computer, solely for the purpose of personally using the software.

2. Distribution: Once software has been collected from a distribution point, the act of making it available, either by itself, repackaging, bundling, modifying configuration files specific to a platform, and then making the resulting software available for others to "copy".

3. Modification: When a user takes code that has been copied, and implements changes to the source code, such that the program is changed, and then makes the code available through a distribution channel for others to "copy".

4. Other: This refers to license clauses that set restrictions on actions of software uses for actions outside of the direct use, as described above, of the software. Typical "other" language defines restrictions of special restrictive language specific to the use of the original developer's name and branding in marketing done by a distributor/modifier of software copied.

Restrictions -
1. Limitations of liabilities, as is clauses
2. Advertising restrictions
3. Licensing fees, shared revenue, restriction of revenue activities
4. Export restrictions
5. and so on
6. Downstream licensing on modified code

"Restrictions" govern "use" type. Many restrictions also only exist for specific use type.
Revenue restrictions, downstream licensing requirements, and triggered by modification, and or distribution, as example.

Therefrore, if you are copying and distributing, many restrictions don't even apply.

In summary, open source software licensing has become needlessly complex, FUD evolves around rumors of compatibility and interoperability without consideration and understanding of use types and specific restrictions. Open source licensing is a copyright with specific use considerations, restrictions and terms defined within the license, rahter than by copyright law. The thousands of licenses that exist have complicated the issue of using open source software far too much than the issue requires. Practically, we need only one license that specifies the use types and associated governance. Anything beyong one simple license that we can clearly explain the use and restrictions around open source software fails the future use and growth of the adoption of such software.

Ernest Park

Why expend effort on licenses that are merely "compliant?"

I think another interesting question, responding to the following quote from the article:

"At the OSI meeting in Portland a few weeks ago, the Board decided to tackle this problem again and split licenses into two tiers. The specific wording has not been finalized yet, but "recommended" and "compliant" have been suggested. This would make it clear which open source licenses are "merely" OSD compliant whereas a limited number are recommended for use in projects."

is why anyone would want to waste time on a license that is "merely" OSD compliant? If such a license is not recommended for use in projects, what is the point of its existence? Merely a vanity license? Shouldn't we use our efforts to work on and use licenses that are actually practical and usable?



tbm's picture

Yes, I agree. People

Yes, I agree. People generally should look at existing licenses rather than create their own, and the OSI actively discourages the development of new vanity licenses. However, existing licenses that are not recommended will not go away and there may also be new licenses with very special needs.

Having said this, when there's a strong dichotomy between recommended and compliant licenses, you'll also need a process for a new license (think GPLv4) to become a recommended license.