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

[Ernest Prabhakar]

Hi all,

Just catching up after an extended absence.  I decided to turn Andy's  
excellent summary into a FAQ:

> https://osi.osuosl.org/wiki/help/license


> Q: Can I always "relicense" BSD licensed-software under a new license?
> If you define relicensing as "sublicensing, possibly under  
> additional terms and conditions which do not contradict the terms  
> and conditions of an original licensor's permissive license", then  
> the answer is generally "yes" -- provided you also retain the  
> original copyright information. However, strictly speaking, you can  
> only modify the license of a "derivative work", and opinions differ  
> on how much change is required to qualify as a derivative work. The  
> MIT license and Academic Free License, for example, freely allow  
> "trivial" sublicensing (without any other changes) as long as the  
> copyright is preserved. Conversely, the Apache 2.0 license only  
> allows sublicensing for "Derivative Works", which it defines as  
> "original works of authorship" -- meaning non-trivial additions. The  
> new BSD license, unfortunately, is silent on this point. If you are  
> planning to "trivially relicense" BSD software, you are encouraged  
> to first check with the copyright holder and/or your own legal  
> counsel.
>

Let me know if you have further suggestions.  Thanks!

-- Ernie P.

On Apr 23, 2008, at 6:04 PM, Wilson, Andrew wrote:

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