Three new proposed OSD terms (next steps?)

[David A. Wheeler]

It appears to me (though I could be wrong)
that there's a rough working consensus that
the OSI should continue to accept OSS licenses that meet the
current OSD, and not change the current OSD. There also seems
to me to be a rough consensus that OSI should create a new short subset of
"Gold"/"Recommended" licenses (whatever they're called!).
This subset would make it especially easy for new projects to pick one of a few
common licenses, and newcomers would be herded to this
subset as a suggested place to start.  Let me say  AOL^H^H^Hme too!

Here are actions I think need to happen next, based on some of the
previous emails I've seen, if this really is what's agreed to:

1. What's needed is a list of criteria for a license to become a "Gold"
standard.... as well as a good name for this subset.
The original proposal of 3 items isn't a bad start,
particularly the requirements for templatability and understandability
(if a license is to be widely used understandability is even more important).
I recommend adding "market acceptance" as a critieria (e.g., use
on several projects as shown by various stats).
A "Gold" license should have significant marketplace acceptance,
and while the other criteria are more subjective, you CAN
measure how many projects & lines of code use a license.
I point to some data sources at:
http://www.dwheeler.com/essays/gpl-compatible.html
That means that anyone can create an OSS license, and have it
reviewed, but to be a "Gold" standard people actually have to pick it up.

2. You'll need to start creating that set using that criteria, which will really be
a continuous process.  There are some licenses for which there is
unanimous agreement (GPL, LGPL, at least one of BSD-new or MIT),
so start there.  To head off the "what about mine?!" query, make it clear
that this is an ongoing process, and that more will be added.
In the end, this decision is going to have to be made by a group others
can trust, because there will inevitably be some subjectivity in where
to cut things off.  There are some thickets here. Some licenses
are only common for certain situations (PHP license
for PHP code) - should they be listed?
How popular is "popular enough"?
And should both BSD-new and MIT licenses be in the list?
After all, they're BOTH widely used;
Perens recommends MIT over BSD-new because the MIT license is
much easier to understand, better meeting the "understandability" criteria.

3. Another useful action will be to create a templatable MPL. Not easy, but
I think that'd be an excellent idea.  I suspect if you identified the
top projects using MPL-like licenses, you might be able to hammer
out something; it'd take time, ESPECIALLY to get anyone to switch..!
This would take a while, but I see a big-win possibility here.

4. Once you have a Gold list, it'd be useful to have a taxonomy - basically
an aid to license selectors, so they'll know what some of the important
differences are between their options, and what is compatible with what.
As most of you already know, there's already one attempt that might be a good
starting point, and that's Perens' paper at:
 http://www.oreilly.com/catalog/opensources/book/perens.html
I find it interesting that this 1999 paper warns about the very issue
that started this: "Do not write a new license if it is possible to use one
of the ones listed here. The propagation of many different and incompatible
licenses works to the detriment of Open Source software because fragments
of one program cannot be used in another program with an incompatible license."
It should also note that some communities have specialized licenses & that
if it's widespread in that community they should consider using that
(e.g., PHP license common for OSS/FS PHP code, and
GNAT-modified GPL is common in OSS/FS Ada software).

5. I think the "Gold" list could also eventually select one of a few common
"riders", if certain riders become common.  But I think that is for the future.

Hope this helps.

--- David A. Wheeler