You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by David Nalley <da...@gnsa.us> on 2012/07/28 03:24:08 UTC
[DISCUSS] Dropping NetApp Support
Hi folks,
As I noted in an earlier email, I've been playing with dependencies
this evening.
one of those dependencies is manageontap.jar, which is part of the NM
SDK from NetApp. Sadly I can't get to the license terms for this
particular library as it's behind a paywall. This leads me to believe
that it's not open source, though perhaps it has a freely
redistributable license. Who knows.
Now that Murali and Alex and others have done lots of work to get
things pretty modular, it's pretty easy to remove this from the
default build, so I propose we drop the jar (no real choice about
that), make this a non-default build path, and perhaps include
instructions on how to download the jar (though someone else would
have to do that) and build the plugin if needed.
If I don't hear any backlash, I'll make this part of my ant dependency
download target.
--David.
Re: [DISCUSS] Dropping NetApp Support
Posted by Chip Childers <ch...@sungard.com>.
On Thu, Aug 9, 2012 at 4:40 PM, John Kinsella <jl...@stratosec.co> wrote:
> On Aug 9, 2012, at 3:55 AM, David Nalley wrote:
>
>> On Wed, Aug 8, 2012 at 6:03 PM, John Kinsella <jl...@stratosec.co> wrote:
>>>
>>> On Aug 8, 2012, at 2:51 PM, Ewan Mellor wrote:
>>>
>>>>> -----Original Message-----
>>>>> From: Chip Childers [mailto:chip.childers@sungard.com]
>>>>> Sent: Wednesday, August 08, 2012 12:31 PM
>>>>> To: cloudstack-dev@incubator.apache.org
>>>>> Subject: Re: [DISCUSS] Dropping NetApp Support
>>>>>
>>>>> On Wed, Aug 8, 2012 at 1:56 PM, John Kinsella <jl...@stratosec.co> wrote:
>>>>>> I reached out to some contacts at NetApp, their product management
>>>>> team quoted the following part of their "NETAPP MANAGEABILITY SDK -
>>>>> EULA.docx"[1] to me:
>>>>>>
>>>>>> "Subject to the terms and conditions set forth herein, NetApp grants
>>>>> You a license to:...Use, reproduce and distribute the Language
>>>>> Libraries in object code form (for C/C++, Java, C#, VB.NET and
>>>>> PowerShell only) and source code form (for Perl, Python and Ruby only)
>>>>> as incorporated into the Licensee Application; provided, however, that
>>>>> You (A) reproduce and include the copyright notice that appears in the
>>>>> Language Libraries as provided by NetApp, and (B) distribute the
>>>>> Licensee Application incorporating the Language Libraries pursuant to
>>>>> terms no less restrictive than those set forth herein. You shall not
>>>>> modify the Language Libraries; and..."
>>>>>>
>>>>>> Not that we want to distribute jars in the source, I was told they
>>>>> don't have an "open source" license so this wouldn't fly with ASL, but
>>>>> perhaps we could provide the library as part of the "convenience
>>>>> builds?"
>>>>>>
>>>>>> John
>>>>>> 1: I can forward the docx to the list or put it up somewhere if
>>>>> there's interest
>>>>>
>>>>> John,
>>>>>
>>>>> I think we may not be able to distribute this, even within a
>>>>> convenience binary. From what I can tell, this is basically falling
>>>>> into "Category X", which the ASF has explicitly stated that no project
>>>>> can distribute source OR binary distributions that contain prohibited
>>>>> works. I think we can also assume that we can't make it a "system
>>>>> dependency" for the project (stating the obvious here). The policy
>>>>> goes on to offer three suggestions for how to help users optionally
>>>>> make use of the prohibited work:
>>>>>
>>>>> ###############
>>>>>
>>>>> If a PMC wishes to allow optional add-ons to enhance the functionality
>>>>> of the standard Apache product, the following options are available:
>>>>>
>>>>> 1) For add-ons under authorized licenses, the add-on could be
>>>>> distributed inside the product (see forthcoming policy on "Receiving
>>>>> and Releasing Contributions" for details on how and where to do this).
>>>>>
>>>>> 2) For add-ons under excluded licenses, the PMC may provide a
>>>>> link/reference on the product web site or within product documentation
>>>>> to some other web site that hosts such add-ons (e.g. a SF.net project
>>>>> or some third-party site dedicated to distributing add-ons for the
>>>>> Apache product) as long as it is made clear to users that the host
>>>>> site is not part of the Apache product nor endorsed by the ASF.
>>>>>
>>>>> 3) For add-ons under excluded licenses, the PMC may include a feature
>>>>> within the product that allows the user to obtain third-party add-ons
>>>>> if the feature also alerts the user of the associated license and
>>>>> makes clear to users that the host site is not part of the Apache
>>>>> product nor endorsed by the ASF.
>>>>>
>>>>> ###############
>>>>>
>>>>> The way I'm interpreting this situation is:
>>>>>
>>>>> - We can't do (1)
>>>>> - We can do (2) or (3)
>>>>>
>>>>> Based on what you are saying about access to the library, I think that
>>>>> Netapp has excluded us from option 3.
>>>>>
>>>>> So we're left with option 2... we can provide instructions for how to
>>>>> get access to the library, and how to build CloudStack in a way that
>>>>> would use the library.
>>>>>
>>>>> Am I interpreting all of this correctly?
>>>>
>>>> I think that's right. Anyone using NetApp is going to need to get the SDK for themselves. There are lots of terms in that license that Apache could never agree to. For example, the Licensee Indemnity clause requires the licensee (i.e. ASF) to indemnify NetApp against any damages. It also says that the terms of the license are confidential, which means that even this email is in violation of their license.
>>>>
>>>> Unless NetApp change their SDK terms drastically, there's no way that we can ship their software. Option 2) is the only one open to us.
>>>>
>>>> Cheers,
>>>>
>>>> Ewan.
>>>
>>>
>>> After giving that a closer look, I concur. Would be nice if we have a section in the docs or wiki listing any pieces of functionality a user could enable and what they have to do to get there
>>>
>>> John
>>>
>>>
>>
>> Are you willing to start building this? We are likely to have lots of
>> optional code paths. I think this can start as a wiki page and after
>> we know everything we can make it into the more official docs.
>
> Teaches me for suggesting something. ;) Yes, I'll start working on a page in the new wiki later today.
>
> John
>
John,
As you document the optional items, would you mind updating the status
column on this page:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Moving+dependencies+to+ASF+approved+licenses
Something like "optional" would suffice.
Thanks a ton!
-chip
Re: [DISCUSS] Dropping NetApp Support
Posted by John Kinsella <jl...@stratosec.co>.
On Aug 9, 2012, at 3:55 AM, David Nalley wrote:
> On Wed, Aug 8, 2012 at 6:03 PM, John Kinsella <jl...@stratosec.co> wrote:
>>
>> On Aug 8, 2012, at 2:51 PM, Ewan Mellor wrote:
>>
>>>> -----Original Message-----
>>>> From: Chip Childers [mailto:chip.childers@sungard.com]
>>>> Sent: Wednesday, August 08, 2012 12:31 PM
>>>> To: cloudstack-dev@incubator.apache.org
>>>> Subject: Re: [DISCUSS] Dropping NetApp Support
>>>>
>>>> On Wed, Aug 8, 2012 at 1:56 PM, John Kinsella <jl...@stratosec.co> wrote:
>>>>> I reached out to some contacts at NetApp, their product management
>>>> team quoted the following part of their "NETAPP MANAGEABILITY SDK -
>>>> EULA.docx"[1] to me:
>>>>>
>>>>> "Subject to the terms and conditions set forth herein, NetApp grants
>>>> You a license to:...Use, reproduce and distribute the Language
>>>> Libraries in object code form (for C/C++, Java, C#, VB.NET and
>>>> PowerShell only) and source code form (for Perl, Python and Ruby only)
>>>> as incorporated into the Licensee Application; provided, however, that
>>>> You (A) reproduce and include the copyright notice that appears in the
>>>> Language Libraries as provided by NetApp, and (B) distribute the
>>>> Licensee Application incorporating the Language Libraries pursuant to
>>>> terms no less restrictive than those set forth herein. You shall not
>>>> modify the Language Libraries; and..."
>>>>>
>>>>> Not that we want to distribute jars in the source, I was told they
>>>> don't have an "open source" license so this wouldn't fly with ASL, but
>>>> perhaps we could provide the library as part of the "convenience
>>>> builds?"
>>>>>
>>>>> John
>>>>> 1: I can forward the docx to the list or put it up somewhere if
>>>> there's interest
>>>>
>>>> John,
>>>>
>>>> I think we may not be able to distribute this, even within a
>>>> convenience binary. From what I can tell, this is basically falling
>>>> into "Category X", which the ASF has explicitly stated that no project
>>>> can distribute source OR binary distributions that contain prohibited
>>>> works. I think we can also assume that we can't make it a "system
>>>> dependency" for the project (stating the obvious here). The policy
>>>> goes on to offer three suggestions for how to help users optionally
>>>> make use of the prohibited work:
>>>>
>>>> ###############
>>>>
>>>> If a PMC wishes to allow optional add-ons to enhance the functionality
>>>> of the standard Apache product, the following options are available:
>>>>
>>>> 1) For add-ons under authorized licenses, the add-on could be
>>>> distributed inside the product (see forthcoming policy on "Receiving
>>>> and Releasing Contributions" for details on how and where to do this).
>>>>
>>>> 2) For add-ons under excluded licenses, the PMC may provide a
>>>> link/reference on the product web site or within product documentation
>>>> to some other web site that hosts such add-ons (e.g. a SF.net project
>>>> or some third-party site dedicated to distributing add-ons for the
>>>> Apache product) as long as it is made clear to users that the host
>>>> site is not part of the Apache product nor endorsed by the ASF.
>>>>
>>>> 3) For add-ons under excluded licenses, the PMC may include a feature
>>>> within the product that allows the user to obtain third-party add-ons
>>>> if the feature also alerts the user of the associated license and
>>>> makes clear to users that the host site is not part of the Apache
>>>> product nor endorsed by the ASF.
>>>>
>>>> ###############
>>>>
>>>> The way I'm interpreting this situation is:
>>>>
>>>> - We can't do (1)
>>>> - We can do (2) or (3)
>>>>
>>>> Based on what you are saying about access to the library, I think that
>>>> Netapp has excluded us from option 3.
>>>>
>>>> So we're left with option 2... we can provide instructions for how to
>>>> get access to the library, and how to build CloudStack in a way that
>>>> would use the library.
>>>>
>>>> Am I interpreting all of this correctly?
>>>
>>> I think that's right. Anyone using NetApp is going to need to get the SDK for themselves. There are lots of terms in that license that Apache could never agree to. For example, the Licensee Indemnity clause requires the licensee (i.e. ASF) to indemnify NetApp against any damages. It also says that the terms of the license are confidential, which means that even this email is in violation of their license.
>>>
>>> Unless NetApp change their SDK terms drastically, there's no way that we can ship their software. Option 2) is the only one open to us.
>>>
>>> Cheers,
>>>
>>> Ewan.
>>
>>
>> After giving that a closer look, I concur. Would be nice if we have a section in the docs or wiki listing any pieces of functionality a user could enable and what they have to do to get there
>>
>> John
>>
>>
>
> Are you willing to start building this? We are likely to have lots of
> optional code paths. I think this can start as a wiki page and after
> we know everything we can make it into the more official docs.
Teaches me for suggesting something. ;) Yes, I'll start working on a page in the new wiki later today.
John
Re: [DISCUSS] Dropping NetApp Support
Posted by David Nalley <da...@gnsa.us>.
On Wed, Aug 8, 2012 at 6:03 PM, John Kinsella <jl...@stratosec.co> wrote:
>
> On Aug 8, 2012, at 2:51 PM, Ewan Mellor wrote:
>
>>> -----Original Message-----
>>> From: Chip Childers [mailto:chip.childers@sungard.com]
>>> Sent: Wednesday, August 08, 2012 12:31 PM
>>> To: cloudstack-dev@incubator.apache.org
>>> Subject: Re: [DISCUSS] Dropping NetApp Support
>>>
>>> On Wed, Aug 8, 2012 at 1:56 PM, John Kinsella <jl...@stratosec.co> wrote:
>>>> I reached out to some contacts at NetApp, their product management
>>> team quoted the following part of their "NETAPP MANAGEABILITY SDK -
>>> EULA.docx"[1] to me:
>>>>
>>>> "Subject to the terms and conditions set forth herein, NetApp grants
>>> You a license to:...Use, reproduce and distribute the Language
>>> Libraries in object code form (for C/C++, Java, C#, VB.NET and
>>> PowerShell only) and source code form (for Perl, Python and Ruby only)
>>> as incorporated into the Licensee Application; provided, however, that
>>> You (A) reproduce and include the copyright notice that appears in the
>>> Language Libraries as provided by NetApp, and (B) distribute the
>>> Licensee Application incorporating the Language Libraries pursuant to
>>> terms no less restrictive than those set forth herein. You shall not
>>> modify the Language Libraries; and..."
>>>>
>>>> Not that we want to distribute jars in the source, I was told they
>>> don't have an "open source" license so this wouldn't fly with ASL, but
>>> perhaps we could provide the library as part of the "convenience
>>> builds?"
>>>>
>>>> John
>>>> 1: I can forward the docx to the list or put it up somewhere if
>>> there's interest
>>>
>>> John,
>>>
>>> I think we may not be able to distribute this, even within a
>>> convenience binary. From what I can tell, this is basically falling
>>> into "Category X", which the ASF has explicitly stated that no project
>>> can distribute source OR binary distributions that contain prohibited
>>> works. I think we can also assume that we can't make it a "system
>>> dependency" for the project (stating the obvious here). The policy
>>> goes on to offer three suggestions for how to help users optionally
>>> make use of the prohibited work:
>>>
>>> ###############
>>>
>>> If a PMC wishes to allow optional add-ons to enhance the functionality
>>> of the standard Apache product, the following options are available:
>>>
>>> 1) For add-ons under authorized licenses, the add-on could be
>>> distributed inside the product (see forthcoming policy on "Receiving
>>> and Releasing Contributions" for details on how and where to do this).
>>>
>>> 2) For add-ons under excluded licenses, the PMC may provide a
>>> link/reference on the product web site or within product documentation
>>> to some other web site that hosts such add-ons (e.g. a SF.net project
>>> or some third-party site dedicated to distributing add-ons for the
>>> Apache product) as long as it is made clear to users that the host
>>> site is not part of the Apache product nor endorsed by the ASF.
>>>
>>> 3) For add-ons under excluded licenses, the PMC may include a feature
>>> within the product that allows the user to obtain third-party add-ons
>>> if the feature also alerts the user of the associated license and
>>> makes clear to users that the host site is not part of the Apache
>>> product nor endorsed by the ASF.
>>>
>>> ###############
>>>
>>> The way I'm interpreting this situation is:
>>>
>>> - We can't do (1)
>>> - We can do (2) or (3)
>>>
>>> Based on what you are saying about access to the library, I think that
>>> Netapp has excluded us from option 3.
>>>
>>> So we're left with option 2... we can provide instructions for how to
>>> get access to the library, and how to build CloudStack in a way that
>>> would use the library.
>>>
>>> Am I interpreting all of this correctly?
>>
>> I think that's right. Anyone using NetApp is going to need to get the SDK for themselves. There are lots of terms in that license that Apache could never agree to. For example, the Licensee Indemnity clause requires the licensee (i.e. ASF) to indemnify NetApp against any damages. It also says that the terms of the license are confidential, which means that even this email is in violation of their license.
>>
>> Unless NetApp change their SDK terms drastically, there's no way that we can ship their software. Option 2) is the only one open to us.
>>
>> Cheers,
>>
>> Ewan.
>
>
> After giving that a closer look, I concur. Would be nice if we have a section in the docs or wiki listing any pieces of functionality a user could enable and what they have to do to get there
>
> John
>
>
Are you willing to start building this? We are likely to have lots of
optional code paths. I think this can start as a wiki page and after
we know everything we can make it into the more official docs.
--David
Re: [DISCUSS] Dropping NetApp Support
Posted by John Kinsella <jl...@stratosec.co>.
On Aug 8, 2012, at 2:51 PM, Ewan Mellor wrote:
>> -----Original Message-----
>> From: Chip Childers [mailto:chip.childers@sungard.com]
>> Sent: Wednesday, August 08, 2012 12:31 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: [DISCUSS] Dropping NetApp Support
>>
>> On Wed, Aug 8, 2012 at 1:56 PM, John Kinsella <jl...@stratosec.co> wrote:
>>> I reached out to some contacts at NetApp, their product management
>> team quoted the following part of their "NETAPP MANAGEABILITY SDK -
>> EULA.docx"[1] to me:
>>>
>>> "Subject to the terms and conditions set forth herein, NetApp grants
>> You a license to:...Use, reproduce and distribute the Language
>> Libraries in object code form (for C/C++, Java, C#, VB.NET and
>> PowerShell only) and source code form (for Perl, Python and Ruby only)
>> as incorporated into the Licensee Application; provided, however, that
>> You (A) reproduce and include the copyright notice that appears in the
>> Language Libraries as provided by NetApp, and (B) distribute the
>> Licensee Application incorporating the Language Libraries pursuant to
>> terms no less restrictive than those set forth herein. You shall not
>> modify the Language Libraries; and..."
>>>
>>> Not that we want to distribute jars in the source, I was told they
>> don't have an "open source" license so this wouldn't fly with ASL, but
>> perhaps we could provide the library as part of the "convenience
>> builds?"
>>>
>>> John
>>> 1: I can forward the docx to the list or put it up somewhere if
>> there's interest
>>
>> John,
>>
>> I think we may not be able to distribute this, even within a
>> convenience binary. From what I can tell, this is basically falling
>> into "Category X", which the ASF has explicitly stated that no project
>> can distribute source OR binary distributions that contain prohibited
>> works. I think we can also assume that we can't make it a "system
>> dependency" for the project (stating the obvious here). The policy
>> goes on to offer three suggestions for how to help users optionally
>> make use of the prohibited work:
>>
>> ###############
>>
>> If a PMC wishes to allow optional add-ons to enhance the functionality
>> of the standard Apache product, the following options are available:
>>
>> 1) For add-ons under authorized licenses, the add-on could be
>> distributed inside the product (see forthcoming policy on "Receiving
>> and Releasing Contributions" for details on how and where to do this).
>>
>> 2) For add-ons under excluded licenses, the PMC may provide a
>> link/reference on the product web site or within product documentation
>> to some other web site that hosts such add-ons (e.g. a SF.net project
>> or some third-party site dedicated to distributing add-ons for the
>> Apache product) as long as it is made clear to users that the host
>> site is not part of the Apache product nor endorsed by the ASF.
>>
>> 3) For add-ons under excluded licenses, the PMC may include a feature
>> within the product that allows the user to obtain third-party add-ons
>> if the feature also alerts the user of the associated license and
>> makes clear to users that the host site is not part of the Apache
>> product nor endorsed by the ASF.
>>
>> ###############
>>
>> The way I'm interpreting this situation is:
>>
>> - We can't do (1)
>> - We can do (2) or (3)
>>
>> Based on what you are saying about access to the library, I think that
>> Netapp has excluded us from option 3.
>>
>> So we're left with option 2... we can provide instructions for how to
>> get access to the library, and how to build CloudStack in a way that
>> would use the library.
>>
>> Am I interpreting all of this correctly?
>
> I think that's right. Anyone using NetApp is going to need to get the SDK for themselves. There are lots of terms in that license that Apache could never agree to. For example, the Licensee Indemnity clause requires the licensee (i.e. ASF) to indemnify NetApp against any damages. It also says that the terms of the license are confidential, which means that even this email is in violation of their license.
>
> Unless NetApp change their SDK terms drastically, there's no way that we can ship their software. Option 2) is the only one open to us.
>
> Cheers,
>
> Ewan.
After giving that a closer look, I concur. Would be nice if we have a section in the docs or wiki listing any pieces of functionality a user could enable and what they have to do to get there
John
RE: [DISCUSS] Dropping NetApp Support
Posted by Ewan Mellor <Ew...@eu.citrix.com>.
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Wednesday, August 08, 2012 12:31 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] Dropping NetApp Support
>
> On Wed, Aug 8, 2012 at 1:56 PM, John Kinsella <jl...@stratosec.co> wrote:
> > I reached out to some contacts at NetApp, their product management
> team quoted the following part of their "NETAPP MANAGEABILITY SDK -
> EULA.docx"[1] to me:
> >
> > "Subject to the terms and conditions set forth herein, NetApp grants
> You a license to:...Use, reproduce and distribute the Language
> Libraries in object code form (for C/C++, Java, C#, VB.NET and
> PowerShell only) and source code form (for Perl, Python and Ruby only)
> as incorporated into the Licensee Application; provided, however, that
> You (A) reproduce and include the copyright notice that appears in the
> Language Libraries as provided by NetApp, and (B) distribute the
> Licensee Application incorporating the Language Libraries pursuant to
> terms no less restrictive than those set forth herein. You shall not
> modify the Language Libraries; and..."
> >
> > Not that we want to distribute jars in the source, I was told they
> don't have an "open source" license so this wouldn't fly with ASL, but
> perhaps we could provide the library as part of the "convenience
> builds?"
> >
> > John
> > 1: I can forward the docx to the list or put it up somewhere if
> there's interest
>
> John,
>
> I think we may not be able to distribute this, even within a
> convenience binary. From what I can tell, this is basically falling
> into "Category X", which the ASF has explicitly stated that no project
> can distribute source OR binary distributions that contain prohibited
> works. I think we can also assume that we can't make it a "system
> dependency" for the project (stating the obvious here). The policy
> goes on to offer three suggestions for how to help users optionally
> make use of the prohibited work:
>
> ###############
>
> If a PMC wishes to allow optional add-ons to enhance the functionality
> of the standard Apache product, the following options are available:
>
> 1) For add-ons under authorized licenses, the add-on could be
> distributed inside the product (see forthcoming policy on "Receiving
> and Releasing Contributions" for details on how and where to do this).
>
> 2) For add-ons under excluded licenses, the PMC may provide a
> link/reference on the product web site or within product documentation
> to some other web site that hosts such add-ons (e.g. a SF.net project
> or some third-party site dedicated to distributing add-ons for the
> Apache product) as long as it is made clear to users that the host
> site is not part of the Apache product nor endorsed by the ASF.
>
> 3) For add-ons under excluded licenses, the PMC may include a feature
> within the product that allows the user to obtain third-party add-ons
> if the feature also alerts the user of the associated license and
> makes clear to users that the host site is not part of the Apache
> product nor endorsed by the ASF.
>
> ###############
>
> The way I'm interpreting this situation is:
>
> - We can't do (1)
> - We can do (2) or (3)
>
> Based on what you are saying about access to the library, I think that
> Netapp has excluded us from option 3.
>
> So we're left with option 2... we can provide instructions for how to
> get access to the library, and how to build CloudStack in a way that
> would use the library.
>
> Am I interpreting all of this correctly?
I think that's right. Anyone using NetApp is going to need to get the SDK for themselves. There are lots of terms in that license that Apache could never agree to. For example, the Licensee Indemnity clause requires the licensee (i.e. ASF) to indemnify NetApp against any damages. It also says that the terms of the license are confidential, which means that even this email is in violation of their license.
Unless NetApp change their SDK terms drastically, there's no way that we can ship their software. Option 2) is the only one open to us.
Cheers,
Ewan.
Re: [DISCUSS] Dropping NetApp Support
Posted by Chip Childers <ch...@sungard.com>.
On Wed, Aug 8, 2012 at 1:56 PM, John Kinsella <jl...@stratosec.co> wrote:
> I reached out to some contacts at NetApp, their product management team quoted the following part of their "NETAPP MANAGEABILITY SDK - EULA.docx"[1] to me:
>
> "Subject to the terms and conditions set forth herein, NetApp grants You a license to:...Use, reproduce and distribute the Language Libraries in object code form (for C/C++, Java, C#, VB.NET and PowerShell only) and source code form (for Perl, Python and Ruby only) as incorporated into the Licensee Application; provided, however, that You (A) reproduce and include the copyright notice that appears in the Language Libraries as provided by NetApp, and (B) distribute the Licensee Application incorporating the Language Libraries pursuant to terms no less restrictive than those set forth herein. You shall not modify the Language Libraries; and..."
>
> Not that we want to distribute jars in the source, I was told they don't have an "open source" license so this wouldn't fly with ASL, but perhaps we could provide the library as part of the "convenience builds?"
>
> John
> 1: I can forward the docx to the list or put it up somewhere if there's interest
John,
I think we may not be able to distribute this, even within a
convenience binary. From what I can tell, this is basically falling
into "Category X", which the ASF has explicitly stated that no project
can distribute source OR binary distributions that contain prohibited
works. I think we can also assume that we can't make it a "system
dependency" for the project (stating the obvious here). The policy
goes on to offer three suggestions for how to help users optionally
make use of the prohibited work:
###############
If a PMC wishes to allow optional add-ons to enhance the functionality
of the standard Apache product, the following options are available:
1) For add-ons under authorized licenses, the add-on could be
distributed inside the product (see forthcoming policy on "Receiving
and Releasing Contributions" for details on how and where to do this).
2) For add-ons under excluded licenses, the PMC may provide a
link/reference on the product web site or within product documentation
to some other web site that hosts such add-ons (e.g. a SF.net project
or some third-party site dedicated to distributing add-ons for the
Apache product) as long as it is made clear to users that the host
site is not part of the Apache product nor endorsed by the ASF.
3) For add-ons under excluded licenses, the PMC may include a feature
within the product that allows the user to obtain third-party add-ons
if the feature also alerts the user of the associated license and
makes clear to users that the host site is not part of the Apache
product nor endorsed by the ASF.
###############
The way I'm interpreting this situation is:
- We can't do (1)
- We can do (2) or (3)
Based on what you are saying about access to the library, I think that
Netapp has excluded us from option 3.
So we're left with option 2... we can provide instructions for how to
get access to the library, and how to build CloudStack in a way that
would use the library.
Am I interpreting all of this correctly?
-chip
> On Jul 30, 2012, at 6:45 AM, Hugo Trippaers wrote:
>
>> Hey David,
>>
>> This the part from the SLA regarding distribution of the netapp SDK:
>> -- snip --
>> No distribution or redistribution rights are granted by this license, except as specified in this paragraph. Notwithstanding the terms of this Agreement to the contrary, certain of the components of the Product may be redistributed by you to the extent required for the permitted operation of the derivative work created by you while using the Software hereunder. The specific components permitted for redistribution are limited to those which are compiled as part of the derivative work and distributed by you only in conjunction with or embedded with your product and not as a stand-alone product of the redistributed components. Other components such as printed materials, code samples, SNMP MIB files and "online" or electronic documentation, accompanying the particular embodiment of the Software may not be distributed or redistributed.
>> -- end snip --
>>
>> If I read this correctly (mind you I'm no lawyer) this means that we can't redistribute the compiled jars unless we (meaning the ASF) are granted the use of the Manage ONTAP SDK. If we were granted that use we could distribute the jar.
>>
>> As far as I know the manage ontap SDK is available to everyone with a valid NetApp support contract, so interested parties with a NetApp contract could be pointed to the correct spot on the netapp support site should they wish to use the CloudStack netapp plugin.
>>
>> Cheers,
>>
>> Hugo
>>
>>
>> -----Original Message-----
>> From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
>> Sent: Sunday, July 29, 2012 10:23 AM
>> To: <cl...@incubator.apache.org>
>> Subject: Re: [DISCUSS] Dropping NetApp Support
>>
>> Hey David,
>>
>> I'm sure it not open source, but if you want I can check the distribution license tomorrow. I have the access required.
>>
>> Hugo
>>
>> Sent from my iPhone
>>
>> On 28 jul. 2012, at 03:25, "David Nalley" <da...@gnsa.us> wrote:
>>
>>> Hi folks,
>>>
>>> As I noted in an earlier email, I've been playing with dependencies
>>> this evening.
>>>
>>> one of those dependencies is manageontap.jar, which is part of the NM
>>> SDK from NetApp. Sadly I can't get to the license terms for this
>>> particular library as it's behind a paywall. This leads me to believe
>>> that it's not open source, though perhaps it has a freely
>>> redistributable license. Who knows.
>>>
>>> Now that Murali and Alex and others have done lots of work to get
>>> things pretty modular, it's pretty easy to remove this from the
>>> default build, so I propose we drop the jar (no real choice about
>>> that), make this a non-default build path, and perhaps include
>>> instructions on how to download the jar (though someone else would
>>> have to do that) and build the plugin if needed.
>>>
>>> If I don't hear any backlash, I'll make this part of my ant dependency
>>> download target.
>>>
>>> --David.
>>
>
> Stratosec - Secure Infrastructure as a Service
> o: 415.315.9385
> @johnlkinsella
>
Re: [DISCUSS] Dropping NetApp Support
Posted by John Kinsella <jl...@stratosec.co>.
I reached out to some contacts at NetApp, their product management team quoted the following part of their "NETAPP MANAGEABILITY SDK - EULA.docx"[1] to me:
"Subject to the terms and conditions set forth herein, NetApp grants You a license to:...Use, reproduce and distribute the Language Libraries in object code form (for C/C++, Java, C#, VB.NET and PowerShell only) and source code form (for Perl, Python and Ruby only) as incorporated into the Licensee Application; provided, however, that You (A) reproduce and include the copyright notice that appears in the Language Libraries as provided by NetApp, and (B) distribute the Licensee Application incorporating the Language Libraries pursuant to terms no less restrictive than those set forth herein. You shall not modify the Language Libraries; and..."
Not that we want to distribute jars in the source, I was told they don't have an "open source" license so this wouldn't fly with ASL, but perhaps we could provide the library as part of the "convenience builds?"
John
1: I can forward the docx to the list or put it up somewhere if there's interest
On Jul 30, 2012, at 6:45 AM, Hugo Trippaers wrote:
> Hey David,
>
> This the part from the SLA regarding distribution of the netapp SDK:
> -- snip --
> No distribution or redistribution rights are granted by this license, except as specified in this paragraph. Notwithstanding the terms of this Agreement to the contrary, certain of the components of the Product may be redistributed by you to the extent required for the permitted operation of the derivative work created by you while using the Software hereunder. The specific components permitted for redistribution are limited to those which are compiled as part of the derivative work and distributed by you only in conjunction with or embedded with your product and not as a stand-alone product of the redistributed components. Other components such as printed materials, code samples, SNMP MIB files and "online" or electronic documentation, accompanying the particular embodiment of the Software may not be distributed or redistributed.
> -- end snip --
>
> If I read this correctly (mind you I'm no lawyer) this means that we can't redistribute the compiled jars unless we (meaning the ASF) are granted the use of the Manage ONTAP SDK. If we were granted that use we could distribute the jar.
>
> As far as I know the manage ontap SDK is available to everyone with a valid NetApp support contract, so interested parties with a NetApp contract could be pointed to the correct spot on the netapp support site should they wish to use the CloudStack netapp plugin.
>
> Cheers,
>
> Hugo
>
>
> -----Original Message-----
> From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
> Sent: Sunday, July 29, 2012 10:23 AM
> To: <cl...@incubator.apache.org>
> Subject: Re: [DISCUSS] Dropping NetApp Support
>
> Hey David,
>
> I'm sure it not open source, but if you want I can check the distribution license tomorrow. I have the access required.
>
> Hugo
>
> Sent from my iPhone
>
> On 28 jul. 2012, at 03:25, "David Nalley" <da...@gnsa.us> wrote:
>
>> Hi folks,
>>
>> As I noted in an earlier email, I've been playing with dependencies
>> this evening.
>>
>> one of those dependencies is manageontap.jar, which is part of the NM
>> SDK from NetApp. Sadly I can't get to the license terms for this
>> particular library as it's behind a paywall. This leads me to believe
>> that it's not open source, though perhaps it has a freely
>> redistributable license. Who knows.
>>
>> Now that Murali and Alex and others have done lots of work to get
>> things pretty modular, it's pretty easy to remove this from the
>> default build, so I propose we drop the jar (no real choice about
>> that), make this a non-default build path, and perhaps include
>> instructions on how to download the jar (though someone else would
>> have to do that) and build the plugin if needed.
>>
>> If I don't hear any backlash, I'll make this part of my ant dependency
>> download target.
>>
>> --David.
>
Stratosec - Secure Infrastructure as a Service
o: 415.315.9385
@johnlkinsella
RE: [DISCUSS] Dropping NetApp Support
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
Hey David,
This the part from the SLA regarding distribution of the netapp SDK:
-- snip --
No distribution or redistribution rights are granted by this license, except as specified in this paragraph. Notwithstanding the terms of this Agreement to the contrary, certain of the components of the Product may be redistributed by you to the extent required for the permitted operation of the derivative work created by you while using the Software hereunder. The specific components permitted for redistribution are limited to those which are compiled as part of the derivative work and distributed by you only in conjunction with or embedded with your product and not as a stand-alone product of the redistributed components. Other components such as printed materials, code samples, SNMP MIB files and "online" or electronic documentation, accompanying the particular embodiment of the Software may not be distributed or redistributed.
-- end snip --
If I read this correctly (mind you I'm no lawyer) this means that we can't redistribute the compiled jars unless we (meaning the ASF) are granted the use of the Manage ONTAP SDK. If we were granted that use we could distribute the jar.
As far as I know the manage ontap SDK is available to everyone with a valid NetApp support contract, so interested parties with a NetApp contract could be pointed to the correct spot on the netapp support site should they wish to use the CloudStack netapp plugin.
Cheers,
Hugo
-----Original Message-----
From: Hugo Trippaers [mailto:HTrippaers@schubergphilis.com]
Sent: Sunday, July 29, 2012 10:23 AM
To: <cl...@incubator.apache.org>
Subject: Re: [DISCUSS] Dropping NetApp Support
Hey David,
I'm sure it not open source, but if you want I can check the distribution license tomorrow. I have the access required.
Hugo
Sent from my iPhone
On 28 jul. 2012, at 03:25, "David Nalley" <da...@gnsa.us> wrote:
> Hi folks,
>
> As I noted in an earlier email, I've been playing with dependencies
> this evening.
>
> one of those dependencies is manageontap.jar, which is part of the NM
> SDK from NetApp. Sadly I can't get to the license terms for this
> particular library as it's behind a paywall. This leads me to believe
> that it's not open source, though perhaps it has a freely
> redistributable license. Who knows.
>
> Now that Murali and Alex and others have done lots of work to get
> things pretty modular, it's pretty easy to remove this from the
> default build, so I propose we drop the jar (no real choice about
> that), make this a non-default build path, and perhaps include
> instructions on how to download the jar (though someone else would
> have to do that) and build the plugin if needed.
>
> If I don't hear any backlash, I'll make this part of my ant dependency
> download target.
>
> --David.
Re: [DISCUSS] Dropping NetApp Support
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
Hey David,
I'm sure it not open source, but if you want I can check the distribution license tomorrow. I have the access required.
Hugo
Sent from my iPhone
On 28 jul. 2012, at 03:25, "David Nalley" <da...@gnsa.us> wrote:
> Hi folks,
>
> As I noted in an earlier email, I've been playing with dependencies
> this evening.
>
> one of those dependencies is manageontap.jar, which is part of the NM
> SDK from NetApp. Sadly I can't get to the license terms for this
> particular library as it's behind a paywall. This leads me to believe
> that it's not open source, though perhaps it has a freely
> redistributable license. Who knows.
>
> Now that Murali and Alex and others have done lots of work to get
> things pretty modular, it's pretty easy to remove this from the
> default build, so I propose we drop the jar (no real choice about
> that), make this a non-default build path, and perhaps include
> instructions on how to download the jar (though someone else would
> have to do that) and build the plugin if needed.
>
> If I don't hear any backlash, I'll make this part of my ant dependency
> download target.
>
> --David.