www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <sro...@gmail.com>
Subject Re: Is Spark Kinesis (non-assembly) module distributable via Maven?
Date Sun, 18 Sep 2016 07:48:41 GMT
That is not the case for Spark-Kinesis. If your build depends on
Spark-Kinesis, then you will necessarily download the Kinesis client as a
transitive dependency.
However, almost all Spark users will not depend on Spark-Kinesis.

On Sun, Sep 18, 2016 at 6:54 AM Alex Harui <aharui@adobe.com> wrote:

> 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>
> Reply-To: "legal-discuss@apache.org" <legal-discuss@apache.org>
> Date: Saturday, September 17, 2016 at 3:41 PM
> To: legal discuss <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> 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>
>> 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