Three new proposed OSD terms
David A. Wheeler
dwheeler at dwheeler.com
Wed Mar 2 19:57:27 UTC 2005
Russ Nelson said:
> We have always pushed people in this direction, but by adding these
> terms to the OSD, we will be proactively refusing licenses which don't
> meet these requirements.
>... duplicative ... simple ... reusable
Matthew Garrett then said:
> Duplicative licenses aren't a major problem *as long as they're mutually
> compatible*. In some cases we have licenses with the same aims, but
> which can't easily be incorporated into the same work. I think that
> actively hinders development.
I think there are two separable issues here:
duplicative licenses and incompatibility.
Having duplicative licenses is a problem for understanding things.
Nobody really wants to read "yet another license", and analyzing
them takes time & resources better spent elsewhere.
It may be impossible to even figure out what the ramifications are!
Incompatibility is a slightly different, and in many ways a more
serious problem. There are many times where I'd like to be
able to embed some program A (or fragments thereof) into
program B... and if the licenses aren't compatible I can't do that.
So limiting the cases where programs are incompatible is
really handy. For example, since many common licenses
are GPL-compatible (GPL, LGPL, MIT, BSD-new), if
two licenses are GPL-compatible then their code can
be merged, and that's really useful for reuse (I note this in
I suggest the following:
* I suggest not changing the OSD; instead, add these other
conditions to an additional set of criteria for OSI approval,
and cross-reference to that from the OSD. The OSD is really
higher-level statement of goals.
* Add a fourth term dealing with incompatibility,
beyone what's been said for duplication:
*The license must minimize incompatibility with
other OSS licenses*. In practice, successful OSS projects
often reuse software developed by other OSS projects and
are developed using commons-based peer production.
OSI encourages OSS licenses to be written so that it
is possible to combine existing OSS projects into
larger combined works whenever appropriate, so that
software reuse is possible and the number of relevant
peers can be increased for a project. Licenses should avoid
creating gratuitous incompatibilities. Ideally an
approved license should be compatible with at least one
of the recommended OSS licenses so that combined works can
* I think the idea of a special tier of "recommended" OSS
licenses is a good idea. The list of approved licenses is
pretty overwhelming to someone new, and it's risky for someone
to choose a license other than the few common ones.
Bruce Perens noted back in 1999, in
"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."
Perens recommends GPL, LGPL, BSD-new, MPL, and the MIT licenses, and
he recommends MIT over BSD-new (due to simplicity arguments).
That's still not a bad list: GPL, LGPL, MIT, BSD-new, MPL (or some variant).
If you must, add the Artistic license.
By having a "recommended" tier, those with truly innovative license ideas
can make their pitch... but the vast majority of the world can
see what's recommended, and start there.
So how do you pick the recommended list? I think the short answer
is, use popularity as your guide, both in lines of code and # of projects.
Freshmeat and SourceForge both have stats on the number of projects;
my paper http://www.dwheeler.com/sloc has some stats on lines of code.
Then snag the first few. Figuring out exactly where to cut things
off is hard. Heck, even seven would be better than
the massive list currently on the site. A long list would probably look like
GPL, LGPL, MIT, BSD-new, MPL (or some variant), Artistic.
I'm sure improvements could be made to the text above.
--- David A. Wheeler
More information about the License-discuss