For Approval: GPLv3

[Chris Travers]

>>From GPLv3:

>"For example, Corresponding Source includes interface definition files
>associated with source files for the work, and the source code for
>shared libraries and dynamically linked subprograms that the work is
>specifically designed to require, such as by intimate data communication
>or control flow between those subprograms and other parts of the work."

>It is this type of restrictions that are the source of the compatibility
>problems. The MPL cannot be converted to CDDL, or vice versa, but that
>is not much of a problem since files with those licenses can be linked
>together. If I license my libraries under the CDDL, then it is the GPL
>that prevents those libraries from being used in GPL programs, not the
>CDDL. (And those libraries might be considered independent works,
>depending on the jurisdiction.)

IANAL, and this seems sort of off-topic anyway, but anyway....

I was just reading this again and noticed something I had missed the first time.
It does indeed look like you could not have a GPL program *require* (language of 
the GPL v3) a CDDL library.  However, if the CDDL library is used as an *optional* 
add-on through an appropriately licensed bridge (say LGPL) which is also distributed
separately, it would seem to be no more of a violation than, say, distributing Linux 
with ndiswrapper would be, (a similar case probably exists with the nVidia drivers which
is why, despite harsh critism by the FSF, they have not yet suggested that nVidia's 
closed source kernel drivers are in fact a license violation.

It becomes a harder question when you ask whether distributing Linux with ndiswrapper 
*and* appropriate Windows NDIS drivers constitutes a violation based on the work as a 
whole now including those closed source drivers.  In short, I wonder if distributors
would be liable where developers might not be and if there are cases where mere 
aggregation can actually create a new covered work, extending the license to other 
components listed on the same media.

In short, I think the question of linking GPL code with non-GPL-compatible code is more
complex than the FSF wants to publically admit and center around what is actually 
included in the "work as a whole" as well as what is actually "derivative."  The above
examples would be areas where I would argue the proprietary code is neither derivative
nor part of the same "work as a whole" and is hence can be linked after distribution.
Again, IANAL.....

Now, this is not a *total* thread hijack as it actually comes back to the question of 
GPL v3 approval.

Possible Problem:
Basically, there exists a possible concern that a GPL v3 covered work could exist in a 
synthetic (and hence contageous) form which might extend to otherwise uncovered works
aggregated on distribution media.  Here is the case I am thinking of:

OS Kernel under GPL v3.
Proprietary driver originally written for Windows.
LGPL v3 bridge allowing Windows drivers to be loaded.

Ordinarily, it would be hard to argue that the proprietary Windows drivers were part of
the same work as a whole as the kernel, but if they were distributed together on the
same media, an argument could be made that they are.  In the GPL v3, it seems to me that
the case is harder to make, but might be possible if a hardware/software bundle required
those drivers.

Analysis:
The GPL v2 is actually worse in this regard than the GPL v3, and it has long been deemed
an OSD-compatible license.  It seems to me therefore that if the GPL v2 is recognized, 
that:

1)  This specific problem should be seen as outside of the scope of the OSD and
2)  The FSF deserves some credit for addressing this problem more clearly in this license 
by limiting the requirements to *requirements* as opposed to all libraries which may or 
may not be indirectly linked.  This also helps to address issues of "I link to library x
and it *might* link to OpenSSL depending on compile-time options so what then?"

In short I do not think that this problem should prevent adoption of the GPL v3.  I have
other concerns however (over whether it is really technologically neutral and whether it
discriminates against fields of endeavor) which I have already posted.

Best Wishes,
Chris Travers

-------------- next part --------------
A non-text attachment was scrubbed...
Name: chris.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20070815/3dda0348/attachment.vcf>