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
