BSD-like licenses and the OSI approval process

[Chris Travers]

On 10/16/07, Matthew Flaschen <matthew.flaschen at gatech.edu> wrote:
> Chris Travers wrote:
> > 2)  Go with the theme-and-variations approach I mentioned earlier.
> > Have a separate track for approving minor wording changes, and list
> > them in the parent licenses listing.
>
> I don't think this will solve, or even reduce, the license proliferation
> problem.  True, it will minimoze the number of licenses on the main
> list.  But it will encourage proliferation in general.

I suppose it depends on how you define license proliferation.

I would point out that only a miniscule percentage of actual open
source licenses have their wording approved by the OSI.  I think
approving these individually is one of the concerns that Larry has.
So I guess this is not an issue of proliferation per se.  After all,
the licenses are already out there and have been for longer than the
OSI has been around.  It is a question about how to fairly deal with
the proliferation of the past.

Telling projects to change their licenses is a nonstarter.

In a similar vein, Donnovan Hawkins wrote:
> BSDL is the model for
> what people want from a permissive license. A proper permissive license
> replacement needs to be direct regarding permissions but relatively silent
> regarding how to deal with violations. Wording needs to be bulletproof
> enough that one-track-mind programmers will accept it. Permissions need to
> be utterly explicit (one of the weaknesses of BSDL). Disclaimers need to
> be so broad that you aren't even promising that you're you, regardless of
> whether it is necessary or effective...tons of BSDL-like licenses differ
> only in their disclaimer. There should not be more lines of definitions
> than there are total lines in the original BSDL.

I would add that the license needs to be as short as possible.
Clarity is not always found in length.  (Quite frankly it is unclear
to me whether the AFL requires source code redistribution in verbatim
copying relating to a collective work, as this would involve someone
sublicensing the original work to downstream licensees.)  In fact, to
my lay reading, the AFL reads like some chimera between the Aferro GPL
and the BSD license.

The act is-- it doesn't matter *what* you write in the license--
people will always find some areas which are unclear.

Best Wishes,
Chris Travers