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

[Greg Hellings]

More specifically is the GPL FAQ page, which states the matter very succinctly.

http://www.gnu.org/copyleft/gpl-faq.html#IfLibraryIsGPL

Yes. The application "has to be under the GPL or a GPL-compatible license".

--Greg

On Sun, Aug 12, 2012 at 4:46 PM, Greg Hellings <greg.hellings at gmail.com> wrote:
> 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