www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: LEGAL-280 - Cat-X and Optional Modules
Date Wed, 14 Dec 2016 08:43:06 GMT
It would be grey territory indeed, because you wouldn't violate the GPL
license before distributing the result of compiling, as the resulting
binary then must either be GPL (as it "links" to the library), or you no
longer had the right to copy and use the GPL library.

Some older thoughts from FSF here:
https://www.gnu.org/licenses/lgpl-java.en.html


While obviously ASF can't define FSF policy and we don't require all
releases to maintain AL2->GPL3 license compatibility, I think we should
keep this in mind where that is important for downstream uptake, for
instance distribution within Debian or where a major tool is licensed as
GPL or LGPL.

That is, deviation from that compatibility (e.g. adding an incompatible
dependency) should be a conscious choice by each ASF projects' community,
rather than a "not our concern".



On 14 Dec 2016 3:00 am, "Henri Yandell" <bayard@apache.org> wrote:

> Would hate to discover there is case law in which using software is a
> derivative work :)
>
> And if calling an API is considered a derivative work, then the industry
> has bigger problems than any value gained by GPL having an argument in its
> favour.
>
> Note that in the below you are mixing Apache Software Foundation policy
> (whether or not to include LGPL licensed software in compliance with said
> license) with Free Software Foundation policy and/or informal advice (GPL
> compatibility - which extends to LGPL/AGPL). That the FSF advice on GPL
> compatibility has an issue with some of our third party licenses is not an
> issue for the production of the Apache licensed software as we, by policy,
> do not distribute GPL or LGPL software in a way in which said software
> would affect the licensing of our Apache licensed software.
>
> I'm wary of your indirection comment ('escape route' sounds optimistic),
> and would want to hear more to understand it better.
>
> Hen
>
> On Sat, Dec 10, 2016 at 2:54 AM, Stian Soiland-Reyes <stain@apache.org>
> wrote:
>
>> In Maven land, LGPL should be ok if it is <optional>, or in an
>> integration module that itself is truly optional or outside the normal
>> build; and that we don't bundle the LGPL binary in an ASF distro.
>>
>> The situation is different with GPL; GPL 2.1 without upgrade clause is
>> not compatible with AL2 (because we require patent indemnification), while
>> GPL 3 is compatible (it adds a similar clause), but using GPL would make
>> the whole work GPL3 licensed.
>>
>> (Some of our acceptable third-party licenses are however not compatible
>> with GPL. )
>>
>> Note that merely having code that calls GPL APIs can be seen as a
>> derivative work and therefore covered by GPL - basically if the GPL library
>> is needed during compile, then your code would effectively be
>> GPL3-licensed.
>>
>> (Would love to see case law here, technically you would not be in
>> violation of the license, that is breaching copyright law, before compiling
>> or distributing the result of the compilation. Code blind?)
>>
>> Escape route is through indirection, where the interface is under an AL2
>> and GPL3-compatible license. Merely using such an indirection does not
>> escape "optional" requirement ASF-policy-wise unless there is an
>> alternative, compatible implementation of such an interface. (e.g. OpenSSL
>> and GNU TLS)
>>
>>
>>
>> On 9 Dec 2016 2:18 pm, "John D. Ament" <johndament@apache.org> wrote:
>>
>>> And if the proposed project included a pom coordinate that brought in
>>> hibernate for the user, would that be an issue?
>>>
>>> John
>>>
>>> On Fri, Dec 9, 2016 at 9:04 AM Apache <ralph.goers@dslextreme.com>
>>> wrote:
>>>
>>>> If your code uses JPA only and has no hibernate extensions, then it
>>>> should compile and build without the need for Hibernate - except perhaps
>>>> for testing. If the user chooses to drop in Hibernate because it is an
>>>> implementation of JPA that would be fine.
>>>>
>>>> Ralph
>>>>
>>>> On Dec 4, 2016, at 6:06 PM, John D. Ament <johndament@apache.org>
>>>> wrote:
>>>>
>>>> So I'll point out one more thing around this.  Since Hibernate
>>>> implements JPA (EPL/CDDL licensed, last I checked) the core dependency is
>>>> on that.  The additional maven dependency is simply a bridge for a user who
>>>> has expected to use Hibernate to bring in this library and Hibernate
>>>> together.  There's no actual code in the module, just a test and
>>>> coordinates.
>>>>
>>>> John
>>>>
>>>> On Sun, Dec 4, 2016 at 8:02 PM Henri Yandell <bayard@apache.org> wrote:
>>>>
>>>> I don't see that that argument helps with Test#1. Section 5 defines
>>>> said not derivative as a "work that uses the Library". Section 6 then says
>>>> that:
>>>>
>>>> *"6.* As an exception to the Sections above, you may also combine or
>>>> link a "work that uses the Library" with the Library to produce a work
>>>> containing portions of the Library, and distribute that work under terms
of
>>>> your choice, provided that the terms permit modification of the work for
>>>> the customer's own use and reverse engineering for debugging such
>>>> modifications."
>>>>
>>>> So LGPL 2.1 would appear to put modification and reverse engineering
>>>> criteria on the Apache licensed code. This is why resolved.xml says "The
>>>> LGPL is ineligible primarily due to the restrictions it places on larger
>>>> works, violating the third license criterion. ".
>>>>
>>>> For Test#4 - the question should be "are there no reasonable
>>>> alternatives?" :) ie) We shouldn't have an optional dependency on GNU
>>>> Regexp if BSD Regexp exists. In this case you took it as 'are Apache
>>>> offering alternative integrations?'; which is an interesting, and also
>>>> valid, point. If we're providing said alternatives and giving the public
>>>> more choice, that seems like a good thing.
>>>>
>>>> For Test#2 - I think that sounds good. If a user is seeking integration
>>>> with an LGPL licensed library, they should not be surprised by the LGPL
>>>> licensing.
>>>>
>>>> So #1 would seem the primary issue here. Sadly this part of LGPL is
>>>> something we have spent many threads on without, I feel, any great
>>>> consensus to treat LGPL differently to GPL.
>>>>
>>>> Hen
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Dec 4, 2016 at 4:38 PM, John D. Ament <johndament@apache.org>
>>>> wrote:
>>>>
>>>> RE 3 and 4 - the answers are yes.
>>>> The product could (and does) provide similar modules for other more
>>>> reasonably licensed products (e.g. EclipseLink & Apache OpenJPA)
>>>>
>>>> RE #1 - The argument I've made with my legal is that the style of use
>>>> is not a "derivative" since there's no modifications to the source code,
>>>> one of the requirements to fall under the derivative section of the LGPL.
>>>>
>>>> RE #2 - I don't have a way to judge this.  If the module is called
>>>> "hibernate-integration" then would a user be surprised that includes a
>>>> dependency on hibernate for their convenience - probably not.
>>>>
>>>>
>>>> On Sun, Dec 4, 2016 at 7:06 PM Henri Yandell <bayard@apache.org> wrote:
>>>>
>>>> So applying my tests:
>>>>
>>>> 1) Does it pass the criteria?   Possibly not; LGPL 2.1 (assuming 2.1)
>>>> has a reverse engineering clause that could apply to the Apache product.
2)
>>>> Will users be surprised? Hard to judge this as the details aren't in the
>>>> issue.
>>>> 3) Can it be meaningfully separated? Again hard to judge without
>>>> details. Easy to remove a jar, but will rest of the product work with it
>>>> removed (presumably from your optional description).
>>>> 4) Are there alternatives? Could we develop an alternative with
>>>> moderate effort? To be answered.
>>>>
>>>> Hen
>>>>
>>>>
>>>> On Sun, Dec 4, 2016 at 7:29 AM, John D. Ament <johndament@apache.org>
>>>> wrote:
>>>>
>>>> Hi Henri,
>>>>
>>>> So the situation here is a little different than in 279.  In 279, this
>>>> is a pretty core module of the product wherein the developers had made
>>>> modifications to it and include it in their source code.
>>>>
>>>> In this case, its not embedded, no changes are made within the product
>>>> to the source code of the undesirably licensed product.
>>>>
>>>> John
>>>>
>>>>
>>>> On Sun, Dec 4, 2016 at 4:43 AM Henri Yandell <bayard@apache.org> wrote:
>>>>
>>>> In https://issues.apache.org/jira/browse/LEGAL-279 I tried to
>>>> define/draft a pattern to thinking about these. Not sure if it's useful for
>>>> you, but here's the summary for the undesirably licensed product X:
>>>>
>>>> * The first test is defined on resolved.xml. Does the licensing of
>>>> product X pass our Software License Criteria?
>>>>
>>>> * The second test for me on non-cat-A dependencies is a 'principle of
>>>> no surprise'. Would a user, looking to use our product A, be surprised by
>>>> the dependency on non-cat-A product X. If they've already agreed to the
>>>> license of product X, then they won't be surprised. For example discovering
>>>> that product A has a dependency on Windows, when one was looking for the
>>>> product-A-for-Windows install.
>>>>
>>>> * The third test is a 'degree of meaningful separation'. How easy is it
>>>> for a user getting our product A, with our optional product B (depending
on
>>>> X), to separate those two products while still leaving product A
>>>> meaningfully useful.
>>>>
>>>>
>>>> * The fourth test is lack of availability of a reasonable/valuable
>>>> alternative. Where we should take the long view on reasonable. For example
>>>> implementing our own 'spec' jars from the BCL'd APIs was reasonable given
>>>> the level of effort needed (moderately low) and level of value to the
>>>> public (high).
>>>>
>>>> All four of those would need to be a yes to feel comfortable relying on
>>>> product X.
>>>>
>>>> If not, then we have:
>>>>
>>>> * Lastly, an exception valve of 'this is reality folks'. If the only
>>>> option to run product A is dealing with product X, and there is significant
>>>> value to the public in producing product A, then consider whether this is
>>>> an exception. Should be rare for this to apply but always worth remembering
>>>> it's an option. Lots of conversation with PMC and legal-discuss@
>>>> expected.
>>>>
>>>> Hen
>>>>
>>>> On Sat, Dec 3, 2016 at 5:28 AM, John D. Ament <johndament@apache.org>
>>>> wrote:
>>>>
>>>> So maybe.. but hear me out for a minute.
>>>>
>>>> I'm assuming by Legal FAQ you're referring to the previously asked
>>>> questions page https://www.apache.org/legal/resolved
>>>>
>>>> In that page, LGPL is bundled into the same Cat-X as Amazon Software
>>>> License.  We recently established that it was OK to use Amazon Software
>>>> License.
>>>>
>>>> Second, in the case i have, the LPGL dependency is not included in the
>>>> product.  If you were to use maven, ivy, etc to download the convenience
>>>> binary dependency it would include its transitive dependencies as separate
>>>> downloads.  Its not packaged as part of the binary product.
>>>>
>>>> In addition, when I think of product in the realm of Apache, I'm
>>>> thinking of the source code release.  I'm not sure if there's another
>>>> definition we use.  There would be no LGPL source code in the product.
>>>>
>>>>
>>>> On Fri, Dec 2, 2016 at 9:01 AM Apache <ralph.goers@dslextreme.com>
>>>> wrote:
>>>>
>>>> This is answered on the legal FAQ.  The one point you are missing is:
>>>> will the majority of your users want to use the optional dependency? If
>>>> they do then it may not really be all that optional.
>>>>
>>>> Ralph
>>>>
>>>> On Nov 29, 2016, at 12:51 PM, John D. Ament <johndament@apache.org>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I raised this legal ticket https://issues.apache.o
>>>> rg/jira/browse/LEGAL-280 due to the outcome of a recent discussion
>>>> around the Amazon Software LIcense, which was deemed OK for optional
>>>> dependencies specifically designed for use within AWS.
>>>>
>>>> I'd like to know if this can be expanded to handle any Cat-X dependency
>>>> or if its something special about the ASL's field of use restriction that
>>>> allows it? for instance, if I have source code fully apache licensed that
>>>> compiles against a dynamically linked LGPL library, can that source code
be
>>>> distributed, and can I produce binaries that are non-inclusive of those
>>>> LGPL libraries as long as:
>>>>
>>>> - Its clear to the user they need to pull in the LGPL dependency
>>>> - Its an optional module - its adding something specifically around
>>>> that LGPL library's usage.
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>

Mime
View raw message