Hi David, I think I misunderstood the problem. Okay the plugins directory in our repository contains all ASF compliant code. I think the VMWare, NetApp etc. code in plugins are mere wrapper over the actual libraries shipped by respective vendors (I may be wrong, pl. correct me) and they have Apache license too.
The tool I'm using is ASF compliant and opensource and yes anyone can use it to build the plugins artifacts and package them as debs/rpms. Users are free to install cloudstack-plugins but they won't work until they install VMWare, NetApp etc. libraries. We won't be shipping them. Also, we won't be shipping any dependencies until they are available in a distro's repositories. So the control files don't depend on the external proprietary libraries. In that case user has to install the libraries before installing the plugin artifacts. Thanks. Regards, Rohit ________________________________________ From: David Nalley [da...@gnsa.us] Sent: Thursday, September 13, 2012 10:54 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Building debs with Maven On Thu, Sep 13, 2012 at 1:10 PM, Rohit Yadav <rohit.ya...@citrix.com> wrote: > Thanks David for the comments. Alright, in that case, the non-compliant > packages can be shipped as non-oss. > Regards. I am not sure that having two packages (one oss and one nonoss) satisfies the problem. Consider the F5, VMware, NetApp, and Netscaler problem. If I personally wanted to build packages using the tools you are going to use (and everyone should be able to do this, right?) I can consume F5 - it's open source, albeit not ASF-compliant, I have no personal rights to the vmware, netapp or netscaler libraries. If I am using your debian control files to build the nonoss-plugins, it's going to fail because I don't have 3 of the 4 libraries necessary. Besides, why did we go to all of the work of breaking this up if our package build process requires them to all be present. --David
