How permissive is BSD? (Was: Implications for switching licenses mid-stream)

[Wilson, Andrew]

As others have noted, this is a question which seems to recur on
this list every six months or so.  As usual, it either ends in
the participants doggedly repeating the same points -- see the massive
unwillingness to engage in meaningful dialog which led to Chris Travers
being escorted from the premises -- or in what Richard Dawkins
called the "squid defense," where an author shoots a huge cloud of
ink and swims away as fast as possible (referring to the late,
great, Stephen Jay Gould, who could shoot ink with the best of them).
The list fails to reach consensus and then six months later,
we are back at it.  And, oh yes, someone always introduces the
straw man argument against removing or defacing copyrights, which is
really quite irrelevant to the question of permissible uses
for new-BSD code (with original copyright intact) under other licensing
disciplines.

Relicensing: let's use this term for brevity, and define it in this
context as "sublicensing, possibly under additional terms and conditions
which do not contradict the terms and conditions of an original
licensor's permissive license."  {Yes, I know.  Only a copyright
holder may grant a license.  Got it.}

So, the recurring question is under what circumstances may new-BSD code
be relicensed, in the sense defined above.  At one end of the
spectrum there is the camp who says simply adding a new header
with a compatible proprietary, or open source, license
to otherwise unchanged new-BSD code creates a de miminis (or de
minimus, my spell checker seems to accept both) derivative work
and this is permitted by new-BSD.  Let's call them camp A.

Another camp claims that trivial relicensing is not allowed 
and that relicensing is only permissible when new-BSD code is included 
in a derivative, or a collective work, where the deltas represent 
a non-trivial, original work of authorship. Let's call them camp B.

Finally, there is the extreme left-wing position that BSD isn't 
a permissive license at all, it is a stealth copyleft license,
and original BSD code and any derivatives of original BSD code
must always and forever be available
in source under BSD.  Since Mr. Travers' departure, this position
doesn't have many adherents, so I won't discuss it further.

It's instructive to look at other permissive licenses usually considered
more or less functionally equivalent to BSD.  MIT/X11, for example, 
includes the right to sublicense without limitation so long as copyright

notices and disclaimers of warranty are preserved.  Camp A would have a
pretty
strong case if this argument were about MIT/X11.

AFL 3.0 makes it even clearer.  Sec. 1(c) says flat out that original
works,
and derivatives, may be distributed "under any license of your choice
that 
does not contradict the terms and conditions, including Licensor's 
reserved rights and remedies, in this Academic Free License."  Camp A
would clearly be correct if this argument were about AFL.

Apache 2.0 is different.  Last para of sec. 4 reads

	You may add Your own copyright statement to Your modifications 
	and may provide additional or different license terms and
conditions for use, 
	reproduction, or distribution of Your modifications, or for any
such 
	Derivative Works as a whole, provided Your use, reproduction,
and 
	distribution of the Work otherwise complies with the conditions 
	stated in this License.

This allows relicensing (in the sense defined above) but only for
Derivative Works, which are defined as original works of authorship.
Camp B is giving an accurate summary of Apache 2.0.

So who then is right about new-BSD?  Should we read new-BSD like AFL,
or like Apache?  I don't know.
I also don't know who has the time, energy, and standing to 
bring a good test case to court, there being no institutional
equivalent to FSF as license steward for BSD and all its many variants.
Community practice mostly seems to tolerate camp A trivial relicensing.
As I noted before, there are quite a few examples "in the wild."
On the other hand, camp B can make a logical case for their
position.

I do have a few thoughts.  One is that if a licensor really wants
the most permissive, camp A license possible, he/she should think
about using MIT/X11 or AFL rather than new-BSD.  Another is that
a licensor who is allergic to camp A really ought to use Apache,
or BSD with an additional anti-relicensing clause such
as the SSLeay license (http://www.openssl.org/source/license.html,
not OSI-approved), or the Microsoft public license.

Cheers

Andy Wilson
Intel open source technology center