Three new proposed OSD terms

[David A. Wheeler]

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
http://www.dwheeler.com/essays/gpl-compatible.html).

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
  be created.
* 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
     http://www.oreilly.com/catalog/opensources/book/perens.html
   "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.
Suggestions welcome.

--- David A. Wheeler