Dispelling BSD License Misconceptions (fwd)

[Chuck Swiger]

On Jan 17, 2007, at 3:45 PM, Matthew Flaschen wrote:
>> You're welcome to decide
>> for yourself that you don't want to use proprietary software,  
>> Matthew,
>> but you seem curiously unwilling to acknowledge that people using
>> BSD-licensed software to write proprietary software are also users of
>> BSD software.
>
> They are users (sometimes in the sense of both end users and
> redistributors).  However, my point was end users of proprietary
> BSD-based software generally have no way to extract the free BSD code.
> Thus, they can no longer redistribute the BSD code in that version.

It's certainly common for people to statically link in BSD code into  
a proprietary program in a fashion that makes it difficult to extract  
or update.

On the other hand, it's not uncommon for even highly proprietary  
software (I'm thinking about things like Windows-based games, which  
tend to be copy-protected & come with obnoxious forms of DRM like  
Starforce, SecuROM, SafeDisc, etc) to have a zlib.dll or similar,  
where you actually can swap that out for a newer version of the ZLib  
compression software you build yourself.

>>> Thus, for example, much of OS X is under a BSD license, but  
>>> difficult to
>>> extract out the BSD code and use it separately.  There's also  
>>> usually no
>>> reason, since it's available untainted straight from the source.
>>
>> It's not hard to get the BSD-licensed portions of OS X from Apple:
>>
>>   http://www.apple.com/opensource/
>>
>> ...and I know that a number of changes and improvements Apple have  
>> made
>> their way back into the BSDs, to the Apache projects, to the ISC's
>> software (BIND, DHCP, etc), and elsewhere.
>
> Okay, that was probably unfair, and a bad example.  I don't think  
> Apple
> has separately released all the BSD code they're using (but I may be
> wrong).

Perhaps you might ask Ernie Prabhakar; I cannot answer that question  
myself.

> However, Microsoft for instance has been less cooperative
> still.  Early versions of Microsoft used the BSD stack extensively  
> (they
> may still, though I'm not sure).  Even though that code is under  
> the BSD
> license, it is impossible (I think) to extract and redistribute the  
> BSD
> code MS uses.  Thus, the BSD license for the TCP stack doesn't affect
> endusers of Windows NT; they can't become redistributors (of  
> WinNT's TCP
> code).

Microsoft's licensing actually lists a number of BSD contributors who  
have worked on the TCP/IP stack and firewall capabilities, and this  
is still true of XP/2003/Vista, so it's reasonable to assume that  
there's still a fair amount of BSD-derived code lurking in their  
network stack.

It would be difficult to extract that code, agreed, although it is  
quite possible to replace the CLI binaries for things like ping, ftp,  
telnet, and so forth with alternatives.  That's part of what Cygwin  
does.

>>> I misread "as part of a compilation" as the vague and totally  
>>> different
>>> "when compiled together".  Excuse me for this foolish mistake.
>>
>> I see-- very well.
>
> My apology sounds sarcastic now.  It wasn't meant to be.

A legitimate confusion about what someone meant happens sometimes  
even with the best of intent on both sides; no problem.

>>> My understanding (I admittedly did not originally interpret the  
>>> license
>>> this way) is that BSD doesn't apply for even derivative works,  
>>> only for
>>> the original code.
>>
>> I would not agree with that position at all.
>
> This is certainly an important issue, and I would appreciate hearing
> from others or being pointed to some resources to clarify.  When I  
> first
> read BSD, I interpreted it your way, but have since been steered to  
> the
> view I gave above.  I should clarify that I don't think it applies to
> *new code* in the derivative work.

Ah, that's a critical distinction.  I would now agree with your  
statement with regard to *new code* added to BSD-licensed software;  
that does not need to be under the BSDL.

>> The BSD license is a simple, permissive license which allows you  
>> to add
>> your own software or make changes, and license the derivative work
>> formed thereby under *both* the BSD license and your proprietary
>> license--
>
> So this means that for instance the WinNT TCP stack is all under  
> BSD (or
> at least the parts derived from BSD code)?

The unmodified portions of the Windows NT TCP stack which came from  
BSD were and are under the BSD license.  The combination of that  
original software and Microsoft's changes are distributed under  
Microsoft's proprietary EULA, but that EULA still lists the terms of  
the original BSD license, including some attribution requirements in  
the case of the "old" form of the BSDL.

Search most of the way down for "Acknowledgements" in:

    http://support.microsoft.com/kb/306819

> How is this different from the GPL, which also allows new code (in  
> a distributed derivative work)
> to be dual licensed under the GPL and a proprietary license?  Is the
> only difference source availability?

That's an interesting question.  The main differences I see are that  
the GPL requires source code availability and places requirements  
upon the distribution & licensing of all subsequent derivative works.

>>> This is not a question of whether you can change the terms of  
>>> existing
>>> code.  It is a question of the terms for derivative works, or the
>>> question of copyleft.  Critically, the BSD and GPL give different
>>> answers to this answer.  The BSD license allows derivative works  
>>> to have
>>> any license (as long as the BSD is preserved for the original code).
>>
>> That's right.
>
> But we disagree on whether new code in derivative works must also be
> under BSD.  I think it need not.

We're actually in agreement here; see above.  :-)

[ ... ]
>>> Seems to you.  It depends on whether shared library linking  
>>> creates a
>>> derivative work.  This is a matter of opinion and interpretation  
>>> thus
>>> far.
>>
>> I am not aware of any court decision which has indicated that dynamic
>> linking produces a derivative work.
>
> I'm not well versed in case law; you're probably right.  However, I
> don't think there has been a decision the other way either.  In any
> case, many (including some experts) do assert this.

I wonder if you might name these experts and point to their reasoning  
for closer evaluation?

For what it's worth, I've served as an expert witness in a software  
copyright infringement case [1] and have performed the "abstraction- 
filtration-comparison" testing to identify copyrightable program code  
required by the Computer Associates v. Altai decision.  This doesn't  
make me even slightly qualified to hold or provide legal opinions,  
BTW, but the Honorable Richard Conway Casey, U.S.D.J. was willing to  
accept my opinions with regard to computer software in his court.   
YMMV.  :-)

>>>> which will dynamically link libreadline.so (if available), or run
>>>> without it, if libreadline.so is not available.  Both Perl and  
>>>> Python do this,
>>>> for example.  Perl is dual-licensed under the GPL, but Python is  
>>>> not-- nor does it
>>>> need to be.
>>>
>>> Again, this still may create a derivative work, since program (or  
>>> the
>>> part that can use readline) is written to so tightly depend on  
>>> readline.
>>
>> Please re-read what I said, especially the part "or run without it".
>
> That's why I said "the part that can use readline)".  This code may  
> be a
> derivative work of readline, which would mean the whole program was.

Well, that's simply not how the analysis for copyright infringement  
works.

The filtration test requires one to analyze the program modules via a  
flowchart, and decide whether each distinct module or section "shows  
only an idea" (if yes, the material is not copyrightable, but might  
be patentable), or is an expression of an idea.  If the latter, the  
analysis requires consideration of whether the expression is (a)  
dictated by efficiency, (b) dictated by external factors  
(specifically interfaces, APIs), or (c) whether the expression is  
taken from the public domain.  Unless the answer to (a)-(c) are all  
no, and it does not represent a "protected combination", and it  
constitutes "enough copying to be a wrongful taking", it is  
considered "lawful copying" and not "copyright infringement".

Notice (b) & (c) in particular; publicly published APIs generally  
cannot qualify or be used as grounds for software copyright  
infringement...  [2]  ( IANAL, TINLA. )

>> If your position is correct, would you care to explain how Cygwin
>> redistributes GPL-licensed software compiled for Windows without  
>> running
>> afoul of the GPL-immiscibility of the Microsoft EULAs?
>
> I think the EULAs allow derivatives to be distributed under any terms,
> as long as the DLLs themselves are not distributed.

Absolutely not; this isn't a matter where you have to guess, go to:

   http://www.microsoft.com/about/legal/useterms/default.aspx

...and choose your favorite version of Visual Studio.  One version of  
the EULA states:

"2.4 Redistributable Code-Visual C++: Microsoft Foundation Classes  
(MFC), Active Template Libraries (ATL), and C runtimes (CRTs). If  
this EULA accompanies Visual C++, then in addition to the rights  
granted in Section 1, Microsoft grants you a license to use and  
modify the source code version of those portions of the Software that  
are identified as MFC, ATL, or CRTs (collectively, the "VC  
Redistributables"), for the sole purposes of designing, developing,  
and testing your software product(s). Provided you comply with  
Section 3.1..."

...and section 3.1(b) says:

"3.1 [ ... ]
(b) If you use the Redistributables, then in addition to your  
compliance with the applicable distribution requirements described  
for the Redistributables, the following also applies. Your license  
rights to the Redistributables are conditioned upon your not (i)  
creating derivative works of the Redistributables in any manner that  
would cause the Redistributables in whole or in part to become  
subject to any of the terms of an Excluded License; or (ii)  
distributing the Redistributables (or derivative works thereof) in  
any manner that would cause the Redistributables to become subject to  
any of the terms of an Excluded License. An "Excluded License" is any  
license that requires as a condition of use, modification and/or  
distribution of software subject to the Excluded License, that such  
software or other software combined and/or distributed with such  
software be (x) disclosed or distributed in source code form; (y)  
licensed for the purpose of making derivative works; or (z)  
redistributable at no charge."

You can't mix this EULA with the GPL under any circumstances,  
including the exception mentioned in GPL #3.

>> Is every program that runs under Windows a derivative of Microsoft's
>> software?  If the same exact program source code also runs on  
>> MacOS X,
>> or Linux, or FreeBSD, does this same program somehow become a  
>> derivative
>> work of MacOS X, Linux, FreeBSD, etc-- all at the same time?  Such a
>> position seems absurd....
>
> If the library is so simple that the API is shared among all these
> systems, it would probably not result in a derivative work.  Of  
> course,
> this is a gray area, and we again must await legal decisions.

It doesn't have to be a library, simple or otherwise: any program  
written against only the ANSI-C/POSIX 1003.x APIs is portable to a  
very wide of systems.  Such programs are not derivative works of any  
specific operating system.

-- 
-Chuck

[1]: UNITED STATES DISTRICT COURT/SOUTHERN DISTRICT OF NEW YORK/Civil  
Action No.: 02 CV 354x (RCC)

[2]: The exact text of the decision reads:

"Professor Nimmer points out that "in many instances it is virtually  
impossible to write a program to perform particular functions in a  
specific computing environment without employing standard  
techniques." 3 Nimmer s 13.03[F][3], at 13-65. This is a result of  
the fact that a programmer's freedom of design choice is often  
circumscribed by extrinsic considerations such as (1) the mechanical  
specifications of the computer on which a particular program is  
intended to run; (2) compatibility requirements of other programs  
with which a program is designed to operate in conjunction; (3)  
computer manufacturers' design standards; (4) demands of the industry  
being serviced; and (5) widely accepted programming practices within  
the computer industry. Id. at 13-66-71."