Dispelling BSD License Misconceptions (fwd)

[Matthew Flaschen]

Chuck Swiger wrote:
> 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.

Yes, but the latter are the exception rather than the rule.  I also
don't think it is the intention of most proprietary software developers
to allow such flexibility; rather convenience dictates.

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

Yes, I use Cygwin, but that's quite separate from the question of
Windows' TCP stack.

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

Yes, glad we cleared that up.  I think it certainly still applies to the
original BSD code in the derivative work.

> 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

That was an interesting page.  I've never seen such a long list of
BSD-like licenses for Microsoft software.  I especially like the
introductory comment (not required by the license) like "Because
Microsoft has included the Hewlett-Packard Company software in this
product, Microsoft is required to include the following text that
accompanied such software:"  They're almost apologizing for including an
open source license for part of their product.

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

Yes.  The GPL does require new code in a distributed derivative work be
licensed under the GPL.  That's the critical distinction (along with
mandatory source availability).  My question was based on my
misunderstanding of your interpretation of BSD.

>> 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.  :-)

Right.

> 
> [ ... ]
>>>> 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?

Well, Eben Moglen comes to mind.  He said
(http://interviews.slashdot.org/interviews/03/02/20/1544245.shtml?tid=117&tid=123):

"The language or programming paradigm in use doesn't determine the rules
of compliance, nor does whether the GPL'd code has been modified. The
situation is no different than the one where your code depends on static
or dynamic linking of a GPL'd library, say GNU readline. Your code, in
order to operate, must be combined with the GPL'd code, forming a new
combined work, which under GPL section 2(b) must be distributed under
the terms of the GPL and only the GPL."

in response to a question about using GPLed JARs.  It's clear he
believes dynamic linking of GPL software (e.g. readline) creates a
derivative work that must be licensed under the GPL if distributed.

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

That's quite interesting.  Depending on the interpretation of b. if
source file A is coded using library B, then they are statically linked
together, source file A might not be a derivative work of B if B is
considered an external factor.  The binary probably still would be, though.

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

Why not?  I think this exception ensures the DLLs wouldn't fall under
the GPL; thus neither i or ii should be violated.

Matthew Flaschen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20070117/e25ff376/attachment.sig>