I'm good with that. I kept running into that scenario. Discussions about GPL but not LGPL.
On Thu, Apr 25, 2019 at 3:34 PM Smith, McCoy <[email protected]> wrote: > Here’s what FSF says about incompatibility: > https://www.gnu.org/licenses/license-list.html#apache2 > > It discusses GPLv3 (compatible) & GPLv2 (incompatible) but not LGPL. > > FWIW John Sullivan is looking to update the FSF FAQ and this is issue he > might want to write a new FAQ on. Do you mind if I share this thread with > him? > > > > > > > > *From:* License-discuss [mailto: > [email protected]] *On Behalf Of *Bruce Perens > via License-discuss > *Sent:* Thursday, April 25, 2019 1:25 PM > *To:* Bryan Christ <[email protected]> > *Cc:* Bruce Perens <[email protected]>; > [email protected] > *Subject:* Re: [License-discuss] Question about LGPL 2.1 and APL 2.0 > Compatibility > > > > Well, obviously the Apache license permits these things, so no concern > regarding your question. > > > > A proprietary license that entirely prohibited modification to the extent > of preventing re-linking with a modified LGPL library, or that prevented > the reverse-engineering necessary to debug that modification, would not be > compatible with LGPL 2.1 . > > > > On Thu, Apr 25, 2019 at 1:22 PM Bryan Christ <[email protected]> > wrote: > > Sorry for being dense here, but can you explain this a bit more? > > > > And I didn't completely state all of the requirements of LGPL 2.1 on the > non-LGPL piece: *the terms *[must]* permit modification of the work for > the customer's own use and reverse engineering for debugging such > modifications.* > > > > On Thu, Apr 25, 2019 at 2:42 PM Bruce Perens <[email protected]> wrote: > > It's definitely relevant between APL and *GPL*, because GPL places > requirements that the terms of the *entire* work do not include > restrictions beyond those in the GPL. LGPL doesn't say that. > > > > And I didn't completely state all of the requirements of LGPL 2.1 on the > non-LGPL piece: *the terms *[must]* permit modification of the work for > the customer's own use and reverse engineering for debugging such > modifications.* > > > > On Thu, Apr 25, 2019 at 12:29 PM Bryan Christ <[email protected]> > wrote: > > I came across a discussion about a patent clause contention between APL > 2.0 and LGPL 2.1 and wasn't sure how/if that was relevant. > > > > On Thu, Apr 25, 2019 at 2:26 PM Bruce Perens via License-discuss < > [email protected]> wrote: > > Yes to both. For the same reasons you could link both to proprietary > software. Neither license applies terms to works they are combined with, > except for lgpl requiring that it is possible to upgrade or modify the lgpl > software and for the combination to be capable of being relinked. Was there > any particular reason that you thought this might not be possible? > > > > Thanks > > > > Bruce > > > > On Thu, Apr 25, 2019, 11:04 Bryan Christ <[email protected]> wrote: > > I am the author of a library that is licensed under the LGPL 2.1. It's > very clear that a closed source work can dynamically link to the library. > That's easy to understand. There are 2 other scenarios however that I am > unclear about: > > > > 1. Can a LGPL 2.1 dynamically link to an APL 2.0 library or binary? > > 2. Can an APL 2.0 binary dynamically link to a LGPL 2.1 library? > > > > I did a lot of searching on the web first and couldn't find anything > covering this. > > > > Thanks in advance to whoever replies. > > > > -- > > Bryan > <>< > > _______________________________________________ > License-discuss mailing list > [email protected] > > http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org > > _______________________________________________ > License-discuss mailing list > [email protected] > > http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org > > > > > -- > > Bryan > <>< > > > > > -- > > Bryan > <>< > > -- Bryan <><
_______________________________________________ License-discuss mailing list [email protected] http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
