BSD-like licenses and the OSI approval process

[Chris Travers]

Just as a clarification.

On 10/12/07, Lawrence Rosen <lrosen at rosenlaw.com> wrote:
> Chris Travers wrote:
> > I am not a lawyer and you are, so perhaps you could enlighten me, John
> > Cowan, and others who question why we should assume the BSDL is
> > divisible?
>
> Chris, please note that I never once used the word "divisible." I have no
> idea whatsoever what that word means for a copyrighted work. Rephrase your
> question, but please do it privately to me to avoid cluttering the list.

This was based in large part on documents such as
http://www.publaw.com/1976.html (though that appears to be at odds
with Gardner v. Nike-- a case would is also outside his circuit).
Again, IANAL, so I could be misreading his interpretation of
indivisible vs divisible licenses.

The central question is:  Does the BSD license allow the rights
granted under it to be subdivided and and granted only in part to
downstream users?

Or does it merely allow people to assert their own copyrights in ways
which do not violate the right of those who own portions used with
permission to license those in ways they see fit?

If the former is true, then I can take, say, the OpenBSD kernel, wrap
the whole program under the GPL v3 and ship it with no further
modifications, claiming tht the ISC license gives me this permission.
If the latter is true, I can only make that assertion after adding
copyright-worthy elements (for example, I could add some graphics I
had designed to the boot screens and enforce my copyrights to those
images).

Similarly, if I receive PostgreSQL which has been sublicensed by a
third party under the terms of the GPL v3, in the former case, I might
have to contact the developers for permission to revert the license.
In the latter case, I could ignore the GPL v3 entirely and could not
be sued even by the original copyright holders.


> Read almost every BSD license. "Redistribution and use ... are permitted
> provided that the following conditions are met." I can assure you, I'll meet
> those conditions when I combine those BSD-licensed works into an AFL
> 3.0-licensed collective or derivative work.

Nobody is disputing that.  But if you then distribute a single
unaltered BSD file out of that collected or derivative work, I don;t
think the AFL applies as far as copyright goes.  Or am I wrong here?

> I'll be just as careful as FSF
> is when it combines BSD works into GPL programs, and as Microsoft and IBM
> are when they combine BSD works into proprietary works.

Again, nobody is disputing that.  But this would be different if a
Linux developer wanted to change the license of a wireless driver
without first substantially modifying it, I would think.

>
> My reply to John Cowan earlier today addressed what I think your question is
> about. But let me say it a different way: As I wrote in my book, the BSD
> license certainly is not expressly sublicenseable.

According to every source I can find, it is settled law that
nonexclusive licenses do not provide any implied sublicense right
beyond those minimally required for the reasonable utilization of the
rights explicitly granted in the license.

As I would read it, then, sublicensing is only allowed in the BSD
license to the minimal extent required to utilize the other rights
granted in the license.  For example, if I want to incorporate your
BSD code into my proprietary application which is then included on a
CDROM which is shipped with a book, I can sublicense the code to the
publishing house for that purpose because it is necessary in order to
reasonably utilize the rights granted in the preparation of derivative
works.   (The MIT license is more interesting in this regard)

This would seem to me to be no different than if you give me
permission to use your photographs in my book.  That might give me
implied permission to sublicense them to the publisher, but only for
the purpose of publishing my book (I couldn't turn around and
sublicense your photos for a magazine article based on the book, or a
web site).

I see the BSD license the same way.  If you want to license a
derivative or a collected work under a more restrictive license, then
sublicensing the BSD licensed content *for the purpose of publishing
that work only* is permitted.   I would read it as not allowing a
global relicensing of the BSD-licensed original content, but merely an
ability to negotiate with distributors for the relevant rights to
distribute or publish your work.  As you said before, the original
components, or what is left of them, would be governed by their
original licenses.  Once extracted (for example, the unaltered file
distributed by your site), the license to the larger work would no
longer apply and since the permission grant must be maintained, it
alone would govern the extracted excerpt or full work merely used with
permission.

In essence on your hypothetical site, the BSD license does not give
you the right to tell me what I can or cannot do with code you didn't
write, but simply provides you unlimited ability to publish and
distribute your own works which include that code.

Does my perspective make more sense?

> Everywhere people take BSD software and incorporate it into other
> collective and derivative software works, and nobody has ever complained
> about the public's right to do so, or about the fact that another license
> usually surrounds the BSD-licensed work. Ever.

No, but a license change of a specific file, even wrapping a file in a
new license, has been known to cause problems.

For example, if there is a file in the Linux kernel which is licensed
under the BSD or ISC licenses and distribute it separately, then the
GPL no longer applies in any way.  This is not a matter of "reverting
the license" rather than simply removing it from the larger work whose
expressive elements were not added to the portion I took *or* were
licensed otherwise under the BSD or ISC license.

>
> In that context, why are we still arguing about "sublicensing"? Is it still
> a legal concern for BSD-licensed software?

I suspect the recent OpenBSD flap has something to do with it, as does
the fact that the "sublicensing is not permitted" view is held
actually by a large number of developers of BSD-licensed software who
are not as political as Theo.

And I suspect that general attempts by the OSI to be the definitive
listing of "real" open source licenses has something to do with it.
>
> One thing we can do is to take advantage of these common interpretations of
> the BSD-like licenses and redistribute those works under a more mature open
> source license, in the process eliminating (for all practical but not legal
> effect) hundreds of slightly different BSD-like licenses that do nothing but
> confuse the public.

First, I don;t think that one should try to force-feed licenses on projects.

One option is to adopt a more modular policy on license approval and
listing.  *The only* difference between the Intel Open Source License
an the New BSD License is an additional disclaimer.  Why not
consolidate the listings and suggest that the latter is nothing more
than a variation on the former?

Where this is not possible, why don't we, as an organization, start to
work with organizations which have substantially similar license with
the goal of license convergance.  Why don't we stop trying to tell
people what is better, and help their own legal counsel work out
agreements going forward?

And why don't we move away from popularity-driven categories in favor
of functional categories so that people can more easily find whatever
licenses they need, whether that is BSDL, MITL, AFL, GPL v2, OSL, or
whatever?
>
> Certainly one can do that mechanically, as several here have suggested, and
> you'll get a mechanical compendium of BSD-licensed software on which you can
> claim a very thin collective work copyright. Or one can add some
> intelligence to the compendium, some guidance as to how to use the software,
> and some sophistication in its collection and organization. Combine that
> with appropriate warranties and representations, an audit trail and
> indicators of provenance, and I predict that such a copyrightable collective
> work under AFL 3.0 would resolve the BSD license proliferation problem to
> the satisfaction of most open source customers in the world.

I am still utterly confused how the AFL would apply to the
BSD-licensed components that you merely use with permission.  Last I
checked,a collective work's copyrights didn't extend into portions the
copyright owner didn't create.


> My point is
> that OSI shouldn't try to approve every BSD-like license in the world, but
> we should find another way to give comfort to customers about BSD-like
> license terms.

Agreed on this limited point.

How about by declaring that they are all, as a class "Open Source" and
therefore approval is unnecessary?  We could even drop the listings
for the "New BSD," MIT, Intel Open Source License, and a few others,
and replace with one listing as a class (perhaps with examples from
those dropped licenses).  I think this is what Michael was getting at.

Look, all I am looking for is a clear and unambiguous statement from
OSI that they believe that they clearly see software under these
licenses as open source and therefore businesses such as myself aren't
going to be under pressure to adopt "OSI approved" licenses or stop
calling our work open source.

Best Wishes,
Chris Travers