You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by "P. Taylor Goetz" <pt...@gmail.com> on 2016/06/20 16:47:12 UTC
Amazon Software License compatibility
I have a question similar to the one described in LEGAL-198 [1], but based on that discussion I’m not really clear on how to handle an Amazon Software License dependency.
Here’s the scenario:
1. We have an optional component that is not required for the project software to function.
2. The component provides integration with AWS, and so depends on ASL-licensed client library (Kinesis client in this case).
3. The module does not contain any ASL-licensed code. The ASL-licensed component is strictly a runtime dependency for the module.
The questions I have that LEGAL-198 doesn’t seem clear on are:
1. Can the source code for this module be included in an Apache source release?
2. Can a binary of this module be pushed to repository.apache.org <http://repository.apache.org/> for consumption by Maven users?
3. How do we make such a module truly “optional” from a licensing standpoint?
Thanks in advance.
-Taylor
[1] https://issues.apache.org/jira/browse/LEGAL-198
Re: Amazon Software License compatibility
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
>> Or perhaps does ASL != Apache Software License (perhaps Amazon Software
License)?
Please remember there is no such thing as The Apache Software License.
The document is called the Apache License
Re: Amazon Software License compatibility
Posted by Ted Dunning <te...@gmail.com>.
On Mon, Jun 20, 2016 at 1:08 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
>
> We can certainly keep it separate, and exclude it from the main build and
> release artifacts. Actually users almost have to separately download (via
> Maven) such modules in order to use them (and we could enforce that for
> this module by not including it in convenience binaries).
>
> In terms of a source-only release, would we need to make sure the module
> is not included in the main build unless explicitly enabled by the user
> building the code? Can we even include the module source code in an Apache
> release?
>
> Would we be able to publish the module jar file to repository.apache.org?
>
My own tendency would be for somebody to publish it separately to maven,
but not to Apache repos.
Re: Amazon Software License compatibility
Posted by sebb <se...@gmail.com>.
On 21 June 2016 at 02:11, Justin Mclean <ju...@classsoftware.com> wrote:
> HI,
>
>> Just to be clear, that means no Apache source code can have a dependency on Category X - licensed software?
>
> It can if it’s an optional feature [1], used during the build process [2] or is a well know build tool [3]. But not if it's required feature/dependancy.
However of course the Cat X software cannot be bundled with the
release or distributed; end users will have to obtain it separately.
They will have to satisfy themselves whether its license is suitable
for their needs.
> Thanks,
> Justin
>
> 1. http://www.apache.org/legal/resolved.html#optional
> 2. http://www.apache.org/legal/resolved.html#prohibited
> 3. http://www.apache.org/legal/resolved.html#build-tools
> ---------------------------------------------------------------------
> 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: Amazon Software License compatibility
Posted by Shane Curcuru <as...@shanecurcuru.org>.
P. Taylor Goetz wrote on 6/21/16 12:15 AM:
...snip...
> I'm not opposed to tangential threads, but hope a side thread won't
> derail the original subject... ;)
>
> Probably worthy of a separate thread, but:
>
> I've always followed what seems to be a convention of abbreviating the
> Apache License as ASLvx.x (e.g "ASLv2", "ASLv1.1"). The emergence of the
> acronym "ASL" to refer to the Amazon Software License (I plead guilty :)
> ) has the potential to create confusion confusion
>
> Would it be worth documenting best practices wrt referring to the Apache
> License in an abbreviated form?
Thanks for the gentle nudge and useful thread, P.!
The most widely "canonical" viewed license abbreviation list is the SPDX
one, which uses Apache-2.0:
http://spdx.org/licenses/
Most people I've seen building tooling to check licenses use SPDX. Our
own docs use ALv2, but that can too easily be confused with Amazon or
Apple licenses.
- Shane
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Amazon Software License compatibility
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
> On Jun 20, 2016, at 10:43 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
>> On Mon, Jun 20, 2016 at 9:14 PM, Ted Dunning <te...@gmail.com> wrote:
>>
>> All well and good to say that there is no Apache Software License, but common usage is to use ASL to refer to the Apache License.
>>
>> Decoding common usage was what I was doing here.
>>
>> See for instance the first parenthetical on the Wikipedia page: https://en.wikipedia.org/wiki/Apache_License
>
> Indeed. That's an error, with respect to the current and defacto v 2.0.
>
> "The Apache Software License, Version 1.1" is what misleads authors (which
> we need to disabuse, now that 1.1 is hardly common anymore). This should
> be corrected whenever we trip over it.
>
> "Apache License, Version 2.0" deliberately omitted the term "Software" to be
> more generally applicable to other works.
>
> If you see "ASL" please, gently correct the author/page, rather than letting
> the mis-abbreviation persist (especially in light of other, actually abbrievated
> "ASL" licenses).
>
>
I'm not opposed to tangential threads, but hope a side thread won't derail the original subject... ;)
Probably worthy of a separate thread, but:
I've always followed what seems to be a convention of abbreviating the Apache License as ASLvx.x (e.g "ASLv2", "ASLv1.1"). The emergence of the acronym "ASL" to refer to the Amazon Software License (I plead guilty :) ) has the potential to create confusion confusion
Would it be worth documenting best practices wrt referring to the Apache License in an abbreviated form?
I'd also like to gently urge a return to the subject at hand. I know of at least three ASF projects that could benefit from a clear answer.
-Taylor
Re: Amazon Software License compatibility
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, Jun 20, 2016 at 9:14 PM, Ted Dunning <te...@gmail.com> wrote:
>
> All well and good to say that there is no Apache Software License, but
> common usage is to use ASL to refer to the Apache License.
>
> Decoding common usage was what I was doing here.
>
> See for instance the first parenthetical on the Wikipedia page:
> https://en.wikipedia.org/wiki/Apache_License
>
Indeed. That's an error, with respect to the current and defacto v 2.0.
"The Apache Software License, Version 1.1" is what misleads authors (which
we need to disabuse, now that 1.1 is hardly common anymore). This should
be corrected whenever we trip over it.
"Apache License, Version 2.0" deliberately omitted the term "Software" to be
more generally applicable to other works.
If you see "ASL" please, gently correct the author/page, rather than letting
the mis-abbreviation persist (especially in light of other, actually
abbrievated
"ASL" licenses).
Re: Amazon Software License compatibility
Posted by Ted Dunning <te...@gmail.com>.
All well and good to say that there is no Apache Software License, but
common usage is to use ASL to refer to the Apache License.
Decoding common usage was what I was doing here.
See for instance the first parenthetical on the Wikipedia page:
https://en.wikipedia.org/wiki/Apache_License
On Mon, Jun 20, 2016 at 7:08 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
> It's an optional module from an "entire product" perspective. But for the
> module itself to work, it requires the category X dependency.
>
> It's that second part that makes it fuzzy to me. It an optional module,
> but to work requires that module requires (non-optional) an cat X
> dependency.
>
> I'm leaning toward we can't have this in our source tree. But am having
> trouble with what the boundaries of "optional" are in this context.
>
> -Taylor
>
> > On Jun 20, 2016, at 9:11 PM, Justin Mclean <ju...@classsoftware.com>
> wrote:
> >
> > HI,
> >
> >> Just to be clear, that means no Apache source code can have a
> dependency on Category X - licensed software?
> >
> > It can if it’s an optional feature [1], used during the build process
> [2] or is a well know build tool [3]. But not if it's required
> feature/dependancy.
> >
> > Thanks,
> > Justin
> >
> > 1. http://www.apache.org/legal/resolved.html#optional
> > 2. http://www.apache.org/legal/resolved.html#prohibited
> > 3. http://www.apache.org/legal/resolved.html#build-tools
> > ---------------------------------------------------------------------
> > 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: Amazon Software License compatibility
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Would it make sense to update /legal/resolved.html to include a stance on the Amazon Software License?
I’ll add it to category X - not thing there any need to add anything else.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Amazon Software License compatibility
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
One final question:
Would it make sense to update /legal/resolved.html to include a stance on the Amazon Software License?
If so, is the correct process to file a LEGAL JIRA ticket?
-Taylor
> On Jun 21, 2016, at 5:03 PM, Alex Harui <ah...@adobe.com> wrote:
>
> IMO, you can include the ALv2 connector code in your release. It is the customer who bundles Kinesis that should make consumers of that bundle aware of what the licenses are within it.
>
> Good luck on your release,
> -Alex
>
> From: "P. Taylor Goetz" <pt...@gmail.com>
> Reply-To: <le...@apache.org>
> Date: Tuesday, June 21, 2016 at 12:07 PM
> To: <le...@apache.org>
> Subject: Re: Amazon Software License compatibility
>
>
>> On Jun 21, 2016, at 2:36 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>>> On Tue, Jun 21, 2016 at 12:20 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
>>> Hi Alex,
>>>
>>> In Apache Storm we have a number of components that users can use to do things like read from Apache Kafka, write to Apache HBase, etc. I’ll call them “connectors.” Connectors are optional and are not required to run Apache Storm.
>>>
>>> When users create an application to run on a Storm cluster, they bundle all their dependencies, including any connectors they are using, into a single fat jar file and upload it to the cluster to run.
>>>
>>> We have a contributor who has written a connector for Amazon Kinesis, and the Kinesis client library required by that code is licensed with the Amazon Software License [1].
>>>
>>> As I mentioned earlier, connectors are completely optional (optional facet #1). To use the Kinesis spout, however, users must bundle the Kinesis client library in their application jar file, so in this sense the Cat-X dependency is not optional (optional facet #2).
>>>
>>> The Kinesis connector would not require us to include any source code in our repository that is licensed under the Amazon Software License. The Kinesis client library is purely a dependency.
>>>
>>> I guess the question becomes, would we be able to license the Kinesis connector code under the ALv2 given the terms of the Amazon Software License [1]?
>>
>> You can license the Apache work under ALv2. Those licenses don't conflict.
>>
>> You cannot "bundle" the Kinesis client library, thereby creating a "derivative work",
>> and simultaneously use this bundle on a non-AWS architecture, if this bundle
>> is considered a derivative work...
>>
>> 3.3 Use Limitation. The Work and any derivative works thereof only may be used or intended for use with the web services, computing platforms or applications provided by Amazon.com, Inc. or its affiliates, including Amazon Web Services, Inc.
>>
>> I'm not a lawyer, so I can't comment whether the bundle is considered a
>> derivative work of its components, or whether the individual components
>> which go unused (based on the interpretation of "used or intended for use")
>> are simply part of a Compilation. If the 'bundle' used on both an AWS and
>> a non-AWS target will never "use or intended for use" on the non-AWS
>> target, the user may be in the clear. This may be informative;
>>
>> http://www.copyright.gov/circs/circ14.pdf
>>
>> The ASF won't create works with FOU restrictions (this was long-ago
>> settled back in the Sun Java days), and the 3.3 clause above for the
>> Amazon components is an FOU restriction. So we cannot ship this
>> component, although there should not be an issue with creating and
>> publishing an optional AL work from the ASF which does not include
>> the problematic license.
>
>
> I’m not a lawyer either, but this part of the Definitions section of the Amazon Software License seems applicable in terms of derivative works:
>
> "The terms “reproduce,” “reproduction,” “derivative works,” and “distribution” have the meaning as provided under U.S. copyright law; provided, however, that for the purposes of this License, derivative works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work.”
>
> That seems to imply that linking to the Kinesis client library does not create a derivative work in the context of the Amazon Software License. We also would not be bundling the Kinesis client library, end users would have to download it themselves (usually automated by maven).
>
> It seems like all the bases are covered. Is it safe to assume we can proceed?
>
> -Taylor
>
>
>
>
>
Re: Amazon Software License compatibility
Posted by Alex Harui <ah...@adobe.com>.
IMO, you can include the ALv2 connector code in your release. It is the customer who bundles Kinesis that should make consumers of that bundle aware of what the licenses are within it.
Good luck on your release,
-Alex
From: "P. Taylor Goetz" <pt...@gmail.com>>
Reply-To: <le...@apache.org>>
Date: Tuesday, June 21, 2016 at 12:07 PM
To: <le...@apache.org>>
Subject: Re: Amazon Software License compatibility
On Jun 21, 2016, at 2:36 PM, William A Rowe Jr <wr...@rowe-clan.net>> wrote:
On Tue, Jun 21, 2016 at 12:20 PM, P. Taylor Goetz <pt...@gmail.com>> wrote:
Hi Alex,
In Apache Storm we have a number of components that users can use to do things like read from Apache Kafka, write to Apache HBase, etc. I’ll call them “connectors.” Connectors are optional and are not required to run Apache Storm.
When users create an application to run on a Storm cluster, they bundle all their dependencies, including any connectors they are using, into a single fat jar file and upload it to the cluster to run.
We have a contributor who has written a connector for Amazon Kinesis, and the Kinesis client library required by that code is licensed with the Amazon Software License [1].
As I mentioned earlier, connectors are completely optional (optional facet #1). To use the Kinesis spout, however, users must bundle the Kinesis client library in their application jar file, so in this sense the Cat-X dependency is not optional (optional facet #2).
The Kinesis connector would not require us to include any source code in our repository that is licensed under the Amazon Software License. The Kinesis client library is purely a dependency.
I guess the question becomes, would we be able to license the Kinesis connector code under the ALv2 given the terms of the Amazon Software License [1]?
You can license the Apache work under ALv2. Those licenses don't conflict.
You cannot "bundle" the Kinesis client library, thereby creating a "derivative work",
and simultaneously use this bundle on a non-AWS architecture, if this bundle
is considered a derivative work...
3.3 Use Limitation. The Work and any derivative works thereof only may be used or intended for use with the web services, computing platforms or applications provided by Amazon.com<http://amazon.com/>, Inc. or its affiliates, including Amazon Web Services, Inc.
I'm not a lawyer, so I can't comment whether the bundle is considered a
derivative work of its components, or whether the individual components
which go unused (based on the interpretation of "used or intended for use")
are simply part of a Compilation. If the 'bundle' used on both an AWS and
a non-AWS target will never "use or intended for use" on the non-AWS
target, the user may be in the clear. This may be informative;
http://www.copyright.gov/circs/circ14.pdf
The ASF won't create works with FOU restrictions (this was long-ago
settled back in the Sun Java days), and the 3.3 clause above for the
Amazon components is an FOU restriction. So we cannot ship this
component, although there should not be an issue with creating and
publishing an optional AL work from the ASF which does not include
the problematic license.
I’m not a lawyer either, but this part of the Definitions section of the Amazon Software License seems applicable in terms of derivative works:
"The terms “reproduce,” “reproduction,” “derivative works,” and “distribution” have the meaning as provided under U.S. copyright law; provided, however, that for the purposes of this License, derivative works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work.”
That seems to imply that linking to the Kinesis client library does not create a derivative work in the context of the Amazon Software License. We also would not be bundling the Kinesis client library, end users would have to download it themselves (usually automated by maven).
It seems like all the bases are covered. Is it safe to assume we can proceed?
-Taylor
Re: Amazon Software License compatibility
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
> On Jun 21, 2016, at 2:36 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Tue, Jun 21, 2016 at 12:20 PM, P. Taylor Goetz <ptgoetz@gmail.com <ma...@gmail.com>> wrote:
> Hi Alex,
>
> In Apache Storm we have a number of components that users can use to do things like read from Apache Kafka, write to Apache HBase, etc. I’ll call them “connectors.” Connectors are optional and are not required to run Apache Storm.
>
> When users create an application to run on a Storm cluster, they bundle all their dependencies, including any connectors they are using, into a single fat jar file and upload it to the cluster to run.
>
> We have a contributor who has written a connector for Amazon Kinesis, and the Kinesis client library required by that code is licensed with the Amazon Software License [1].
>
> As I mentioned earlier, connectors are completely optional (optional facet #1). To use the Kinesis spout, however, users must bundle the Kinesis client library in their application jar file, so in this sense the Cat-X dependency is not optional (optional facet #2).
>
> The Kinesis connector would not require us to include any source code in our repository that is licensed under the Amazon Software License. The Kinesis client library is purely a dependency.
>
> I guess the question becomes, would we be able to license the Kinesis connector code under the ALv2 given the terms of the Amazon Software License [1]?
>
> You can license the Apache work under ALv2. Those licenses don't conflict.
>
> You cannot "bundle" the Kinesis client library, thereby creating a "derivative work",
> and simultaneously use this bundle on a non-AWS architecture, if this bundle
> is considered a derivative work...
>
> 3.3 Use Limitation. The Work and any derivative works thereof only may be used or intended for use with the web services, computing platforms or applications provided by Amazon.com <http://amazon.com/>, Inc. or its affiliates, including Amazon Web Services, Inc.
>
> I'm not a lawyer, so I can't comment whether the bundle is considered a
> derivative work of its components, or whether the individual components
> which go unused (based on the interpretation of "used or intended for use")
> are simply part of a Compilation. If the 'bundle' used on both an AWS and
> a non-AWS target will never "use or intended for use" on the non-AWS
> target, the user may be in the clear. This may be informative;
>
> http://www.copyright.gov/circs/circ14.pdf <http://www.copyright.gov/circs/circ14.pdf>
>
> The ASF won't create works with FOU restrictions (this was long-ago
> settled back in the Sun Java days), and the 3.3 clause above for the
> Amazon components is an FOU restriction. So we cannot ship this
> component, although there should not be an issue with creating and
> publishing an optional AL work from the ASF which does not include
> the problematic license.
I’m not a lawyer either, but this part of the Definitions section of the Amazon Software License seems applicable in terms of derivative works:
"The terms “reproduce,” “reproduction,” “derivative works,” and “distribution” have the meaning as provided under U.S. copyright law; provided, however, that for the purposes of this License, derivative works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work.”
That seems to imply that linking to the Kinesis client library does not create a derivative work in the context of the Amazon Software License. We also would not be bundling the Kinesis client library, end users would have to download it themselves (usually automated by maven).
It seems like all the bases are covered. Is it safe to assume we can proceed?
-Taylor
Re: Amazon Software License compatibility
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Jun 21, 2016 at 12:20 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
> Hi Alex,
>
> In Apache Storm we have a number of components that users can use to do
> things like read from Apache Kafka, write to Apache HBase, etc. I’ll call
> them “connectors.” Connectors are optional and are not required to run
> Apache Storm.
>
> When users create an application to run on a Storm cluster, they bundle
> all their dependencies, including any connectors they are using, into a
> single fat jar file and upload it to the cluster to run.
>
> We have a contributor who has written a connector for Amazon Kinesis, and
> the Kinesis client library required by that code is licensed with the
> Amazon Software License [1].
>
> As I mentioned earlier, connectors are completely optional (optional facet
> #1). To use the Kinesis spout, however, users must bundle the Kinesis
> client library in their application jar file, so in this sense the Cat-X
> dependency is not optional (optional facet #2).
>
> The Kinesis connector would not require us to include any source code in
> our repository that is licensed under the Amazon Software License. The
> Kinesis client library is purely a dependency.
>
> I guess the question becomes, would we be able to license the Kinesis
> connector code under the ALv2 given the terms of the Amazon Software
> License [1]?
>
You can license the Apache work under ALv2. Those licenses don't conflict.
You cannot "bundle" the Kinesis client library, thereby creating a
"derivative work",
and simultaneously use this bundle on a non-AWS architecture, if this bundle
is considered a derivative work...
3.3 Use Limitation. The Work and any derivative works thereof only may be
used or intended for use with the web services, computing platforms or
applications provided by Amazon.com, Inc. or its affiliates, including
Amazon Web Services, Inc.
I'm not a lawyer, so I can't comment whether the bundle is considered a
derivative work of its components, or whether the individual components
which go unused (based on the interpretation of "used or intended for use")
are simply part of a Compilation. If the 'bundle' used on both an AWS and
a non-AWS target will never "use or intended for use" on the non-AWS
target, the user may be in the clear. This may be informative;
http://www.copyright.gov/circs/circ14.pdf
The ASF won't create works with FOU restrictions (this was long-ago
settled back in the Sun Java days), and the 3.3 clause above for the
Amazon components is an FOU restriction. So we cannot ship this
component, although there should not be an issue with creating and
publishing an optional AL work from the ASF which does not include
the problematic license.
Re: Amazon Software License compatibility
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
Hi Alex,
In Apache Storm we have a number of components that users can use to do things like read from Apache Kafka, write to Apache HBase, etc. I’ll call them “connectors.” Connectors are optional and are not required to run Apache Storm.
When users create an application to run on a Storm cluster, they bundle all their dependencies, including any connectors they are using, into a single fat jar file and upload it to the cluster to run.
We have a contributor who has written a connector for Amazon Kinesis, and the Kinesis client library required by that code is licensed with the Amazon Software License [1].
As I mentioned earlier, connectors are completely optional (optional facet #1). To use the Kinesis spout, however, users must bundle the Kinesis client library in their application jar file, so in this sense the Cat-X dependency is not optional (optional facet #2).
The Kinesis connector would not require us to include any source code in our repository that is licensed under the Amazon Software License. The Kinesis client library is purely a dependency.
I guess the question becomes, would we be able to license the Kinesis connector code under the ALv2 given the terms of the Amazon Software License [1]?
-Taylor
[1] https://aws.amazon.com/asl/
> On Jun 21, 2016, at 1:38 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 6/20/16, 7:08 PM, "P. Taylor Goetz" <ptgoetz@gmail.com <ma...@gmail.com>> wrote:
>
>> It's an optional module from an "entire product" perspective. But for the
>> module itself to work, it requires the category X dependency.
>>
>> It's that second part that makes it fuzzy to me. It an optional module,
>> but to work requires that module requires (non-optional) an cat X
>> dependency.
>>
>> I'm leaning toward we can't have this in our source tree. But am having
>> trouble with what the boundaries of "optional" are in this context.
>
> IMO, "optional" is defined for this context in [1] in Justin's reply.
>
> Also, IMO, depending on the actual Cat-X license, if an ASF project can
> write code that relies on that Cat-X dependency and license said code
> under ALv2, and either [1],[2], or [3] is met, said code can be part of an
> ASF release, live in an ASF repo and be distributed from ASF servers. The
> actual Cat-X dependency cannot. But instead of theoreticals, maybe you
> can discuss your specific case.
>
> -Alex
>
>>
>> -Taylor
>>
>>> On Jun 20, 2016, at 9:11 PM, Justin Mclean <ju...@classsoftware.com>
>>> wrote:
>>>
>>> HI,
>>>
>>>> Just to be clear, that means no Apache source code can have a
>>>> dependency on Category X - licensed software?
>>>
>>> It can if it’s an optional feature [1], used during the build process
>>> [2] or is a well know build tool [3]. But not if it's required
>>> feature/dependancy.
>>>
>>> Thanks,
>>> Justin
>>>
>>> 1. http://www.apache.org/legal/resolved.html#optional
>>> 2. http://www.apache.org/legal/resolved.html#prohibited
>>> 3. http://www.apache.org/legal/resolved.html#build-tools
>>> ---------------------------------------------------------------------
>>> 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 <ma...@apache.org>
>> For additional commands, e-mail: legal-discuss-help@apache.org <ma...@apache.org>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org <ma...@apache.org>
> For additional commands, e-mail: legal-discuss-help@apache.org <ma...@apache.org>
Re: Amazon Software License compatibility
Posted by Alex Harui <ah...@adobe.com>.
On 6/20/16, 7:08 PM, "P. Taylor Goetz" <pt...@gmail.com> wrote:
>It's an optional module from an "entire product" perspective. But for the
>module itself to work, it requires the category X dependency.
>
>It's that second part that makes it fuzzy to me. It an optional module,
>but to work requires that module requires (non-optional) an cat X
>dependency.
>
>I'm leaning toward we can't have this in our source tree. But am having
>trouble with what the boundaries of "optional" are in this context.
IMO, "optional" is defined for this context in [1] in Justin's reply.
Also, IMO, depending on the actual Cat-X license, if an ASF project can
write code that relies on that Cat-X dependency and license said code
under ALv2, and either [1],[2], or [3] is met, said code can be part of an
ASF release, live in an ASF repo and be distributed from ASF servers. The
actual Cat-X dependency cannot. But instead of theoreticals, maybe you
can discuss your specific case.
-Alex
>
>-Taylor
>
>> On Jun 20, 2016, at 9:11 PM, Justin Mclean <ju...@classsoftware.com>
>>wrote:
>>
>> HI,
>>
>>> Just to be clear, that means no Apache source code can have a
>>>dependency on Category X - licensed software?
>>
>> It can if it’s an optional feature [1], used during the build process
>>[2] or is a well know build tool [3]. But not if it's required
>>feature/dependancy.
>>
>> Thanks,
>> Justin
>>
>> 1. http://www.apache.org/legal/resolved.html#optional
>> 2. http://www.apache.org/legal/resolved.html#prohibited
>> 3. http://www.apache.org/legal/resolved.html#build-tools
>> ---------------------------------------------------------------------
>> 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: Amazon Software License compatibility
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
It's an optional module from an "entire product" perspective. But for the module itself to work, it requires the category X dependency.
It's that second part that makes it fuzzy to me. It an optional module, but to work requires that module requires (non-optional) an cat X dependency.
I'm leaning toward we can't have this in our source tree. But am having trouble with what the boundaries of "optional" are in this context.
-Taylor
> On Jun 20, 2016, at 9:11 PM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> HI,
>
>> Just to be clear, that means no Apache source code can have a dependency on Category X - licensed software?
>
> It can if it’s an optional feature [1], used during the build process [2] or is a well know build tool [3]. But not if it's required feature/dependancy.
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/legal/resolved.html#optional
> 2. http://www.apache.org/legal/resolved.html#prohibited
> 3. http://www.apache.org/legal/resolved.html#build-tools
> ---------------------------------------------------------------------
> 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: Amazon Software License compatibility
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> Just to be clear, that means no Apache source code can have a dependency on Category X - licensed software?
It can if it’s an optional feature [1], used during the build process [2] or is a well know build tool [3]. But not if it's required feature/dependancy.
Thanks,
Justin
1. http://www.apache.org/legal/resolved.html#optional
2. http://www.apache.org/legal/resolved.html#prohibited
3. http://www.apache.org/legal/resolved.html#build-tools
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Amazon Software License compatibility
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
Thanks Justin,
In this case were talking about code that links at compile time to category X software.
Just to be clear, that means no Apache source code can have a dependency on Category X - licensed software?
This has always been my interpretation, but I see other projects interpreting it differently, and perhaps wrongly. In general I try not to give in to "but other Apache projects do this" arguments, which I've seen in this case. People make mistakes, but it scares me when those mistakes are treated as precedent.
Thanks again for your input, I appreciate.
-Taylor
> On Jun 20, 2016, at 6:29 PM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> HI,
>
>> In terms of a source-only release, would we need to make sure the module is not included in the main build unless explicitly enabled by the user building the code? Can we even include the module source code in an Apache release?
>
> No. Category X software can’t be put in a release [1]
>
>> Would we be able to publish the module jar file to repository.apache.org?
>
> No. Category X software can’t be distributed by an Apache project [2]
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/legal/resolved.html#category-x
> 1. http://www.apache.org/legal/resolved.html#prohibited
Re: Amazon Software License compatibility
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> In terms of a source-only release, would we need to make sure the module is not included in the main build unless explicitly enabled by the user building the code? Can we even include the module source code in an Apache release?
No. Category X software can’t be put in a release [1]
> Would we be able to publish the module jar file to repository.apache.org <http://repository.apache.org/>?
No. Category X software can’t be distributed by an Apache project [2]
Thanks,
Justin
1. http://www.apache.org/legal/resolved.html#category-x
1. http://www.apache.org/legal/resolved.html#prohibited
Re: Amazon Software License compatibility
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
Thanks Ted.
I think we can easily make the case that it is optional in terms of both (a) AND (b). What I’d like to know is the exact mechanics of doing so without creating a licensing issue for the product as a whole.
> a) Can the overall product be run without including or loading the module at all? (i.e. is there some dynamic linkage going on?)
In this sense the module is optional, and not required at all to use the overall product. To use the module, a user would have to explicitly add the module as a dependency in their Maven pom, or add it to the classpath.
(For more context, the module is an Apache Storm spout that reads data from Amazon Kinesis. To use it, users would have to add it as a dependency to their topology code.)
> b) can the module in question be released and downloaded separately from any binary convenience artifacts for the main product?
We can certainly keep it separate, and exclude it from the main build and release artifacts. Actually users almost have to separately download (via Maven) such modules in order to use them (and we could enforce that for this module by not including it in convenience binaries).
In terms of a source-only release, would we need to make sure the module is not included in the main build unless explicitly enabled by the user building the code? Can we even include the module source code in an Apache release?
Would we be able to publish the module jar file to repository.apache.org <http://repository.apache.org/>?
-Taylor
>
>
>
> On Mon, Jun 20, 2016 at 11:59 AM, P. Taylor Goetz <ptgoetz@gmail.com <ma...@gmail.com>> wrote:
> Yes, in this context ASL==Amazon Software License, which appears to be Category X.
>
>
>> On Jun 20, 2016, at 2:53 PM, Ted Dunning <ted.dunning@gmail.com <ma...@gmail.com>> wrote:
>>
>>
>> This is a little confusing. I think it may be a reader problem (i.e. me)
>>
>> In (3), how is the code in the module licensed if not ASL? Are you actually saying that the module has no *external* ASL code?
>>
>> Also, if the Kinesis client is ASL licensed, where is the problem in any case?
>>
>> Or perhaps does ASL != Apache Software License (perhaps Amazon Software License)?
>>
>>
>>
>>
>> On Mon, Jun 20, 2016 at 9:47 AM, P. Taylor Goetz <ptgoetz@gmail.com <ma...@gmail.com>> wrote:
>> I have a question similar to the one described in LEGAL-198 [1], but based on that discussion I’m not really clear on how to handle an Amazon Software License dependency.
>>
>> Here’s the scenario:
>>
>> 1. We have an optional component that is not required for the project software to function.
>> 2. The component provides integration with AWS, and so depends on ASL-licensed client library (Kinesis client in this case).
>> 3. The module does not contain any ASL-licensed code. The ASL-licensed component is strictly a runtime dependency for the module.
>>
>> The questions I have that LEGAL-198 doesn’t seem clear on are:
>>
>> 1. Can the source code for this module be included in an Apache source release?
>> 2. Can a binary of this module be pushed to repository.apache.org <http://repository.apache.org/> for consumption by Maven users?
>> 3. How do we make such a module truly “optional” from a licensing standpoint?
>>
>> Thanks in advance.
>>
>> -Taylor
>>
>> [1] https://issues.apache.org/jira/browse/LEGAL-198 <https://issues.apache.org/jira/browse/LEGAL-198>
>
>
Re: Amazon Software License compatibility
Posted by Ted Dunning <te...@gmail.com>.
a) Can the overall product be run without including or loading the module
at all? (i.e. is there some dynamic linkage going on?)
b) can the module in question be released and downloaded separately from
any binary convenience artifacts for the main product?
If (a) AND (b), then this is a very obviously optional module.
If (a) AND NOT (b), the module is less obviously optional, but presumably
you can remove the module in question. The "optional" becomes a form of
opt-out rather than the more desirable opt-in, but a case could still be
made that they module is optional.
On Mon, Jun 20, 2016 at 11:59 AM, P. Taylor Goetz <pt...@gmail.com> wrote:
> Yes, in this context ASL==Amazon Software License, which appears to be
> Category X.
>
>
> On Jun 20, 2016, at 2:53 PM, Ted Dunning <te...@gmail.com> wrote:
>
>
> This is a little confusing. I think it may be a reader problem (i.e. me)
>
> In (3), how is the code in the module licensed if not ASL? Are you
> actually saying that the module has no *external* ASL code?
>
> Also, if the Kinesis client is ASL licensed, where is the problem in any
> case?
>
> Or perhaps does ASL != Apache Software License (perhaps Amazon Software
> License)?
>
>
>
>
> On Mon, Jun 20, 2016 at 9:47 AM, P. Taylor Goetz <pt...@gmail.com>
> wrote:
>
>> I have a question similar to the one described in LEGAL-198 [1], but
>> based on that discussion I’m not really clear on how to handle an Amazon
>> Software License dependency.
>>
>> Here’s the scenario:
>>
>> 1. We have an optional component that is not required for the project
>> software to function.
>> 2. The component provides integration with AWS, and so depends on
>> ASL-licensed client library (Kinesis client in this case).
>> 3. The module does not contain any ASL-licensed code. The ASL-licensed
>> component is strictly a runtime dependency for the module.
>>
>> The questions I have that LEGAL-198 doesn’t seem clear on are:
>>
>> 1. Can the source code for this module be included in an Apache source
>> release?
>> 2. Can a binary of this module be pushed to repository.apache.org for
>> consumption by Maven users?
>> 3. How do we make such a module truly “optional” from a licensing
>> standpoint?
>>
>> Thanks in advance.
>>
>> -Taylor
>>
>> [1] https://issues.apache.org/jira/browse/LEGAL-198
>>
>
>
>
Re: Amazon Software License compatibility
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
Yes, in this context ASL==Amazon Software License, which appears to be Category X.
> On Jun 20, 2016, at 2:53 PM, Ted Dunning <te...@gmail.com> wrote:
>
>
> This is a little confusing. I think it may be a reader problem (i.e. me)
>
> In (3), how is the code in the module licensed if not ASL? Are you actually saying that the module has no *external* ASL code?
>
> Also, if the Kinesis client is ASL licensed, where is the problem in any case?
>
> Or perhaps does ASL != Apache Software License (perhaps Amazon Software License)?
>
>
>
>
> On Mon, Jun 20, 2016 at 9:47 AM, P. Taylor Goetz <ptgoetz@gmail.com <ma...@gmail.com>> wrote:
> I have a question similar to the one described in LEGAL-198 [1], but based on that discussion I’m not really clear on how to handle an Amazon Software License dependency.
>
> Here’s the scenario:
>
> 1. We have an optional component that is not required for the project software to function.
> 2. The component provides integration with AWS, and so depends on ASL-licensed client library (Kinesis client in this case).
> 3. The module does not contain any ASL-licensed code. The ASL-licensed component is strictly a runtime dependency for the module.
>
> The questions I have that LEGAL-198 doesn’t seem clear on are:
>
> 1. Can the source code for this module be included in an Apache source release?
> 2. Can a binary of this module be pushed to repository.apache.org <http://repository.apache.org/> for consumption by Maven users?
> 3. How do we make such a module truly “optional” from a licensing standpoint?
>
> Thanks in advance.
>
> -Taylor
>
> [1] https://issues.apache.org/jira/browse/LEGAL-198 <https://issues.apache.org/jira/browse/LEGAL-198>
Re: Amazon Software License compatibility
Posted by Ted Dunning <te...@gmail.com>.
This is a little confusing. I think it may be a reader problem (i.e. me)
In (3), how is the code in the module licensed if not ASL? Are you
actually saying that the module has no *external* ASL code?
Also, if the Kinesis client is ASL licensed, where is the problem in any
case?
Or perhaps does ASL != Apache Software License (perhaps Amazon Software
License)?
On Mon, Jun 20, 2016 at 9:47 AM, P. Taylor Goetz <pt...@gmail.com> wrote:
> I have a question similar to the one described in LEGAL-198 [1], but based
> on that discussion I’m not really clear on how to handle an Amazon Software
> License dependency.
>
> Here’s the scenario:
>
> 1. We have an optional component that is not required for the project
> software to function.
> 2. The component provides integration with AWS, and so depends on
> ASL-licensed client library (Kinesis client in this case).
> 3. The module does not contain any ASL-licensed code. The ASL-licensed
> component is strictly a runtime dependency for the module.
>
> The questions I have that LEGAL-198 doesn’t seem clear on are:
>
> 1. Can the source code for this module be included in an Apache source
> release?
> 2. Can a binary of this module be pushed to repository.apache.org for
> consumption by Maven users?
> 3. How do we make such a module truly “optional” from a licensing
> standpoint?
>
> Thanks in advance.
>
> -Taylor
>
> [1] https://issues.apache.org/jira/browse/LEGAL-198
>