www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Is Spark Kinesis (non-assembly) module distributable via Maven?
Date Sun, 18 Sep 2016 05:54:01 GMT
Hi Luciano,

I'm not an official answer-person, but I believe your interpretation is too narrow.  If a
majority of folks who start downloading your Maven artifacts will not end up downloading the
jar that depends on a category X jar, you can deploy that jar that depends on the category
X jar to Maven.  If you are right, then there is more than one project that needs to do some
adjusting.

-Alex

From: Luciano Resende <luckbr1975@gmail.com<mailto:luckbr1975@gmail.com>>
Reply-To: "legal-discuss@apache.org<mailto:legal-discuss@apache.org>" <legal-discuss@apache.org<mailto:legal-discuss@apache.org>>
Date: Saturday, September 17, 2016 at 3:41 PM
To: legal discuss <legal-discuss@apache.org<mailto:legal-discuss@apache.org>>
Subject: Re: Is Spark Kinesis (non-assembly) module distributable via Maven?

So, let's go back to the original quotes on the current resolved items from Apache Legal :

http://www.apache.org/legal/resolved.html#prohibited says:
-----
CAN APACHE PROJECTS RELY ON COMPONENTS UNDER PROHIBITED LICENSES?
Apache projects cannot distribute any such components. As with the previous question on platforms,
the component can be relied on if the component's licence terms do not affect the Apache product's
licensing. For example, using a GPL'ed tool during the build is OK.

CAN APACHE PROJECTS RELY ON COMPONENTS WHOSE LICENSING AFFECTS THE APACHE PRODUCT?
Apache projects cannot distribute any such components. However, if the component is only needed
for optional features, a project can provide the user with instructions on how to obtain and
install the non-included work. Optional means that the component is not required for standard
use of the product or for the product to achieve a desirable level of quality. The question
to ask yourself in this situation is:

"Will the majority of users want to use my product without adding the optional components?"
-----

Now consider the Kinesis module that has a direct dependency on a library (jar) that is licensed
under the Amazon Software License (Category X).

Based on "CAN APACHE PROJECTS RELY ON COMPONENTS UNDER PROHIBITED LICENSES?"  the Apache Spark
project cannot distribute such artifacts, so publish this jar in maven as part of a release
process is NOT allowed.

Based on "CAN APACHE PROJECTS RELY ON COMPONENTS WHOSE LICENSING AFFECTS THE APACHE PRODUCT?"
 which claims that "Apache projects cannot distribute any such components. However, if the
component is only needed for optional features, a project can provide the user with instructions
on how to obtain and install the non-included work". Based on this, I believe that, leaving
this module in the source code, and adding instructions on how the user can build themselves
with the appropriate disclaimer that this will introduce code under Amazon Software License
is admissible.

This is very similar to how we document the profile/license for the Ganglia sink in Apache
Spark :

http://spark.apache.org/docs/latest/monitoring.html#metrics

To install the GangliaSink you’ll need to perform a custom build of Spark. Note that by
embedding this library you will include LGPL<http://www.gnu.org/copyleft/lesser.html>-licensed
code in your Spark package. For sbt users, set the SPARK_GANGLIA_LGPL environment variable
before building. For Maven users, enable the -Pspark-ganglia-lgpl profile. In addition to
modifying the cluster’s Spark build user applications will need to link to the spark-ganglia-lgpl
artifact.


So, my understanding is :

- We MUST NOT publish this code (e.g. into maven) as part of a release process.

- We MAY leave the source code available (as this is optional), where we can document how
the user can enable/compile the code together with a disclaimer about the license.


If this is not the case, then are we saying that we can now publish code with direct dependencies
on Category X licensed libraries (e.g. GPL, Amazon Software License, etc) ?




On Sat, Sep 17, 2016 at 1:37 AM, Sean Owen <srowen@gmail.com<mailto:srowen@gmail.com>>
wrote:
I believe that *is* the situation I'm describing. Spark has an optional module Spark-Kinesis,
which doesn't contain but relies on the Kinesis client. "Rely" here means and compile and
runtime dependency on the Kinesis client JARs, and those are category X.

If your distinction was just that it somehow 'runs on' Kinesis without depending on Category
X software, then no, the situation is that this optional module relies directly on Category
X client software in JARs.

On Sat, Sep 17, 2016 at 4:58 AM Ralph Goers <ralph.goers@dslextreme.com<mailto:ralph.goers@dslextreme.com>>
wrote:
OK. But the original question says "It does not itself contain any source or binary code from
the Amazon Kinesis client. However, this optional Spark Kinesis module requires the Kinesis
client of course. And, the Kinesis client is licensed under the Amazon Software License, which
is Category X.” which clearly is very different than saying it requires a jar that is licensed
under category x.

Ralph



--
Luciano Resende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Mime
View raw message