Re: LEGAL-280 - Cat-X and Optional Modules

[Apache <ra...@dslextreme.com>]

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 <jo...@apache.org> wrote:
> 
> Hi,
> 
> I raised this legal ticket https://issues.apache.org/jira/browse/LEGAL-280 <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 

Re: LEGAL-280 - Cat-X and Optional Modules

[Apache <ra...@dslextreme.com>]

One thing to note is that by Free Software Foundation’s definition you do not have to modify the code of something licensed under the LGPL to create a derivative work. You merely need to use it.  

Ralph

> On Dec 4, 2016, at 5:38 PM, John D. Ament <jo...@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 <ma...@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 <ma...@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 <ma...@apache.org>> wrote:
> In https://issues.apache.org/jira/browse/LEGAL-279 <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 <ma...@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 <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 <ma...@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 <ma...@apache.org>> wrote:
>> 
>> Hi,
>> 
>> I raised this legal ticket https://issues.apache.org/jira/browse/LEGAL-280 <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 
> 
> 
> 

Re: LEGAL-280 - Cat-X and Optional Modules

[Mark Struberg <st...@yahoo.de.INVALID>]

What I'm usually doing is to use geroinimo-jpa_2.0-spec etc as API and have 2 different maven profiles for the actual implementations.
The default profile could leverage OpenJPA (<activeByDefault>true). A second profile (<profile><id>hibernate..) could contain the LGPL dependency on Hibernate. 

What does this mean:  
.) we do *not* include Hibernate in any packaging
.) we do *not* link nor build against any LGPL licensed lib

But a user could build with the -Phibernate profile and then check if all things still work with Hibernate as well.

Ofc that only works if you don't need any Hibernate specific functionality.

Makes sense?
Afaiu it should legally work fine and technically as well.

LieGrue,
strub

> Am 16.12.2016 um 23:53 schrieb John D. Ament <jo...@apache.org>:
> 
> Mark,
> 
> I'm not sure what you mean by 2 profiles here.  There are two modules in question:
> - a jpa core module that provides JPA integration
> - a hibernate module that provides coordinates to bring in the relevant maven dependencies as well as execute tests.  This way a user is using the version we're saying works.
> 
> There are alternate modules for OpenJPA, EclipseLink.  But I don't understand what you mean by profiles here.
> 
> John
> 
> On Fri, Dec 16, 2016 at 2:09 AM Mark Struberg <st...@yahoo.de.invalid> wrote:
> 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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
> 


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

Re: LEGAL-280 - Cat-X and Optional Modules

["John D. Ament" <jo...@apache.org>]

Mark,

I'm not sure what you mean by 2 profiles here.  There are two modules in
question:
- a jpa core module that provides JPA integration
- a hibernate module that provides coordinates to bring in the relevant
maven dependencies as well as execute tests.  This way a user is using the
version we're saying works.

There are alternate modules for OpenJPA, EclipseLink.  But I don't
understand what you mean by profiles here.

John

On Fri, Dec 16, 2016 at 2:09 AM Mark Struberg <st...@yahoo.de.invalid>
wrote:

> 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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>
>

Re: LEGAL-280 - Cat-X and Optional Modules

[Mark Struberg <st...@yahoo.de.INVALID>]

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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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

Re: LEGAL-280 - Cat-X and Optional Modules

["John D. Ament" <jo...@apache.org>]

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 <ba...@apache.org> wrote:

> +1 to your path John and Stian's comments.
>
> On Wed, Dec 14, 2016 at 12:23 AM, Stian Soiland-Reyes <st...@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" <jo...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>
>
>

Re: LEGAL-280 - Cat-X and Optional Modules

[Henri Yandell <ba...@apache.org>]

+1 to your path John and Stian's comments.

On Wed, Dec 14, 2016 at 12:23 AM, Stian Soiland-Reyes <st...@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" <jo...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>

Re: LEGAL-280 - Cat-X and Optional Modules

[Stian Soiland-Reyes <st...@apache.org>]

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" <jo...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>>
>>
>>
>>
>>
>>
>>
>>

Re: LEGAL-280 - Cat-X and Optional Modules

["John D. Ament" <jo...@apache.org>]

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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>
>
>
>
>
>
>
>

Re: LEGAL-280 - Cat-X and Optional Modules

["John D. Ament" <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>
>
>
>
>
>
>
>

Re: LEGAL-280 - Cat-X and Optional Modules

[Henri Yandell <ba...@apache.org>]

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 <jo...@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 <ra...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>>
>>
>>
>>
>>
>>
>>

Re: LEGAL-280 - Cat-X and Optional Modules

[Henri Yandell <ba...@apache.org>]

Agreed.  I'm further back in the thought process - I'm thinking ASF policy
would step in with a 'no' before we had to worry about compatibility
issues. :)

Or rather, if compatibility is an issue, then the product in question
breaks criteria #3 (and possibly #2) of our Software License Criteria. Ergo
compatibility should never be an issue.

Hen

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

> It would be grey territory indeed, because you wouldn't violate the GPL
> license before distributing the result of compiling, as the resulting
> binary then must either be GPL (as it "links" to the library), or you no
> longer had the right to copy and use the GPL library.
>
> Some older thoughts from FSF here:
> https://www.gnu.org/licenses/lgpl-java.en.html
>
>
> While obviously ASF can't define FSF policy and we don't require all
> releases to maintain AL2->GPL3 license compatibility, I think we should
> keep this in mind where that is important for downstream uptake, for
> instance distribution within Debian or where a major tool is licensed as
> GPL or LGPL.
>
> That is, deviation from that compatibility (e.g. adding an incompatible
> dependency) should be a conscious choice by each ASF projects' community,
> rather than a "not our concern".
>
>
>
> On 14 Dec 2016 3:00 am, "Henri Yandell" <ba...@apache.org> wrote:
>
>> Would hate to discover there is case law in which using software is a
>> derivative work :)
>>
>> And if calling an API is considered a derivative work, then the industry
>> has bigger problems than any value gained by GPL having an argument in its
>> favour.
>>
>> Note that in the below you are mixing Apache Software Foundation policy
>> (whether or not to include LGPL licensed software in compliance with said
>> license) with Free Software Foundation policy and/or informal advice (GPL
>> compatibility - which extends to LGPL/AGPL). That the FSF advice on GPL
>> compatibility has an issue with some of our third party licenses is not an
>> issue for the production of the Apache licensed software as we, by policy,
>> do not distribute GPL or LGPL software in a way in which said software
>> would affect the licensing of our Apache licensed software.
>>
>> I'm wary of your indirection comment ('escape route' sounds optimistic),
>> and would want to hear more to understand it better.
>>
>> Hen
>>
>> On Sat, Dec 10, 2016 at 2:54 AM, Stian Soiland-Reyes <st...@apache.org>
>> wrote:
>>
>>> 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" <jo...@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 <ra...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>

Re: LEGAL-280 - Cat-X and Optional Modules

[Stian Soiland-Reyes <st...@apache.org>]

It would be grey territory indeed, because you wouldn't violate the GPL
license before distributing the result of compiling, as the resulting
binary then must either be GPL (as it "links" to the library), or you no
longer had the right to copy and use the GPL library.

Some older thoughts from FSF here:
https://www.gnu.org/licenses/lgpl-java.en.html


While obviously ASF can't define FSF policy and we don't require all
releases to maintain AL2->GPL3 license compatibility, I think we should
keep this in mind where that is important for downstream uptake, for
instance distribution within Debian or where a major tool is licensed as
GPL or LGPL.

That is, deviation from that compatibility (e.g. adding an incompatible
dependency) should be a conscious choice by each ASF projects' community,
rather than a "not our concern".



On 14 Dec 2016 3:00 am, "Henri Yandell" <ba...@apache.org> wrote:

> Would hate to discover there is case law in which using software is a
> derivative work :)
>
> And if calling an API is considered a derivative work, then the industry
> has bigger problems than any value gained by GPL having an argument in its
> favour.
>
> Note that in the below you are mixing Apache Software Foundation policy
> (whether or not to include LGPL licensed software in compliance with said
> license) with Free Software Foundation policy and/or informal advice (GPL
> compatibility - which extends to LGPL/AGPL). That the FSF advice on GPL
> compatibility has an issue with some of our third party licenses is not an
> issue for the production of the Apache licensed software as we, by policy,
> do not distribute GPL or LGPL software in a way in which said software
> would affect the licensing of our Apache licensed software.
>
> I'm wary of your indirection comment ('escape route' sounds optimistic),
> and would want to hear more to understand it better.
>
> Hen
>
> On Sat, Dec 10, 2016 at 2:54 AM, Stian Soiland-Reyes <st...@apache.org>
> wrote:
>
>> 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" <jo...@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 <ra...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>

Re: LEGAL-280 - Cat-X and Optional Modules

[Henri Yandell <ba...@apache.org>]

Would hate to discover there is case law in which using software is a
derivative work :)

And if calling an API is considered a derivative work, then the industry
has bigger problems than any value gained by GPL having an argument in its
favour.

Note that in the below you are mixing Apache Software Foundation policy
(whether or not to include LGPL licensed software in compliance with said
license) with Free Software Foundation policy and/or informal advice (GPL
compatibility - which extends to LGPL/AGPL). That the FSF advice on GPL
compatibility has an issue with some of our third party licenses is not an
issue for the production of the Apache licensed software as we, by policy,
do not distribute GPL or LGPL software in a way in which said software
would affect the licensing of our Apache licensed software.

I'm wary of your indirection comment ('escape route' sounds optimistic),
and would want to hear more to understand it better.

Hen

On Sat, Dec 10, 2016 at 2:54 AM, Stian Soiland-Reyes <st...@apache.org>
wrote:

> 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" <jo...@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 <ra...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>>>
>>>
>>>
>>>
>>>
>>>
>>>

Re: LEGAL-280 - Cat-X and Optional Modules

[Stian Soiland-Reyes <st...@apache.org>]

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" <jo...@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 <ra...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>>
>>
>>
>>
>>
>>
>>

Re: LEGAL-280 - Cat-X and Optional Modules

["John D. Ament" <jo...@apache.org>]

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 <ra...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>
>
>
>
>
>
>

Re: LEGAL-280 - Cat-X and Optional Modules

[Apache <ra...@dslextreme.com>]

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 <jo...@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 <ma...@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 <ma...@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 <ma...@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 <ma...@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 <ma...@apache.org>> wrote:
> In https://issues.apache.org/jira/browse/LEGAL-279 <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 <ma...@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 <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 <ma...@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 <ma...@apache.org>> wrote:
>> 
>> Hi,
>> 
>> I raised this legal ticket https://issues.apache.org/jira/browse/LEGAL-280 <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 
> 
> 
> 
> 

Re: LEGAL-280 - Cat-X and Optional Modules

["John D. Ament" <jo...@apache.org>]

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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>
>
>
>
>
>

Re: LEGAL-280 - Cat-X and Optional Modules

[Henri Yandell <ba...@apache.org>]

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 <jo...@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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>>
>>
>>
>>
>>

Re: LEGAL-280 - Cat-X and Optional Modules

["John D. Ament" <jo...@apache.org>]

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 <ba...@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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>
>
>
>
>

Re: LEGAL-280 - Cat-X and Optional Modules

[Henri Yandell <ba...@apache.org>]

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 <jo...@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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>>
>>
>>
>>

Re: LEGAL-280 - Cat-X and Optional Modules

["John D. Ament" <jo...@apache.org>]

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 <ba...@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 <jo...@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 <ra...@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 <jo...@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
>
>
>
>

Re: LEGAL-280 - Cat-X and Optional Modules

[Henri Yandell <ba...@apache.org>]

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 <jo...@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 <ra...@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 <jo...@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
>>
>>
>>

Re: LEGAL-280 - Cat-X and Optional Modules

["John D. Ament" <jo...@apache.org>]

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 <ra...@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 <jo...@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
>
>
>