incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Kinsella <...@stratosec.co>
Subject Re: [DISCUSS] Dropping NetApp Support
Date Wed, 08 Aug 2012 22:03:49 GMT

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 <jlk@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



Mime
View raw message