[sword-devel] GPL restrictions (was Re: using a zText module)

[Greg Hellings]

On Sun, Aug 12, 2012 at 4:33 PM, Chris Little <chrislit at crosswire.org> wrote:
> On 08/12/2012 01:11 PM, Greg Hellings wrote:
>>
>> On Sun, Aug 12, 2012 at 2:55 PM, Chris Little <chrislit at crosswire.org>
>> wrote:
>>>
>>> I'm not sure I see the distinction. For GPLv2 software A to be used by or
>>> incorporated in some other software B, GPLv2 must be compatible with
>>> software B's license. The set of licenses that GPLv2 is compatible with
>>> consists of exactly and only GPLv2. (This is distinct from the set of
>>> licenses that are compatible with GPLv2, which includes GPLv2, BSD, and
>>> many
>>> others.) GPLv2 and GPLv3 are mutually incompatible.
>>
>>
>> I think you're understanding "compatible" more narrowly than it
>> actually means. Here is the quote from the email exchange with the
>> FSF, asking specifically about public domain:
>>
>>> The crucial words here are "or a GPL-compatible license".
>>> Public domain is compatible with the GPL.
>>> http://www.gnu.org/licenses/license-list.html#PublicDomain
>>>
>>> Therefore this is ok and the application code can be public domain,
>>> while the library is GPL.
>>
>>
>> You might not understand, but this is how the FSF explains it. An
>> application may be non-GPL, so long as its license is compatible with
>> the GPL. That is, the license has to be one which would permit the
>> application to utilize GPL libraries. Any of the licenses on the
>> compatability list are OK for the application.
>
>
> I would guess that the FSF's respondent either misunderstood the question
> that was posed, answered for the reverse (incorporating PD-licensed software
> into GPL-licensed software), or simply didn't know what he was talking
> about. Given the final sentence, I would lean towards the last option. I'm
> not sure what "or a GPL-compatible license" quotes from, as that is not a
> phrase present within GPLv2.
>
> The FSF's staff aren't the judicial branch or anything, so they don't get to
> re-interpret what was meant by the GPL after the fact. The GPL licenses have
> enumerated rights & requirements, those sets of rights & requirements are
> not identical for the two licenses, and both licenses prohibit any addition
> or removal of rights from the licensed work or its derivatives---hence they
> are inherently mutually incompatible licenses.
>
> The page cited by FSF's respondent actually explicitly states that GPLv2 is
> not GPLv3-compatible and GPLv3 is not GPLv2-compatible (unless it's the
> "version 2 or later" version of licensing). So, in addition to the links I
> posted previously, there's the FSF's explicit statement on GPL inter-version
> compatibility, which is the specific case in question.
>
> Crucially, license compatibility is directional. PD and BSD are
> GPL-compatible, which means PD and BSD software may be incorporated into GPL
> software. GPL is not PD- or BSD-compatible, and that would be requisite to
> incorporation of GPL software into PD or BSD software.



You can argue against it all you want, but the man's statement in the
email is very explicit. "...the application code can be public domain,
while the library is GPL." He isn't equivocating and he doesn't sound
confused to me. This is the response from licensing at fsf.org.

Neither you nor I are lawyers. I don't know if the individual
responding on behalf of the FSF is a lawyer or not. But until someone
comes up with a more clear and straightforward statement from either a
lawyer or the FSF, then those of us considering licensing for
applications or wrappers should bow to the very clear statement from
the FSF that any GPLv2-compatible license is permissible for something
that links with SWORD.

GPLv3 is not compatible with v2. Therefore, a SWORD application can't
be GPLv3. But it can be PD, BSD, Apache, etc.

--Greg

>
> It's permissible to release code that makes use of the SWORD API or other
> GPLv2 software available under another license _in addition to_ GPLv2, but
> that code must also be GPLv2-licensed and any binaries must be licensed
> GPLv2-only. (Section 2b and the paragraph following section 2c of GPLv2 make
> this explicit.)
>
> If it were permissible to license software that links against GPLv2 software
> using any 'GPL-compatible' license, then one could trivially write a library
> that simply replicates the SWORD API and passes calls on to the SWORD
> library itself. Then one could have a BSD-, GPLv3-, LGPL-, or PD-licensed
> SWORD API via this intermediary, and by the same method, anyone could switch
> the license of any GPLv2 or v3 library to some other 'GPL-compatible'
> license. I hope it's clear that that is not the case. The whole concept of
> license virality would fall apart under this assumption, and literally any
> piece of GPL software could be converted to public domain via this means.
> (Conversely, it is permissible to write such libraries that replicate BSD-,
> LGPL-, or PD-licensed APIs and license those replicating libraries as GPL,
> though obviously it makes more sense to simply re-license under the more
> restrictive GPL if that's your aim. We effectively re-license any time we
> link SWORD against BSD/MIT libraries.)
>
>
>> A modification of SWORD itself (including of the bindings included
>> with the library) would need GPLv2 licensing to be released. THAT is
>> the restrictiveness of GPLv2. But as long as I'm just binding or
>> linking against the library, I don't have to be limited to GPLv2.
>> GPLv2 compatible is OK.
>
>
> What you're describing is roughly LGPL. Actual LGPL doesn't have any
> restriction on GPL-compatibility of software employing the LGPL library, but
> that's the nearest thing to what you describe.
>
> --Chris
>
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page