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 Wed, 14 Dec 2016 03:16:42 GMT
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