www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: LEGAL-280 - Cat-X and Optional Modules
Date Fri, 16 Dec 2016 02:22:29 GMT
I'm wondering if at this point would it be considered to update the
resolutions with this additional information, e.g. based on the situation
described, here's when its OK to do this.

On Wed, Dec 14, 2016 at 12:07 PM Henri Yandell <bayard@apache.org> wrote:

> +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.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