cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <>
Subject Re: dependencies on prohibited license components
Date Mon, 02 Jul 2012 13:21:20 GMT

On 02-07-12 09:20, Murali Reddy wrote:
> Currently CloudStack has dependencies on third party software that are under 'excluded
license' [1] or does not fall under category A/B licenses. While effort in underway [2] to
remove the dependencies, I want to bring to the discussion on what is the best approach for
CloudStack to remove the dependencies. As a orchestration software CloudStack deals/designed
to deal with diverse set of Hypervisors, networking devices and file systems etc. While the
core orchestration software can be made not to depend on the third party software which are
not under ASF license, support for hypervisor etc might require dependency on thirty party
software that are not under ASF friendly license. For e.g. in order to  manage Vmware and
Kvm hypervisors CloudStack is using Vmware and libvirt libraries. While support software for
the Vmware/Kvm can treated as optional components of CloudStack, critical value comes from
these optional components. Given this, following seems to some obvious optio
>   *   Keep CloudStack code that integrates with third party libraries in the repo. But
exclude it from the default build targets. Expect the users/developers to download the compile
dependencies and modify the build settings to include the code. But this will take out the
critical support for Vmware etc in the default build.
>   *   Have the compile tasks pull the dependent components from non-asf repo's. Apache
Cassandra, Hadoop projects seems to have maven/ivy tasks to pull the compile dependencies
on build from remote maven repos. Can third-party software that are not under ASF license
can be hosted on remote repo?

First of all, licenses are not my thing.

You mean for example we pull the libvirt Java bindings with a ant target 
and build them separate?

We could also add the libvirt Java bindings as a sub module?

The problem right now with those bindings is that we have a couple of 
pending patches which need to go upstream before we can use the Java 
bindings from the libvirt website.

Those patches have been send to libvirt already, but are waiting for 


> Perhaps mentors or any one who has knowledge of how other apache projects deal with such
dependencies can share the knowledge.
> [1]<>l
> [2]

View raw message