www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache <ralph.go...@dslextreme.com>
Subject Re: LEGAL-280 - Cat-X and Optional Modules
Date Fri, 09 Dec 2016 14:02:53 GMT
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 <johndament@apache.org> wrote:
> 
> RE 3 and 4 - the answers are yes.
> The product could (and does) provide similar modules for other more reasonably licensed
products (e.g. EclipseLink & Apache OpenJPA)
> 
> RE #1 - The argument I've made with my legal is that the style of use is not a "derivative"
since there's no modifications to the source code, one of the requirements to fall under the
derivative section of the LGPL.
> 
> RE #2 - I don't have a way to judge this.  If the module is called "hibernate-integration"
then would a user be surprised that includes a dependency on hibernate for their convenience
- probably not.
> 
> On Sun, Dec 4, 2016 at 7:06 PM Henri Yandell <bayard@apache.org <mailto:bayard@apache.org>>
wrote:
> So applying my tests:
> 
> 1) Does it pass the criteria?   Possibly not; LGPL 2.1 (assuming 2.1) has a reverse engineering
clause that could apply to the Apache product. 2) Will users be surprised? Hard to judge this
as the details aren't in the issue.
> 3) Can it be meaningfully separated? Again hard to judge without details. Easy to remove
a jar, but will rest of the product work with it removed (presumably from your optional description).
> 4) Are there alternatives? Could we develop an alternative with moderate effort? To be
answered.
> 
> Hen
> 
> 
> On Sun, Dec 4, 2016 at 7:29 AM, John D. Ament <johndament@apache.org <mailto:johndament@apache.org>>
wrote:
> Hi Henri,
> 
> So the situation here is a little different than in 279.  In 279, this is a pretty core
module of the product wherein the developers had made modifications to it and include it in
their source code.
> 
> In this case, its not embedded, no changes are made within the product to the source
code of the undesirably licensed product.
> 
> John
> 
> 
> On Sun, Dec 4, 2016 at 4:43 AM Henri Yandell <bayard@apache.org <mailto:bayard@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 <mailto:johndament@apache.org>>
wrote:
> So maybe.. but hear me out for a minute.
> 
> I'm assuming by Legal FAQ you're referring to the previously asked questions page https://www.apache.org/legal/resolved
<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 <mailto:ralph.goers@dslextreme.com>>
wrote:
> This is answered on the legal FAQ.  The one point you are missing is: will the majority
of your users want to use the optional dependency? If they do then it may not really be all
that optional.
> 
> Ralph
> 
>> On Nov 29, 2016, at 12:51 PM, John D. Ament <johndament@apache.org <mailto:johndament@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 
> 
> 
> 


Mime
View raw message