Dispelling BSD License Misconceptions (fwd)

Wed Jan 17 23:45:13 UTC 2007

Chuck Swiger wrote:
>> Of course this means a lot to me (I would strongly prefer that the
>> license also be FSF-approved).
> 
> You ought to be aware that the "new" BSD license appears in the
> FSF-approved list of "GPL-compatible Free Software Licenses":
> 
>   http://www.fsf.org/licensing/licenses/index_html
> 
> ...?

I do know that.  I certainly didn't mean to imply BSD wasn't a free license.

>> What I meant here is that if BSD code is modified substantially with
>> proprietary changes, the BSD code usually can't be extracted from the
>> proprietary version.
> 
> This is true and represents the intended goal of the original author(s):
> people are welcome to use BSD-licensed code in proprietary software and
> only release binaries rather than being obligated to release their
> modified version of the source code as well.

I do know this.  It is a goal I disagree with, but I see their perspective.

>> Thus, the BSD license doesn't have any practical
>> meaning for users of the blend (why I don't like the BSD license and
>> avoid proprietary software derived from BSD code).
> 
> The BSD license (or the MIT/X11 license, or the Zlib & PNG licenses)
> have a very practical meaning for people who want to use some existing
> software when writing proprietary software.

I am aware of the practical benefits BSD provides to initial redistributors.

  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.

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

>>> However, that is slightly aside from the central point, which is that a
>>> license applies to the software under that license and to derivative
>>> works but *not* to other software which is completely independent and
>>> exists under other license terms.
>>
>> 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.

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

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

>> The GPL mandates that derivative works are licensed under the GPL in
>> their entirety.
> 
> No, not quite.  With regard to derivative works of GPL'ed software,
> "distribution of the whole must be on the terms of this License"; if you
> don't (re)distribute the combination then the other parts do not need to
> be licensed under the GPL or even under a GPL-miscible license.

Yes, I meant if a derivative work were redistributed.

> If you do wish to redistribute the combination, then you must follow the
> terms of both licenses, which in practice means that you can only do so
> if the other parts are licensed under a GPL-miscible license.  However,
> the other parts need not be under the GPL.

Agreed, many licenses (BSD-included) are GPL-miscible (GPL-compatible).

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

>>> 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.
> 
> The Python interpreter runs just fine without readline; however, if you
> like, you can type "import readline", and Python will attempt to
> dynamically load readline if available, which is handy for doing
> interactive debugging.
> 
>>> Just because a program calls printf() does not mean that it becomes a
>>> derivative work of GNU libc when dynamically linked on a Linux platform,
>>> any more than that same exact same program source code becomes a
>>> derivative work of the original C library on a BSD platform, of
>>> Microsoft's Visual-C++ DLLs when dynamically linked on Windows, and so
>>> forth for every platform that supports an ANSI-C library.
>>
>> I think Microsoft's EULA for these DLLs would offer a very different
>> interpretation of copyright law.  I think all of these licenses allow
>> derivative works, and this has blinded you to the fact that they could
>> restrict them.
> 
> 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.  In turn, I think
the GPL permits this through the operating system exception:

"the source code distributed need not include anything that is normally
distributed (in either source or binary form) with the major components
(compiler, kernel, and so on) of the operating system on which the
executable runs, unless that component itself accompanies the executable."

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

>>>> You're welcome to have a different opinion, but don't try to make it
>>>> seem indisputable or uncontroversial by spouting off sections of the
>>>> GPL
>>>
>>> Honi soit qui mal y pense.
>>
>> Translation?
> 
> French for "shame upon him who thinks evil of it".
> It's meant in the sense of Matthew 7:1-5...

I'm sorry.  I've been rather rigid and impatient through this whole
discussion.

> Because I am human, I know that I am
> fallible and imperfect, and I perceive things in a fashion that is
> intrinsically biased from genetic and cultural influences that cannot be
> completely removed.  Because I acknowledge these things, and start from
> the position that I'm at least as likely to be wrong as the people I
> might be talking with, I compensate for these limitations and biases as
> best as I can.

That's certainly a goal I can agree with.

> 
> Observation suggests that many people find their own opinions to be so
> overwhelmingly important that they simply refuse to acknowledge facts
> which contradict these opinions; observation also suggests that many
> people are also completely unwilling to acknowledge that they might make
> mistakes or be wrong.

I agree.  Hopefully, I am not being so blind.

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/73f733e0/attachment.sig>