You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by David Nalley <da...@gnsa.us> on 2012/05/17 07:26:23 UTC
XAPI API (aka xenserver-java)
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. 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
Re: XAPI API (aka xenserver-java)
Posted by Mike McClurg <mi...@gmail.com>.
On Fri, May 18, 2012 at 4:37 PM, Robert Schweikert <rj...@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
Re: XAPI API (aka xenserver-java)
Posted by David Nalley <da...@gnsa.us>.
>
> I suspect we'll have similar issues around vmware - which incidentally
> I didn't see in that list. I'll go add that now.
>
> --David
So on the page - VMware Infrastructure Java API is listed - which is
vijava.sourceforge.net - but unless something has changed really
recently - that's not what we use. I just looked in master and 3.0.x
and found that the VMware SDK (which is gratis to use and
redistribute, but not open source) is still there, and I can't locate
VIjava anywhere in source.
--David
Re: XAPI API (aka xenserver-java)
Posted by David Nalley <da...@gnsa.us>.
On Fri, May 18, 2012 at 11:37 AM, Robert Schweikert <rj...@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.
>
> 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.
>
>
>> 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.
>
I suspect we'll have similar issues around vmware - which incidentally
I didn't see in that list. I'll go add that now.
--David
Re: XAPI API (aka xenserver-java)
Posted by Robert Schweikert <rj...@suse.com>.
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.
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.
> 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.
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147
RE: XAPI API (aka xenserver-java)
Posted by Anthony Xu <Xu...@citrix.com>.
> > Today, CS uses 5.6.100 iirc - in my mind it makes sense to use the
> latest and
> > greatest - but I also am not maintaining the code that does the work.
> Perhaps
> > they will weigh in on the matter.
>
> Anthony, can you comment on this? The question goes back to Mike's
> earlier question:
We did move XAPI version once, from 5.6 GA to 5.6.100.
XAPI used RPC to communicate with XenServer, but there is not RPC timeout in XenServer side.
We added some codes to make RPC client timeout configurable, and we have some other fixes.
XAPI is supposed to be stable, and upgrade to latest version introduces a lot of test effort.
So we are reluctant to upgrade to latest version.
The reason we upgraded to 5.6.100 is,
We found some fixes we did in XAPI 5.6 are already in XAPI 5.6.100, and XAPI 5.6.100 fixed some other issue we want.
To be honestly, we didn't look at XAPI 6.0.* yet.
And we are glad with XAPI 5.6.100.
Thanks
Anthony
> -----Original Message-----
> From: Kevin Kluge
> Sent: Wednesday, May 30, 2012 4:46 PM
> To: cloudstack-dev@incubator.apache.org
> Cc: Anthony Xu
> Subject: RE: XAPI API (aka xenserver-java)
>
> > I can't speak for the folks at the ASF - perhaps asking on legal@ or
> filing a bug
> > in Legal's Jira instance would get you a more qualified response. My
> question
> > on this would be - is there any reason not to release the generating
> code?
>
> I don't see why the generating code needs to be released. CloudStack
> doesn't incorporate it. Also, GPL and other tools are used all the
> time in the development of ASF code...
>
> > Today, CS uses 5.6.100 iirc - in my mind it makes sense to use the
> latest and
> > greatest - but I also am not maintaining the code that does the work.
> Perhaps
> > they will weigh in on the matter.
>
> Anthony, can you comment on this? The question goes back to Mike's
> earlier question:
>
> > > - Will we have to re-license and re-publish previously released
> > > versions of the xenserverjava library? Which versions does
> CloudStack
> > > depend on? Would it instead be sufficient to re-license the library
> in
> > > the next version of XenServer?
>
> Mike, the community wants to get an Apache CloudStack release out
> "quickly" and from what I know of XenServer product timelines they
> would not qualify as "quick". So I'd request that Citrix do a release
> of the XenServerJava library outside the XenServer release framework.
> This could even be a re-release of whatever CloudStack is currently
> using.
>
> -kevin
RE: XAPI API (aka xenserver-java)
Posted by Kevin Kluge <Ke...@citrix.com>.
> I can't speak for the folks at the ASF - perhaps asking on legal@ or filing a bug
> in Legal's Jira instance would get you a more qualified response. My question
> on this would be - is there any reason not to release the generating code?
I don't see why the generating code needs to be released. CloudStack doesn't incorporate it. Also, GPL and other tools are used all the time in the development of ASF code...
> Today, CS uses 5.6.100 iirc - in my mind it makes sense to use the latest and
> greatest - but I also am not maintaining the code that does the work. Perhaps
> they will weigh in on the matter.
Anthony, can you comment on this? The question goes back to Mike's earlier question:
> > - Will we have to re-license and re-publish previously released
> > versions of the xenserverjava library? Which versions does CloudStack
> > depend on? Would it instead be sufficient to re-license the library in
> > the next version of XenServer?
Mike, the community wants to get an Apache CloudStack release out "quickly" and from what I know of XenServer product timelines they would not qualify as "quick". So I'd request that Citrix do a release of the XenServerJava library outside the XenServer release framework. This could even be a re-release of whatever CloudStack is currently using.
-kevin
Re: XAPI API (aka xenserver-java)
Posted by David Nalley <da...@gnsa.us>.
On Sun, May 20, 2012 at 4:02 PM, Mike McClurg <mi...@gmail.com> wrote:
> On Sat, May 19, 2012 at 4:12 AM, David Nalley <da...@gnsa.us> wrote:
>> I just looked at xenserverjava (the version shipped today 5.6.100-1,
>> and 6.0.0-1)
>>
>> However, while there is a copy of ASLv2 in the source, it does so
>> because some dependencies that it uses are licensed under ASLv2, but
>> the actual code itself has only GPLv2 headers.
>
> David,
>
> Thanks for spotting that. As I said, we should have no problem
> changing the license to something more suitable. I have a few
> questions.
>
> - What is the best license to release this software under? I expect
> that a permissive, BSD-like license would be acceptable for the Apache
> Foundation, yes?
>
> - Will it be necessary to also release the API generation code as
> well? This is something I want to do anyway, but I want to know if it
> will be required for the Apache Foundation.
>
> - Will we have to re-license and re-publish previously released
> versions of the xenserverjava library? Which versions does CloudStack
> depend on? Would it instead be sufficient to re-license the library in
> the next version of XenServer?
>
> Thanks,
>
> Mike
Hi Mike:
MIT, BSD and ASLv2 seem reasonable choices - see this page[1] for
details on what is acceptable:
I can't speak for the folks at the ASF - perhaps asking on legal@ or
filing a bug in Legal's Jira instance would get you a more qualified
response. My question on this would be - is there any reason not to
release the generating code?
Today, CS uses 5.6.100 iirc - in my mind it makes sense to use the
latest and greatest - but I also am not maintaining the code that does
the work. Perhaps they will weigh in on the matter.
--David
[1] http://www.apache.org/legal/3party.html#category-a
Re: XAPI API (aka xenserver-java)
Posted by David Nalley <da...@gnsa.us>.
Mike:
Any update on this?
--David
On Mon, Jul 30, 2012 at 8:17 PM, David Nalley <da...@gnsa.us> wrote:
> On Sun, May 20, 2012 at 4:02 PM, Mike McClurg <mi...@gmail.com> wrote:
>> On Sat, May 19, 2012 at 4:12 AM, David Nalley <da...@gnsa.us> wrote:
>>> I just looked at xenserverjava (the version shipped today 5.6.100-1,
>>> and 6.0.0-1)
>>>
>>> However, while there is a copy of ASLv2 in the source, it does so
>>> because some dependencies that it uses are licensed under ASLv2, but
>>> the actual code itself has only GPLv2 headers.
>>
>> David,
>>
>> Thanks for spotting that. As I said, we should have no problem
>> changing the license to something more suitable. I have a few
>> questions.
>>
>> - What is the best license to release this software under? I expect
>> that a permissive, BSD-like license would be acceptable for the Apache
>> Foundation, yes?
>>
>> - Will it be necessary to also release the API generation code as
>> well? This is something I want to do anyway, but I want to know if it
>> will be required for the Apache Foundation.
>>
>> - Will we have to re-license and re-publish previously released
>> versions of the xenserverjava library? Which versions does CloudStack
>> depend on? Would it instead be sufficient to re-license the library in
>> the next version of XenServer?
>>
>> Thanks,
>>
>> Mike
>
> Hey Mike,
>
> Any update on this relicensing issue? We have a proposed code freeze
> in ~1 week, and AFAIK it's been around 2 months since I've seen any
> updates on this.
>
> --David
Re: XAPI API (aka xenserver-java)
Posted by David Nalley <da...@gnsa.us>.
On Sun, May 20, 2012 at 4:02 PM, Mike McClurg <mi...@gmail.com> wrote:
> On Sat, May 19, 2012 at 4:12 AM, David Nalley <da...@gnsa.us> wrote:
>> I just looked at xenserverjava (the version shipped today 5.6.100-1,
>> and 6.0.0-1)
>>
>> However, while there is a copy of ASLv2 in the source, it does so
>> because some dependencies that it uses are licensed under ASLv2, but
>> the actual code itself has only GPLv2 headers.
>
> David,
>
> Thanks for spotting that. As I said, we should have no problem
> changing the license to something more suitable. I have a few
> questions.
>
> - What is the best license to release this software under? I expect
> that a permissive, BSD-like license would be acceptable for the Apache
> Foundation, yes?
>
> - Will it be necessary to also release the API generation code as
> well? This is something I want to do anyway, but I want to know if it
> will be required for the Apache Foundation.
>
> - Will we have to re-license and re-publish previously released
> versions of the xenserverjava library? Which versions does CloudStack
> depend on? Would it instead be sufficient to re-license the library in
> the next version of XenServer?
>
> Thanks,
>
> Mike
Hey Mike,
Any update on this relicensing issue? We have a proposed code freeze
in ~1 week, and AFAIK it's been around 2 months since I've seen any
updates on this.
--David
Re: XAPI API (aka xenserver-java)
Posted by Mike McClurg <mi...@gmail.com>.
On Sat, May 19, 2012 at 4:12 AM, David Nalley <da...@gnsa.us> wrote:
> I just looked at xenserverjava (the version shipped today 5.6.100-1,
> and 6.0.0-1)
>
> However, while there is a copy of ASLv2 in the source, it does so
> because some dependencies that it uses are licensed under ASLv2, but
> the actual code itself has only GPLv2 headers.
David,
Thanks for spotting that. As I said, we should have no problem
changing the license to something more suitable. I have a few
questions.
- What is the best license to release this software under? I expect
that a permissive, BSD-like license would be acceptable for the Apache
Foundation, yes?
- Will it be necessary to also release the API generation code as
well? This is something I want to do anyway, but I want to know if it
will be required for the Apache Foundation.
- Will we have to re-license and re-publish previously released
versions of the xenserverjava library? Which versions does CloudStack
depend on? Would it instead be sufficient to re-license the library in
the next version of XenServer?
Thanks,
Mike
Re: XAPI API (aka xenserver-java)
Posted by David Nalley <da...@gnsa.us>.
On Fri, May 18, 2012 at 6:49 AM, Mike McClurg <mi...@gmail.com> wrote:
> I just checked the XenServer API bindings for Java, and it seems that
> we've dual-licensed them under the LGPLv2 and Apache v2.0 licenses.
> Are there different XenServer API bindings for Java that are licensed
> differently, that I'm not aware of?
Mike:
I just looked at xenserverjava (the version shipped today 5.6.100-1,
and 6.0.0-1)
However, while there is a copy of ASLv2 in the source, it does so
because some dependencies that it uses are licensed under ASLv2, but
the actual code itself has only GPLv2 headers.
Specifically here are two paragraphs from the README.txt in source
package, that explain things a bit better:
XenServerJava is free sofware. You can redistribute and modify it under the
terms of the GNU GPL version 2, with an additional linking exception that
allows its use unmodified within closed-source applications. See LICENSE.txt
for details.
XenServerJava is dependent upon Apache XML-RPC and WS-Commons, both by The
Apache Software Foundation. We would like to thank the ASF and the
Apache XML-RPC development team in particular.
Both are licensed under the Apache Software License 2.0; see
LICENSE.Apache-2.0.txt for details.
Re: XAPI API (aka xenserver-java)
Posted by David Nalley <da...@gnsa.us>.
On Fri, May 18, 2012 at 11:08 AM, Robert Schweikert <rj...@suse.com> wrote:
>
> I know David mentioned he maintains a Fedora package, but this didn't sound
> like a straight forward undertaking.
Robert:
If you are interested, you can find my spec here:
http://ke4qqq.fedorapeople.org/xenserverjava.spec
--David
Re: XAPI API (aka xenserver-java)
Posted by Robert Schweikert <rj...@suse.com>.
On 05/18/2012 10:20 AM, Mike McClurg wrote:
> On Fri, May 18, 2012 at 2:55 PM, Robert Schweikert<rj...@suse.com> wrote:
>> On 05/18/2012 06:49 AM, Mike McClurg wrote:
>>> These bindings are autogenerated, which is why there is no source
>>> repository for them. The license on the API bindings generation code
>>> is GPLv2, so I don't see any reason why we couldn't publish the source
>>> repo for these bindings.
>>
>>
>> But shouldn't the binding generation code then be part of the xen-server
>> source base?
>>
>> I am a bit confused here. It sounds to me that CS depends on Java bindings
>> to Xen-server, yet the bindings are maintained separately from the server
>> code, do I understand this correctly? If this is the case then this is
>> rather strange, I think. For almost every code base that generates language
>> bindings the generation code/templates/setup is part of the cde base in
>> question, why would this be any different for xen-server?
>
> Hi Robert,
>
> Perhaps I should have said that there is no externally visible
> repository for the api binding generation code.
Yes, that much I understood. My contention still is that this binding
generation code should be part of the XenServer source tree. Then when
the XenServer code is built in a distribution the maintainer can simply
enable the generation of the bindings as well. Having the generation
code in a separate repository (than in this case is not public either)
complicates things for distributions.
> Every XenServer (and
> XCP) release will have a corresponding sources ISO, which contains a
> tarball of each of our internal repositories.
>
> We have opened up a few of our development repositories (see
> http://github.com/xen-org/), and I would like to see us open them all
> up. But perhaps this is a conversation best left for a separate
> thread, and perhaps on the xen-api mailing list instead of
> cloudstack-dev.
Well, yes and no. If I cannot stand up a CloudStack cloud without
xenserver-java and I cannot build xenserver-java, as package from source
then CS is for all intends and purposes a closed system and
distributions will not package CS, as the packages they would create
will be useless.
I know David mentioned he maintains a Fedora package, but this didn't
sound like a straight forward undertaking.
Later,
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147
Re: XAPI API (aka xenserver-java)
Posted by Mike McClurg <mi...@gmail.com>.
On Fri, May 18, 2012 at 2:55 PM, Robert Schweikert <rj...@suse.com> wrote:
> On 05/18/2012 06:49 AM, Mike McClurg wrote:
>> These bindings are autogenerated, which is why there is no source
>> repository for them. The license on the API bindings generation code
>> is GPLv2, so I don't see any reason why we couldn't publish the source
>> repo for these bindings.
>
>
> But shouldn't the binding generation code then be part of the xen-server
> source base?
>
> I am a bit confused here. It sounds to me that CS depends on Java bindings
> to Xen-server, yet the bindings are maintained separately from the server
> code, do I understand this correctly? If this is the case then this is
> rather strange, I think. For almost every code base that generates language
> bindings the generation code/templates/setup is part of the cde base in
> question, why would this be any different for xen-server?
Hi Robert,
Perhaps I should have said that there is no externally visible
repository for the api binding generation code. Every XenServer (and
XCP) release will have a corresponding sources ISO, which contains a
tarball of each of our internal repositories.
We have opened up a few of our development repositories (see
http://github.com/xen-org/), and I would like to see us open them all
up. But perhaps this is a conversation best left for a separate
thread, and perhaps on the xen-api mailing list instead of
cloudstack-dev.
Mike
Re: XAPI API (aka xenserver-java)
Posted by Robert Schweikert <rj...@suse.com>.
On 05/18/2012 06:49 AM, Mike McClurg wrote:
> On Fri, May 18, 2012 at 5:20 AM, David Nalley<da...@gnsa.us> wrote:
>> On Thu, May 17, 2012 at 11:58 PM, Kevin Kluge<Ke...@citrix.com> wrote:
>>> David, I had assumed that we could just get this library released under AL2 and bundle the jar with CloudStack. It'd be great if distros picked it up but that seems more difficult and longer term than a re-license, given our ability to influence the license of this particular piece of software. (My understanding is that Citrix wrote all that code, and it could be released under multiple licenses if needed, which would presumably not upset the Xen/XenServer community.)
>>>
>>> -kevin
>>
>> Ahh - I was unaware that this was a solely Citrix-written piece of
>> software, unlike the rest of Xen* - If we can get it relicensed,
>> that's better, perhaps we can get our changes upstreamed at the same
>> time.
>
> Hi all,
>
> I just checked the XenServer API bindings for Java, and it seems that
> we've dual-licensed them under the LGPLv2 and Apache v2.0 licenses.
> Are there different XenServer API bindings for Java that are licensed
> differently, that I'm not aware of?
>
> These bindings are autogenerated, which is why there is no source
> repository for them. The license on the API bindings generation code
> is GPLv2, so I don't see any reason why we couldn't publish the source
> repo for these bindings.
But shouldn't the binding generation code then be part of the xen-server
source base?
I am a bit confused here. It sounds to me that CS depends on Java
bindings to Xen-server, yet the bindings are maintained separately from
the server code, do I understand this correctly? If this is the case
then this is rather strange, I think. For almost every code base that
generates language bindings the generation code/templates/setup is part
of the cde base in question, why would this be any different for xen-server?
Thanks,
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147
Re: XAPI API (aka xenserver-java)
Posted by Mike McClurg <mi...@gmail.com>.
On Fri, May 18, 2012 at 5:20 AM, David Nalley <da...@gnsa.us> wrote:
> On Thu, May 17, 2012 at 11:58 PM, Kevin Kluge <Ke...@citrix.com> wrote:
>> David, I had assumed that we could just get this library released under AL2 and bundle the jar with CloudStack. It'd be great if distros picked it up but that seems more difficult and longer term than a re-license, given our ability to influence the license of this particular piece of software. (My understanding is that Citrix wrote all that code, and it could be released under multiple licenses if needed, which would presumably not upset the Xen/XenServer community.)
>>
>> -kevin
>
> Ahh - I was unaware that this was a solely Citrix-written piece of
> software, unlike the rest of Xen* - If we can get it relicensed,
> that's better, perhaps we can get our changes upstreamed at the same
> time.
Hi all,
I just checked the XenServer API bindings for Java, and it seems that
we've dual-licensed them under the LGPLv2 and Apache v2.0 licenses.
Are there different XenServer API bindings for Java that are licensed
differently, that I'm not aware of?
These bindings are autogenerated, which is why there is no source
repository for them. The license on the API bindings generation code
is GPLv2, so I don't see any reason why we couldn't publish the source
repo for these bindings.
David, if you have API bindings changes you need made, I can put you
in contact with the team that owns the bindings generation code, and
we can try to get those changes upstreamed there. Also, I would be
interested in publishing the various language bindings as packages for
deb and rpm based distros. We've already pushed the xenapi-python
bindings to Debian and Ubuntu, so it would make sense to add the Java
and C bindings.
Mike
Re: XAPI API (aka xenserver-java)
Posted by David Nalley <da...@gnsa.us>.
On Thu, May 17, 2012 at 11:58 PM, Kevin Kluge <Ke...@citrix.com> wrote:
> David, I had assumed that we could just get this library released under AL2 and bundle the jar with CloudStack. It'd be great if distros picked it up but that seems more difficult and longer term than a re-license, given our ability to influence the license of this particular piece of software. (My understanding is that Citrix wrote all that code, and it could be released under multiple licenses if needed, which would presumably not upset the Xen/XenServer community.)
>
> -kevin
Ahh - I was unaware that this was a solely Citrix-written piece of
software, unlike the rest of Xen* - If we can get it relicensed,
that's better, perhaps we can get our changes upstreamed at the same
time.
--David
RE: XAPI API (aka xenserver-java)
Posted by Kevin Kluge <Ke...@citrix.com>.
David, I had assumed that we could just get this library released under AL2 and bundle the jar with CloudStack. It'd be great if distros picked it up but that seems more difficult and longer term than a re-license, given our ability to influence the license of this particular piece of software. (My understanding is that Citrix wrote all that code, and it could be released under multiple licenses if needed, which would presumably not upset the Xen/XenServer community.)
-kevin
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Wednesday, May 16, 2012 10:26 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: XAPI API (aka xenserver-java)
>
> 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. 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+appr
> oved+licenses