BSD-like licenses and the OSI approval process

Donovan Hawkins hawkins at cephira.com
Tue Oct 16 21:00:11 UTC 2007




Lawrence Rosen wrote:
>
> Not only that, Chris, but I
already suggested that you use AFL 3.0 for 
> *your* business
software and stop tying up this list with approval 
>
requests for all those other old and inadequate BSD-like
licenses! 

Why would he want to switch to an unpopular
license that the OSI lists as redundant?

I realize you wrote
it, but it hasn't done anything to help with license proliferation. You
wrote the license you thought people should use, rather than the license
people wanted to use. We still have no modern version of a permissive
license which can satisfy the majority of the users of permissive
licenses, and it would be far more productive to create such a license
than to continue to debate adding another dozen or so BSDL variants to the
OSI list or push the AFL 3.0 that no one uses.

It should
be clear from this list that people have entrenched ideas about licenses
that they refuse to give up. Even those that have lawyers handle it manage
to find their own way of doing things.

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.

There will
need to be a family of such licenses to account for the people who want
things like no advertising clauses or patch+orginal distribution or
runtime legal notices. I suggested following the Creative Commons model
and using keywords to add additional contraints like this (similar to the
"attribution, share-alike" wording)...combining upstream works
into a single project becomes as simple as ORing all the keywords.

This is something that has a shot at getting used by people. Every
existing OSI permissive liense should be directly expressible in terms of
some combination of keywords. The only thing you can't do is have a
license that is as short and succinct as BSDL, but again the Creative
Commons solution works: a short, simple description in plain language that
most people will use for understanding, plus the longer and more
complete license to do the actual heavy lifting.

You can't
dictate WHAT the license should do, but you can try to reign in everyone's
wild opinions on HOW to do it.

Donovan Hawkins





More information about the License-discuss mailing list