Smith, McCoy dixit:
>Here’s what FSF says about incompatibility:
>https://www.gnu.org/licenses/license-list.html#apache2
Aaaah, so “APL” means “Apache”… d’oh.
>It discusses GPLv3 (compatible) & GPLv2 (incompatible) but not LGPL.
There is nothing to discuss there. Both Apache and LGPL only
app
As a matter of project policy, the Apache Project does not accept as an
official part of software they distribute any software under licenses that
place terms upon the larger work. In this case, the terms regarding
modification and reverse-engineering we just discussed. However, the Apache
license
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 wrote:
> Here’s what FSF says about incompatibility:
> https://www.gnu.org/licenses/license-list.html#apache2
>
> It discusses GPLv3 (compatible) & GPLv2 (inc
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 sha
This was the other thing that gave me pause. It expressly says that the
LGPL 2.1 is not compatible.
http://www.apache.org/legal/resolved.html
On Thu, Apr 25, 2019 at 3:25 PM Bruce Perens wrote:
> Well, obviously the Apache license permits these things, so no concern
> regarding your question.
Ah. Okay. Makes sense. Thanks for the clarification.
On Thu, Apr 25, 2019 at 3:25 PM Bruce Perens wrote:
> 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 preve
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 modific
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
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
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 <
license-discuss@lists.opensource.org> wrote:
> Yes to both. For the same reasons you could link bot
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 p
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 bi
12 matches
Mail list logo
