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
ns.
* 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
acceptance.
Wido
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/3party.html#category-x>l
[2]http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201206.mbox/%3c35f04d4c394874409d9be4bf45ac5ea9fed4f25...@banpmailbox01.citrite.net%3E