Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
Date: Thu, 23 Aug 2012 11:43:42 +1100 (NCT)
From: "Sam Ruby (JIRA)" <jira@apache.org>
To: legal-discuss@apache.org
Message-ID: <1648501100.3556.1345682622363.JavaMail.jiratomcat@arcas>
In-Reply-To: <1104656199.12195.1344029702707.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Assigned] (LEGAL-144) Request for permission for CloudStack
 to distribute secondary convenience builds containing libvirt-java (LGPL)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/LEGAL-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sam Ruby reassigned LEGAL-144:
------------------------------

    Assignee: Sam Ruby
    
> Request for permission for CloudStack to distribute secondary convenience builds containing libvirt-java (LGPL)
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: LEGAL-144
>                 URL: https://issues.apache.org/jira/browse/LEGAL-144
>             Project: Legal Discuss
>          Issue Type: Question
>            Reporter: Ewan Mellor
>            Assignee: Sam Ruby
>
> This ticket is a request from the CloudStack project (currently in incubation) for an exception to the written policy on LGPL-licensed software.
> Background
> =========
> CloudStack is an infrastructure-as-a-service orchestration and management engine. It co-ordinates hypervisors, networking, and storage elements to create a multi-tenant cloud.  It does not actually provide compute, networking or storage services, but it calls out to them and manages them in a co-ordinated manner.
> Managing hypervisors is a critical part of CloudStack.  Each supported hypervisor (XenServer, KVM, VMware ESXi, etc) is managed through the hypervisor's specific API.
> Support for KVM is a non-essential but very important feature for CloudStack.  Non-essential in the sense that it is possible to use a different hypervisor, but very important given KVM's importance as a hypervisor in general, and more specifically as the Linux kernel's offical hypervisor.
> It is important to us that KVM and XenServer are equally easy to use with CloudStack.  However, libvirt-java (the official libvirt / KVM Java SDK) is licensed under the LGPL 2.1, whereas XenServerJava (the official XenServer Java SDK) is licensed under Apache 2.0 terms.  This means that Apache policy makes it harder to use KVM than XenServer, because KVM support must be turned off in the default build.  We are looking to mitigate that problem as far as possible.
> Note that there is a political element to this too: Citrix (owners of XenServer and original donors of CloudStack to Apache) has been able to re-license XenServerJava to suit CloudStack and the Apache Foundation policies.  This may create the appearance of bias towards XenServer rather than KVM, even though no such bias is intended.
> libvirt-java is not commonly distributed with Linux distros today (it is not in Ubuntu 12.04 for example) and we require very recent releases in any case.  It is therefore not possible for us to treat it as a System Dependency as we understand the term.
> Work so far
> ========
> CloudStack plans to release version 4.0 as soon as possible.  This will be the first release as an Apache-incubated project.  The 3.x series of releases were all under Citrix / cloud.com control.
> CloudStack has been refactored so that hypervisor-specific code is contained in plugins, and hypervisor support can be turned on and off in the build.  (This work is in the final stages, and will be completed for the CloudStack 4.0 release.)
> Our understanding of Apache policy is that KVM support must be turned off in the default build, because it is a non-compulsory component and it has a dependency on Category X software.
> Convenience builds
> ==============
> The CloudStack build is very complex.  Given this, we would like to distribute binaries for the convenience of our users.  These would be built from the official source releases and made available for download.
> Our understanding is that this is already accepted under Apache policy in cases where the builds include only Category A software.
> Proposal
> =======
> 1. Disable KVM support in the default build, as per policy.
> 2. Distribute binaries from a convenience build that matches the default build.
> 3. Distribute a secondary convenience build with KVM support turned on.  This requires an exception to policy, which we are asking permission for now.
> The secondary convenience build would:
> 1. include libvirt-java binaries, unmodified from their released form;
> 2. be clearly flagged as a non-default build;
> 3. be clearly flagged as not pure Apache-licensed software;
> 4. be accompanied by the unmodified libvirt-java source code corresponding to the binaries that we distribute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org