www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de.INVALID>
Subject Re: LEGAL-280 - Cat-X and Optional Modules
Date Fri, 16 Dec 2016 07:09:03 GMT
Do you need JPA or Hibernate integration?

If it's just JPA, then you could have 2 profiles. 1 with Apache OpenJPA (as default), the
other (optional) with Hibernate (running on Jenkins).
Think that would be legally ok.

LieGrue,
strub

 
> Am 14.12.2016 um 04:16 schrieb John D. Ament <johndament@apache.org>:
> 
> 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 
>> 
>> 
>> 
>> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message