www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@apache.org>
Subject Re: LEGAL-280 - Cat-X and Optional Modules
Date Wed, 14 Dec 2016 17:07:22 GMT
+1 to your path John and Stian's comments.

On Wed, Dec 14, 2016 at 12:23 AM, Stian Soiland-Reyes <stain@apache.org>
wrote:

> Right, that is a perfect example of how to do it cleanly when integration
> code is needed. It should be obvious that a foo-hibernate integration would
> depend on hibernate using Maven artifacts, and you have multiple
> implementations of foo-api.
>
> I don't think you would need to use <scope>optional within the
> foo-hibernate module, as long as your other modules can think of
> foo-hibernate itself as optional (as you describe).
>
> (Trickier territory: releasing foo-hibernate as it's own ASF source code
> product)
>
> On 14 Dec 2016 3:30 am, "John D. Ament" <johndament@apache.org> wrote:
>
>> So just to provide a full summary of what I think I'm seeing, and what I
>> think I'm saying.
>>
>> The proposed project (because this is all a precursor to proposing a new
>> podling) provides a JPA integration module.  A compile time dependency
>> exists between the project and the JPA API (which ships as EPL).  The
>> project provides three distinct modules for the JPA integration which serve
>> two purposes:
>>
>> - Execute compatibility tests between the module and a JPA implementation
>> - Provide maven coordinates to a dependency on the JPA integration module
>> and the implementation in play, if a user chooses to use the version we've
>> tested with.
>>
>> For full reference, the three JPA implementations tested are Apache
>> OpenJPA, EclipseLink, and Hibernate.  There is no concept of a default
>> implementation, e.g. you need to add it explicitly to your project if you
>> want JPA support.  You can also not use our module - e.g. just bring in the
>> jpa integration and the appropriate JPA implementation for your project.
>>
>> Since the hibernate module is just coordinates, there are no direct
>> invocations of any LGPL libraries.  We're not even getting into the API
>> calls side of it, since that library is EPL.  It has the ability to invoke
>> an SPI provided by Hibernate by the EPL library, satisfying its contract.
>>
>> I believe what I'm hearing at this point is that this should be OK, and
>> in a worst case just don't ship the hibernate convenience maven coordinate.
>>
>> John
>>
>> On Tue, Dec 13, 2016 at 10:16 PM John D. Ament <johndament@apache.org>
>> wrote:
>>
>>> Agreed, and assuming that JPA support is optional by default, and we
>>> provide three distinct modules where a user has to pick one, that would all
>>> be good?
>>>
>>> John
>>>
>>>
>>> On Tue, Dec 13, 2016 at 10:02 PM Henri Yandell <bayard@apache.org>
>>> wrote:
>>>
>>>
>>> I think that would be a surprise for the user (my second test :) ).
>>>
>>> Our product should, by default, use unsurprising licensing. If a user
>>> can switch from 'PermissiveLicensedJPA' to Hibernate, that's great, but we
>>> should not be selecting it by default.
>>>
>>> Hen
>>>
>>>
>>> On Fri, Dec 9, 2016 at 6:18 AM, 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