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 Sat, 10 Dec 2016 10:54:39 GMT
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.
>> org/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