Subject: RE: BSD-like licenses and the OSI approval process
From: "Lawrence Rosen" <>
Date: Tue, 16 Oct 2007 10:28:29 -0700

I will restate my point yet one more time so Chris can better understand his

I don't understand why Chris' business is hurt because he can't claim that
each of the components of *his* software are under OSI-approved BSD-like
licenses. Who cares about that? Chris is already free to:

1) Combine all those BSD-licensed components into *his* software.

2) Release *his* software under an existing OSI-approved license, and not
worry about the licenses on the components. *His* software will be open
source as long as he really does provide all that source code!

As long as Chris complies with the terms of all those other BSD-like
licenses on the components he uses, he shouldn't care one whit whether
PostgreSQL or those other licenses actually get OSI approval.

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! 


> -----Original Message-----
> From: Chris Travers []
> Sent: Tuesday, October 16, 2007 9:22 AM
> To: License Discuss
> Subject: Re: BSD-like licenses and the OSI approval process
> On 10/16/07, John Cowan <> 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, 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