Three new proposed OSD terms

[Michael Poole]

Joel West writes:

> On 5:33 PM -0500 3/3/05, Russell Nelson doth scribe:
> >So are you saying that you see no solution to the license
> >proliferation problem?  Or are you denying the existance of the
> >problem?
> 
> * In the 1980s we had a proliferation of PC assembly companies.
> * In the 1990s we had a proliferation of .com companies.
> * Today we have a proliferation of open source projects.  On
> SourceForge alone, 96,737 as of this afternoon.
> 
> How would we know a priori which of these companies or projects or
> licenses are "right" or "important".

The number of projects, or selecting which are important, is not
relevant to the discussion of license approval.  The issue at hand is
which licenses are important -- and *why*.

It is possible that a license's behavior in court will be a factor in
its importance, but the far more likely factor in a license's
importance is how much code is released compatibly with it.  The
reason to encourage the broad use of a small number of licenses is to
make it easier to reuse code.

The only good reason to advocate for more OSI approved licenses is
when existing ones do not meet your needs.  Licenses exist almost as
parasites on the software: they live on only because of to what they
are attached to.  I submit that software innovation is a higher value
than "license innovation," and that a regular license landscape
furthers software innovation more than having a large number of
licenses.  That is why duplicative or non-reusable licenses are a
serious impediment to Open Source.

Out of 60,764 projects that entered enough information to be listed on
SourceForge's project map, 42,066 use the GPL; 6,755 use the LGPL;
4,361 use the BSD license; 1,192 use the Artistic License; 1,109 use
the MIT license; 979 use the Mozilla Public License 1.0 or 1.1; 949
use the Apache Software License; Common Public License is 457; Apache
2.0 is 322; zlib/libpng License is 314; Open Software License is 286;
and no other license accounts for more than 200 projects.

Combining "old" licenses with their most current version, we see 9 or
10 licenses that account for 97% of SourceForge projects.  I grant
that large non-SourceForge projects want new licenses more often than
small projects or projects hosted on SourceForge -- but a license
maze[1] is harsher on both software users and software producers.

Michael Poole

[1] You are in a maze of twisty little MPL derivatives, all alike.