BSD-like licenses and the OSI approval process

[Chris Travers]

On 10/11/07, Lawrence Rosen <lrosen at rosenlaw.com> wrote:

> There have been a few suggestions in recent days that OSI review and approve
> BSD-like licenses in use around the world. From personal experience, I can
> tell you (1) there are a large number of subtly-different BSD-like licenses;
> (2) there aren't enough differences among these licenses to warrant the time
> and effort to review them. We are cluttering the open source commons with
> too many similar licenses.

Agreed.

> Who needs them?

If the OSI wants to equate "OSI approved licenses" with "the totality
of open source licenses" then the OSI needs to recognize them.
Otherwise, it is silly to suggest that the OSI is the only authority
as to what is open source or not.

If there is a clear statement that:
1)  Vendors which choose these licenses as still open source (Mr
Tiemann's blog seems to argue against this)
and
2) Licenses which adhere to the OSD are considered by the OSI to be
"Acceptable Open Source licenses regardless of approval or lack
thereof."  (Note that this allows a healthy discussion about whether
Qmail is open source or not as it can be argued that it barely meets
the OSD.)

But I think it would be important to settle the matter via a clear
statement from the OSI on this matter.

Personally I do not believe that it is possible for OSI to attempt in
any way to circumscribe open source licensing and at the same time
fail to approve licenses on nonproliferation grounds.  This mean that
the licenses would need to be approved but in a way which does not
cause the problems you mention.  Of course "Open Source" may be too
generic at present to be subject to trademark protection anyway, but
IANAL., and if the OSI takes that position it might be nice to see it
done explicitly....

> Why should people have to read
> them?

They shouldn't have to.  I think that both Mr Tiemann and I have
proposed solutions to this problem (either by making a distinction
between full licenses and approved variations, or by simply providing
a listing of an approved license group that meets certain criteria).

>  Why should people have to comprehend their miniscule differences?

Again, they shouldn't have to.  Again, here I don;t think the current
approach to license proliferation serves anyone.  Right now, the
categories are based on a popularity contest, nothing more.  I think
that if we came up with functional listings, and listed approved
variations, we could actually *reduce* the number of entries currently
listed, and keep them down even as new permissive licenses are
submitted.

Before you dismiss my point out of hand, consider this:
1)  The current categories do nothing to reduce submissions  for
approval of licenses, especially in the face of statements implying
that if vendors don't want to use OSI approved licenses they shouldn't
call their software open source.
2)  The current categories exacerbate the problems you have described
by making it harder to find a license which suits one's needs.



> Here's a radical solution for solving that problem.
>
>
>
> 1. I'd scour the Internet for all BSD-licensed source code software, in all
> license variants. (This can be automated; just ask Black Duck or Palomida.)
>
>
>
> 2. I'd then collect all that BSD-licensed software on a single website. (I
> visualize something like Source Forge.)
>
>
>
> 3. I'd then distribute all that software from that website under the AFL 3.0
> license. (If FSF can distribute BSD-licensed software under the GPL, and
> Microsoft can distribute it under proprietary licenses, I can certainly
> distribute it under AFL 3.0.)

You weren't kidding when you said this was radical.  And time
consuming.  And expensive.  And there is some concern over GPL
compatibility in the AFL and OSL which could result in confusion over
what license actually governs the software.  The FSF treats the
requirement of making reasonable efforts to gain express consent to be
ad additional restriction, and I suspect that that the requirement to
treat external deployments as distribution may also create a conflict.
 (Just FYI-- the LedgerSMB project briefly considered the OSL to move
towards as we remove the code we inherited under the GPL v2, but the
external deployment section was what caused me to oppose it-- this is
a good license for projects which want Aferro GPL-type rights, but is
not a drop-in substitute for the GNU GPL v2 due  to that section.  I
note that the AFL has a similar requirement in certain circumstances.)

Unless OSI wanted to take this on, I don't think there is any chance
of this happening.
>
> The AFL 3.0-licensed software I distribute is OSI-certified open source
> software, even if the underlying BSD-like licenses aren't individually
> approved by OSI. Any users who want to reassure themselves that their
> software is truly open source can obtain that software from my website
> rather than read and review each of those BSD-like licenses.
>

I would just note that while this does not, as you point out, change
the underlying license (in fact, the collection may not be
sufficiently creative to be worthy of any copyright in itself!), it
may add rather than reduce confusion.

>
> Note that I haven't changed the underlying BSD license. Anyone who receives
> the software from me obtains it under AFL 3.0 *and also* under the original
> BSD-like license.

IANAL, but here I would disagree.  Any copyrights which I might be
able to assert under the AFL would only amount to any creative
elements I added in the process of selection or arrangement.   Once
you extract a piece of it which the author of the collected work
merely used with permission, the author of the collected work would
cease to have any rights to it and hence any licenses issued for that
work would be meaningless.  Or am I missing something?

> I have to include the BSD license text with my source
> code. If the recipients don't like the AFL 3.0 terms they can revert to the
> original version of the software under the original BSD license. But why
> would they bother? AFL 3.0 gives them all the same rights.

And places further restrictions (external deployement and source code grant).

> Let's please stop complicating open source licensing with meaningless
> variations of BSD-style licenses.

THe only way to do this is to draw a clear and official line between
"licenses that are open source" and "licenses that are approved by the
OSI."  The latter is obviously a subset of the former.  If there is no
such line (and vendors feel like there is pressure to only use
OSI-approved licenses when advertising open source software), then
there is every reason to submit every license that one wants to claim
is open source.

>
> By the way, even though I describe this solution as a unilateral action, I'd
> be much more comfortable if the community itself would realize that we're
> wasting everyone's time with repetitive license approvals and they would
> make the license changes themselves.
>
First, communities don't decide to do anything.  Individuals do.
Communities obey the basic law of inertia.

There are reasons why the AFL is not quite a drop-in replacement for
licenses like the MIT license (which I argue is also indivisible even
though it allows itself to be passed on, in whole but not in part,
through a sublicensing arrangement).

The large ones are that the AFL requires source code distribution in
some cases, and furthermore requires that where these cases are met,
that mere users of the software outside of one's own organization must
be provided with the source as well.  This is a fairly radical change
from traditional permissive licenses (moreso perhaps than even the
MS-PL), and it poses a number of problems for open source projects:

1)  Changes in requirements invariably cause disruption in communities
and should be avoided.

2)  Forced distribution (for example, when running an online demo)
undermines efforts to centralize the distribution of security fixes.

I am not saying it is a bad license, but it seems to me to be awefully
disruptive and hence not something I would want to move to.

Best Wishes,
Chris Travers