Dispelling BSD License Misconceptions (fwd)
chuck at codefab.com
Thu Jan 18 02:05:42 UTC 2007
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,
>> 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
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:
>> ...and I know that a number of changes and improvements Apple have
>> 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
> has separately released all the BSD code they're using (but I may be
Perhaps you might ask Ernie Prabhakar; I cannot answer that question
> However, Microsoft for instance has been less cooperative
> still. Early versions of Microsoft used the BSD stack extensively
> 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
> 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
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
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
>>> I misread "as part of a compilation" as the vague and totally
>>> "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
>>> 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
> read BSD, I interpreted it your way, but have since been steered to
> 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
> 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:
> 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
>>> 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
>> 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  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.
>>>> 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
>>> part that can use readline) is written to so tightly depend on
>> 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
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...  ( IANAL, TINLA. )
>> If your position is correct, would you care to explain how Cygwin
>> redistributes GPL-licensed software compiled for Windows without
>> 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:
...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
...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
>> 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
> 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.
: UNITED STATES DISTRICT COURT/SOUTHERN DISTRICT OF NEW YORK/Civil
Action No.: 02 CV 354x (RCC)
: 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], 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."
More information about the License-discuss