RE: BSD-like licenses and the OSI approval process

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

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! 

/Larry


> -----Original Message-----
> From: Chris Travers [mailto:chris.traversgmail.com]
> 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 <cowanccil.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

On 10/16/07, Lawrence Rosen <lrosenrosenlaw.com> wrote:
> I will restate my point yet one more time so Chris can
better understand his
> options.
>
> 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.

There are both technical and logistical reasons why this
will not
work.  For example, conflicts regarding package management,
and the
unwillingness to ask people to download many MB extra of
software in
the initial download.

>
> 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!


My concern is that there seems to be pressure (Mr Tiemann's
blog for
example) on vendors to either call it something other than
"open
source" or use OSI-approved licenses.  If I want to
say, "depends only
on open source software" I am worried about pressure in
the future.

If we all agree that there is no "open source"
brand that the OSI is
"protecting" then the problem goes away.  But
unless that happens,
there isn't a lot of room to maneuver.

In short, I think that OSI needs to choose either to abandon
the
question of "protecting" the "open
source" brand, abandon the worry of
license proliferation, or look for a structure which will
allow for
some attempt to balance these.  Otherwise, vendors like me
get pushed
into a corner regarding public statements by board members.

>
> 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.

My issue is that OSI approval is being positioned as being
a
requirement for calling a project "open source." 
If that goes away,
then I have no interest in getting the license approved.  If
it does
not, then I have every interest in either doing so or
publicly and
loudly challenging the right of the OSI to make that
connection.  If
you don't mind, I would rather work with you and avoid the
confrontation altogether (or at least limit it to this
list).
>
> 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!

Our business software is licensed under the GPL v2 or later
because of
inherited code.  We have no plans to change this.  We
briefly
considered the OSL, but I opposed that because I felt that
it would
make it harder to make our official download sites *the*
primary and
authoritative point of download (I also generally do not
like the
external deployment clause for other reasons).  However, we
depend on
software licensed under other licenses (all permissive
licenses).
Some of this software is widely distributed separately, so
we don;'t
want to duplicate the effort.

Unlike you, I do not think that the BSD License gives me the
right to
take a verbatim copy of the software and simply change the
license, so
a separate distribution of such dependencies would be also
out of the
question (at the moment PostgreSQL is the only component
which poses
this problem).  The PostgreSQL core team also objected to
such an
idea.

I am sorry, but your license change solution does not meet
my needs.

Best WIshes,
Chris Travers

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