Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <CC167D35.14D80%murali.reddy@citrix.com>
References: <CC167D35.14D80%murali.reddy@citrix.com>
From: David Nalley <david@gnsa.us>
Date: Mon, 2 Jul 2012 12:58:15 -0400
Message-ID: 
 <CAKprHVbmfxXZPJUHpbkSF96tg77=PmC-am5cSKqxTE4ntwMazA@mail.gmail.com>
Subject: Re: dependencies on prohibited license components
To: cloudstack-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 2, 2012 at 3:20 AM, Murali Reddy <Murali.Reddy@citrix.com> wrot=
e:
> Currently CloudStack has dependencies on third party software that are un=
der 'excluded license' [1] or does not fall under category A/B licenses. Wh=
ile effort in underway [2] to remove the dependencies, I want to bring to t=
he discussion on what is the best approach for CloudStack to remove the dep=
endencies. As a orchestration software CloudStack deals/designed to deal wi=
th diverse set of Hypervisors, networking devices and file systems etc. Whi=
le the core orchestration software can be made not to depend on the third p=
arty software which are not under ASF license, support for hypervisor etc m=
ight require dependency on thirty party software that are not under ASF fri=
endly license. For e.g. in order to  manage Vmware and Kvm hypervisors Clou=
dStack is using Vmware and libvirt libraries. While support software for th=
e Vmware/Kvm can treated as optional components of CloudStack, critical val=
ue comes from these optional components. Given this, following seems to som=
e obvious options.
>
>  *   Keep CloudStack code that integrates with third party libraries in t=
he repo. But exclude it from the default build targets. Expect the users/de=
velopers to download the compile dependencies and modify the build settings=
 to include the code. But this will take out the critical support for Vmwar=
e etc in the default build.
>  *   Have the compile tasks pull the dependent components from non-asf re=
po's. Apache Cassandra, Hadoop projects seems to have maven/ivy tasks to pu=
ll the compile dependencies on build from remote maven repos. Can third-par=
ty software that are not under ASF license can be hosted on remote repo?
>
> Perhaps mentors or any one who has knowledge of how other apache projects=
 deal with such dependencies can share the knowledge.
>
> [1]http://www.apache.org/legal/3party.htm<http://www.apache.org/legal/3pa=
rty.html#category-x>l
> [2]http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/2012=
06.mbox/%3C35F04D4C394874409D9BE4BF45AC5EA9FED4F2586F@BANPMAILBOX01.citrite=
.net%3E
>


Murali,

Thanks for bringing this topic to the list.
While I think we need to figure out a general rule, I don't know that
we can apply it universally.  I worry that because there are so many
potential issues - and the potential outcome has not yet been decided
for each that we will end up needing to discuss them specifically.

For instance, we removed jnetpcap altogether as we weren't using it;
do we continue with a dependency on the VMware SDK or do we instead
rip it out and replace it entirely with something else? Is Paramiko
really used or not?

--David