On Fri, May 18, 2012 at 4:37 PM, Robert Schweikert <rjsch...@suse.com> wrote: > On 05/17/2012 01:26 AM, David Nalley wrote: >> >> Hi folks: >> >> I saw the recent changes to the dependency license page[1] and wanted >> to discuss XAPI API - which I think is the xenserver-java package. I >> don't think this is in any of the currently targeted distributions. > > > And I just learned that this is Citrix-Xen specific, which would be a reason > that it is not in any distribution, i.e. no such bindings are part of the > Xen.org code. > > This would imply that there is a potential that CloudStack depends on APIs > that are only available in the Citrix incarnation of Xen. This in turn would > put CS into an unfortunate position as CloudStack will not be able to run on > any distribution that supports Xen (Xen.org origin), but will only be able > to run on distros that also get Citrix-Xen.
Since there seems to be some confusion about the relationship between the Xen hypervisor and Citrix's XenServer, I'll give a quick explanation for those that are curious. Citrix XenServer is essentially a black-box appliance based on the Xen hypervisor and CentOS 5.7. You don't install XenServer on, say, Ubuntu, you just install XenServer itself on your bare machine. XenServer implements its own XML-RPC based API (called XenAPI, or sometimes XAPI) which is different than the Xen hypervisor's API. Citrix XenServer is open source (mostly GPL and LGPL), except for a few proprietary binaries which implement certain paid-for features. The management server that implements the XenAPI is called xapi, and its source code can be found on Github [1]. Recently, xapi and its dependences were ported to run on Debian and Ubuntu. We have published Debian packages to both Debian testing and Ubuntu universe, so that users can install xapi on those OS's. We plan on doing the same for Fedora and CentOS sometime this summer. So, CloudStack can run on both Citrix's XenServer, and on Ubuntu and Debian (with both Xen and xapi installed). > This newly gained insight of course makes some of the earlier comments i > made in this thread useless. What would have to happen is that the > generation code would have to be pushed to Xen.org and CloudStack would have > to limit itself to those APIs. The generation code itself is GPLv2. Is this compatible enough for an Apache project? If not, I see no reason why Citrix wouldn't dual- or re-license this code (I am a Citrix employee, and XenServer engineer, by the way). I also see no reason not to publish the API binding generation source repository to either xenbits.xen.org, or github.com (where most of the Citrix-specific XenServer code is published). Just curious: is there an Apache requirement that this code have a publicly hosted repository somewhere, or is a sufficiently-licensed source drop good enough? >> I >> maintain this package for Fedora and EPEL (so you can install it on >> EL6.2 - but it's using a non-supported yum repo to do so.) Also I >> don't ship the patched version that ships with CloudStack today - I >> build from source as Fedora and EPEL have guidelines around patches, >> one of which requires at least upstreaming patches - and honestly I >> can't even find an upstream repo for it, much less a record of where >> the patches have been upstreamed. >> >> I am pretty certain that aside from my packaging work, no other distro >> has the above package - and a quick google supports that belief. >> >> --David >> >> [1] >> http://wiki.cloudstack.org/display/dev/Moving+dependencies+to+ASF+approved+licenses > > > Based on the above I think there is a lot of clarification necessary w.r.t. > the dependency list and it is necessary to sort out what the Citrix product > will use (Citrix-Xen presumably) and what an open source incarnation of > CloudStack depends on. The generated xenserver-java bindings themselves are licensed under Apache v2. It seems to me that this would be sufficient for including with CloudStack. If not, Citrix will be receptive to modifying the license to either the generated bindings, or the binding generator itself, and also publishing the source repos. Please let me know if there is anything else I can help with here. Mike
