Dispelling BSD License Misconceptions (fwd)

[Chuck Swiger]

On Jan 17, 2007, at 11:32 AM, Matthew Flaschen wrote:
>> One would hope that
>> having source code available under an OSI-approved open source  
>> license
>> would have some meaning at least for the people on the OSI mailing  
>> lists.
>
> 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

...?

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

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

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

>> I would agree that static linking forms a derivative work for exactly
>> the reason you've mentioned; however, if you'll notice, I did not
>> mention static linking in the list above.  This omission was quite
>> deliberate.
>
> 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.

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

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 long as you adhere to the terms of the BSD license by  
preserving the statements and original disclaimer in source or binary  
forms.

>>> "But when you distribute the same sections as part of a whole  
>>> which is a
>>> work based on the Program, the distribution of the whole must be  
>>> on the
>>> terms of this License, whose permissions for other licensees  
>>> extend to
>>> the entire whole, and thus to each and every part regardless of who
>>> wrote it."
>>
>> Of course.  And if one of the other parts is under license terms  
>> which
>> are not GPL-miscible, then the derived work cannot be  
>> redistributed at all.
>>
>> As far as I can tell, *none* of the OSI-approved licenses grant
>> redistributors or people modifying the code the right to change the
>> original license terms.
>
> 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.

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

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.

[ ... ]
>>> Our position on the use of Readline through a shared-library linking
>>> mechanism is that there is no legal difference between shared- 
>>> library
>>> linking and static linking--either kind of linking combines various
>>> modules into a single larger work.  The conditions for using  
>>> Readline
>>> in a larger work are stated in section 3 of the GNU GPL."
>>>
>>> Obviously, this is interpretation.
>>
>> Yes, and that interpretation seems to contradict both the actual
>> language and the intent of GPL clause 2 quoted 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.

>> Specifically, it's entirely possible to write software which can be
>> distributed without including any GPL'ed code
>
> Derivative works don't have to include literal content from the
> original.  If I translate a poem, I may not include any words from the
> original, but it is still a derivate work.

Sure.  Likewise-- compiling program source code into a binary may not  
include any literal content from the original sources (although it  
usually does), but the binary that results from compiling source code  
is commonly held to be a derivative work.

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

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?

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

>>> 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'd prefer to avoid debating opinions-- mine included-- in favor  
>> of facts (ie, things which are testable, repeatable,
>> refutable, and so forth).
>
> The problem is you keep confusing the two.

Probably not; I don't believe that my opinions are important either  
to other people or even to myself.

I find the prospect of trying to persuade or manipulate other people  
into believing something just because I might hold a particular  
position to be disturbing and repugnant.  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.

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.

However, it has not been my observation that people who refuse to  
acknowledge their intrinsic biases or admit the possibility of error  
are more likely to be factually correct.

-- 
-Chuck