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.helli...@gmail.com> wrote: > On Sun, Aug 12, 2012 at 4:33 PM, Chris Little <chris...@crosswire.org> wrote: >> On 08/12/2012 01:11 PM, Greg Hellings wrote: >>> >>> On Sun, Aug 12, 2012 at 2:55 PM, Chris Little <chris...@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 licens...@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@crosswire.org >> http://www.crosswire.org/mailman/listinfo/sword-devel >> Instructions to unsubscribe/change your settings at above page _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
