You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Murali Reddy <Mu...@citrix.com> on 2012/07/02 09:20:28 UTC
dependencies on prohibited license components
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 options.
* 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?
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/%3C35F04D4C394874409D9BE4BF45AC5EA9FED4F2586F@BANPMAILBOX01.citrite.net%3E
Re: dependencies on prohibited license components
Posted by Wido den Hollander <wi...@widodh.nl>.
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/%3C35F04D4C394874409D9BE4BF45AC5EA9FED4F2586F@BANPMAILBOX01.citrite.net%3E
>
>
Re: dependencies on prohibited license components
Posted by Brett Porter <br...@apache.org>.
On 03/07/2012, at 8:15 AM, David Nalley wrote:
> On Mon, Jul 2, 2012 at 6:18 PM, Murali Reddy <Mu...@citrix.com> wrote:
>> On 02/07/12 9:58 AM, "David Nalley" <da...@gnsa.us> wrote:
>>
>>>
>>> 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
>>>
>>
>> I can speak for Vmware. Its the Vmware SDK that CloudStack integrates
>> with. There is no alternatives to replace with.
>>
>
> vijava isn't an option?
> http://vijava.sourceforge.net
>
> I know, I have asked this a dozen times :)
That's probably valuable to discuss from a technical end, but it'd be worth figuring out if there's an issue with the current situation too. AFAICT, the VI SDK is a WSDL and some redistributable Java code that was generated with Apache Axis. Is that right?
VMWare and KVM are obvious system dependencies of both integrations, so it seems reasonable to treat them that way, and then figure out how best to enable that feature optionally in the source code release.
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
Re: dependencies on prohibited license components
Posted by David Nalley <da...@gnsa.us>.
On Mon, Jul 2, 2012 at 6:18 PM, Murali Reddy <Mu...@citrix.com> wrote:
> On 02/07/12 9:58 AM, "David Nalley" <da...@gnsa.us> wrote:
>
>>
>>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
>>
>
> I can speak for Vmware. Its the Vmware SDK that CloudStack integrates
> with. There is no alternatives to replace with.
>
vijava isn't an option?
http://vijava.sourceforge.net
I know, I have asked this a dozen times :)
Re: dependencies on prohibited license components
Posted by Murali Reddy <Mu...@citrix.com>.
On 02/07/12 9:58 AM, "David Nalley" <da...@gnsa.us> wrote:
>
>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
>
I can speak for Vmware. Its the Vmware SDK that CloudStack integrates
with. There is no alternatives to replace with.
Re: dependencies on prohibited license components
Posted by David Nalley <da...@gnsa.us>.
On Mon, Jul 2, 2012 at 3:20 AM, Murali Reddy <Mu...@citrix.com> 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 options.
>
> * 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?
>
> 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/%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