On Wed, Aug 8, 2012 at 6:03 PM, John Kinsella <j...@stratosec.co> wrote: > > On Aug 8, 2012, at 2:51 PM, Ewan Mellor wrote: > >>> -----Original Message----- >>> From: Chip Childers [mailto:chip.child...@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 <j...@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