BSD-like licenses and the OSI approval process

[Chris Travers]

On 10/16/07, John Cowan <cowan at ccil.org> wrote:

> > So the alternative in your mind is to certify every reasonable BSDL
> > variant individually?  Or do we insist on PostgreSQL not being "Open
> > Source?"
>
> The former, I think.  Yes, it's annoying; the alternative is still more
> annoying.  We can't legally protect the term "open source", but we can
> in turn make life annoying for people who misuse it.

Ok, then just to be clear.  This really pressures vendors such as my
business to submit any BSD-style license we want to advertise as open
source.  At the point when we start using ICU for number to text
conversions, we will need to submit that license.  If we release
something that depends on X.org, then we get to submit that license
(MIT license with the word "sublicense" removed), and so forth.

I don't have a problem with that.  I am quite happy to do this (and
contrary to Zac's comments, these are limited to projects promoted by
my business-- I understand how he got the impression that I was just
trying to be disruptive, but he is incorrect.  I do have legitimate
reasons for these submissions).

It still seems wise to wait to proceed with the request for approving
the PostgreSQL license until after the OSI board decides on what they
want to do about this issue.  Since I am not on the board, these
issues of ground rules are not my decision.

It seems to me that this really boils down the the tension between
wanting to defend the term "open source" as if it were worthy of
brand-name protection and the desire to prevent massive proliferation
of licenses.  This is a serious problem which does not have any real
solution.  At best we can manage this tension.

THis brings me to the next point:
If we go with individual approval, then we need to decide how to
manage the license proliferation issue.  I see three options:
1)  Proceed with single license listings.  This will cause massive
issues in finding appropriate license information.
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.  For example, the LGPL could be
approved as a variation on the GNU GPL.  The one caveat I would
suggest here is that variations should not cross license class
boundaries (Permissive vs copyleft).  So the AFL and OSL would be
separate licenses regardless of how few words changed between the
licenses.
3)  Approve a license class (Mr Tiemann calls this a "cohort") and
then allow minimal discussion over what licenses are listed as members
of that class.  It would seem to me that future versions of the AFL
could be approved as a cohort member, and so it is quite possible to
run into all sorts of politics over when to approve a full-fledged
license.

Best Wishes,
Chris Travers