Re: BSD-like licenses and the OSI approval process

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.  At
least now,
people won't submit a permissive license that's only a word
off from an
approved one.  But if it's just a (lightly-discussed)
variation, why
not?  This opens the door to unlimited variations, all with
some form of
OSI sanction.  I believe this will increase work for both
OSI and the
FOSS community.

Matt Flaschen

On 10/16/07, Matthew Flaschen <matthew.flaschengatech.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