Dispelling BSD License Misconceptions (fwd)

[Chuck Swiger]

On Jan 16, 2007, at 7:08 PM, Matthew Flaschen wrote:
> Chuck Swiger wrote:
>> If they produce a modified version or they combine BSD-licensed code
>> with additional software they've written, the portions they wrote or
>> changed can be licensed under whatever terms that author wishes
>> (assuming for the sake of discussion that the changes are not so  
>> trivial
>> that they would not merit copyright protection), but the original
>> unmodified sources are still under the terms of the BSD license.
>
> Moreover, the portions of their code that were licensed under BSD are
> still under BSD...

I agree up to here...

> ...(though this usually doesn't mean much).

...but I am not quite sure what you meant by this.  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.

>> There are some people who feel that software licenses somehow
>> automatically apply their terms to any and all other software used in
>> conjunction with the original software in question (ie, as part of a
>> compilation, or via dynamic linking, or via pipelines, RPC, or other
>> form of network communication).
>
> There are many quite distinct conjunctive relationships, which you've
> lumped together.  Some forms of conjunction (such as static linking)
> clearly create a derivative work, because the original code is present
> in the executable.  In most other cases, it is controversial.

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.

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.

>> A canonical example is when people
>> claim that you can't dynamically link libreadline.so with software  
>> under
>> another license unless the other software is also under the GPL.
>> [ My canonical response to such claims is to have them re-read the
>> section of the GPL between clause 2c & 3. ]
>
> You make this sound like the end of discussion.

Actually, it is another discussion (and one we've already had  
before); and is also somewhat aside from Brian's original discussion  
about this Groklaw article on the BSD license.

> In fact, this is probably one of the most complex parts of the  
> GPL.  I urge you to reread the sentence stating:
>
> "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.  Nothing in the GPL gives one the right to  
change the license on other software, just as nothing in any other  
license gives one the right to change the license of GPLed code.  The  
author or copyright holder is free to relicense software, and might  
grant others permission to change the license or use the source code  
in a circumstance otherwise not permitted by the original license  
terms, but the right to do so must be explicitly granted.

And this is exactly what the GPL says in the portion of the paragraph  
just before what you've quoted above:

"These requirements apply to the modified work as a whole. If  
identifiable sections of that work are not derived from the Program,  
and can be reasonably considered independent and separate works in  
themselves, then this License, and its terms, do not apply to those  
sections when you distribute them as separate works."

[ ...followed by the section "But when..." Matthew quoted above... ]

"Thus, it is not the intent of this section to claim rights or  
contest your rights to work written entirely by you; rather, the  
intent is to exercise the right to control the distribution of  
derivative or collective works based on the Program."

"In addition, mere aggregation of another work not based on the  
Program with the Program (or with a work based on the Program) on a  
volume of a storage or distribution medium does not bring the other  
work under the scope of this License."

> As far as Readline specifically, A USAGE file says:
>
> "I think Allbery's suggestion is a good one.  So please add this text
> in a suitable place.  Please don't put it in the GPL itself; that
> should be the same as the GPL everywhere else.  Putting it in the
> README and/or the documentation would be a good idea.
>
> ======================================================================
> 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.

Specifically, it's entirely possible to write software which can be  
distributed without including any GPL'ed code, 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.

> Similarly, the FSF uses Readline as an example of a library they  
> leverage to convince people to release their programs under the GPL  
> (http://www.gnu.org/licenses/why-not-lgpl.html).

Of course they do.  It's not surprising that the article you've  
referenced was written back in 1999 but makes no mention of the  
existence of a BSD-licensed readline library (written by Jaromir  
Dolecek for NetBSD in 1997), nor the libedit library written by  
Christos Zoulas for 4.4BSD back in 1992.  The earliest version of GNU  
readline that I can find (originally written by Brian Fox) dates to  
1994.

I've even seen people claim that the only reason why proprietary  
software running on Linux can avoid being "forcibly relicensed under  
the GPL" is because GNU libc is under the LGPL.  They seem to forget  
that the original standard C library was written by Kernighan and  
Richie back around 1971, some twenty years before Roland McGrath  
started writing GNU libc circa 1992.

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.

> 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.  I'd prefer to avoid debating opinions--  
mine included-- in favor of facts (ie, things which are testable,  
repeatable, refutable, and so forth).

-- 
-Chuck