When to evaluate dual licenses (was: license categories, was: I'm not supposed to use the ECL v2?)

[Chuck Swiger]

On Dec 3, 2007, at 11:40 AM, Chris Travers wrote:
> On Dec 3, 2007 11:19 AM, Chuck Swiger <chuck at codefab.com> wrote:
>> If Postgres also works without GNU readline, or if it also works  
>> using
>> the BSD-licensed version of libreadline, then it seems clear enough
>> that Postgres by itself is not a derivative work of GNU readline.
>> However, a precompiled binary which statically links in GNU readline
>> clearly would be.
>
> It does but not pleasantly.  Nobody in their right mind would run it  
> that way given a choice.

Well, there are also people who believe that nobody in their right  
minds should be making interactive changes to a production database--  
any changes should be done via external SQL scripts which can be kept  
in CVS/SVN/etc and tested in some kind of QA or test environment  
before being run against production.  :-)

>> The same would apply to a proprietary closed-source program-- if it
>> ships as a binary which statically links in GNU readline, than they
>> need to honor the GPL and release their sources.  The interesting  
>> case
>> is what happens if a proprietary binary works fine as is, but is
>> willing to dynamically load libreadline if available.  :-)
>
> This is not the FSF's view (they claim that even optional use of  
> Readline means that the program falls under the requirements of the  
> GPL).

Indeed, for example see:

   http://www.gnu.org/licenses/why-not-lgpl.html

...however, this fails to consider the actual text of GPL(v2) clause  
#2, part of which reads:

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

If you distribute a binary which runs just fine by itself as a  
separate work, but which might optionally use a GPL'ed work like GNU  
readline via dynamic linking, then GPL clause 2 says that the terms of  
the GPL do not apply to that binary.

> If the license is compatible, though (as it is in PostgreSQL's case)  
> then there isn't a problem.  Note that this probably means you can  
> use BSD-licensed bridges to proprietary code with no problems (you  
> just treat it as GPL + linking exceptions).  This is the issue-- if  
> the FSF pushes the issue, then they suggest that linking exceptions  
> cannot be added to works which use their libraries.


We've discussed this particular issue before in some detail in a  
thread here:

   http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:12232:200701:eekjfkiiplhjdkoabfid

Quoting myself:

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

Regards,
-- 
-Chuck