You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Wido den Hollander <wi...@widodh.nl> on 2012/07/06 17:08:07 UTC

Licensing: libvirt-java (from RBD thread)

Since the RBD thread was spinning out of control I figured it would be 
best to start a new thread:

"Wido: perhaps you could produce some packages for testing? at least .debs?

--David"

I've been doing that today. I can now generate a libvirt-java debian 
package which should work on Debian and Ubuntu. I'll test it further and 
sent patches to libvirt so they can add it to the libvirt-java repo.

We we could provide a deb, libvirt already provides an RPM and let the 
cloud-agent depend on it?

That way we'll never ship the JAR inside the cloud-agent package and we 
can simply but it online.

For Debian/Ubuntu I'm still voting for a APT repository where people can 
download/install the CloudStack packages from. When they install 
'cloud-agent' they will simply also download libvirt-java from that same 
repository.

I can than try to get the Deb into Debian and Ubuntu and David, you 
might get it into Fedora?

Would this work?

Wido

Re: Licensing: libvirt-java (from RBD thread)

Posted by Chip Childers <ch...@sungard.com>.
Wido,

That's fantastic news!

- chip

Sent from my iPhone.

On Aug 11, 2012, at 4:17 PM, Wido den Hollander <wi...@widodh.nl> wrote:

> Hi,
>
> I was contacted by Daniel Veillard from RedHat about this licensing issue and I explained him our problem.
>
> A couple of hours later I got this e-mail:
>
> "You are receiving this mail because you are listed as a contributor
> of libvrt-java. One of the project using libvirt-java, CloudStack is
> now on the Apache project incubator list and the current LGPLv2+
> licence of libvirt-java makes it a problem for them to redistribute
> the libvirt-java jars along with the project.
> The proposal is to switch to the MIT Licence
>  http://en.wikipedia.org/wiki/MIT_License
> which is a fairly simple and liberal licence which would not be a
> problem for inclusion in the Apache project."
>
> There is a good chance that libvirt-java will be re-licensed so we can include it in the repository in binary form (correct?)
>
> That would resolve one big dependency!
>
> Wido
>
> On 07/06/2012 05:08 PM, Wido den Hollander wrote:
>> Since the RBD thread was spinning out of control I figured it would be
>> best to start a new thread:
>>
>> "Wido: perhaps you could produce some packages for testing? at least .debs?
>>
>> --David"
>>
>> I've been doing that today. I can now generate a libvirt-java debian
>> package which should work on Debian and Ubuntu. I'll test it further and
>> sent patches to libvirt so they can add it to the libvirt-java repo.
>>
>> We we could provide a deb, libvirt already provides an RPM and let the
>> cloud-agent depend on it?
>>
>> That way we'll never ship the JAR inside the cloud-agent package and we
>> can simply but it online.
>>
>> For Debian/Ubuntu I'm still voting for a APT repository where people can
>> download/install the CloudStack packages from. When they install
>> 'cloud-agent' they will simply also download libvirt-java from that same
>> repository.
>>
>> I can than try to get the Deb into Debian and Ubuntu and David, you
>> might get it into Fedora?
>>
>> Would this work?
>>
>> Wido
>

Re: Licensing: libvirt-java (from RBD thread)

Posted by Wido den Hollander <wi...@widodh.nl>.
Hi,

I was contacted by Daniel Veillard from RedHat about this licensing 
issue and I explained him our problem.

A couple of hours later I got this e-mail:

"You are receiving this mail because you are listed as a contributor
of libvrt-java. One of the project using libvirt-java, CloudStack is
now on the Apache project incubator list and the current LGPLv2+
licence of libvirt-java makes it a problem for them to redistribute
the libvirt-java jars along with the project.
The proposal is to switch to the MIT Licence
   http://en.wikipedia.org/wiki/MIT_License
which is a fairly simple and liberal licence which would not be a
problem for inclusion in the Apache project."

There is a good chance that libvirt-java will be re-licensed so we can 
include it in the repository in binary form (correct?)

That would resolve one big dependency!

Wido

On 07/06/2012 05:08 PM, Wido den Hollander wrote:
> Since the RBD thread was spinning out of control I figured it would be
> best to start a new thread:
>
> "Wido: perhaps you could produce some packages for testing? at least .debs?
>
> --David"
>
> I've been doing that today. I can now generate a libvirt-java debian
> package which should work on Debian and Ubuntu. I'll test it further and
> sent patches to libvirt so they can add it to the libvirt-java repo.
>
> We we could provide a deb, libvirt already provides an RPM and let the
> cloud-agent depend on it?
>
> That way we'll never ship the JAR inside the cloud-agent package and we
> can simply but it online.
>
> For Debian/Ubuntu I'm still voting for a APT repository where people can
> download/install the CloudStack packages from. When they install
> 'cloud-agent' they will simply also download libvirt-java from that same
> repository.
>
> I can than try to get the Deb into Debian and Ubuntu and David, you
> might get it into Fedora?
>
> Would this work?
>
> Wido

Re: Licensing: libvirt-java (from RBD thread)

Posted by Wido den Hollander <wi...@widodh.nl>.

On 06-07-12 18:48, Alex Huang wrote:
>
>
>> -----Original Message-----
>> From: David Nalley [mailto:david@gnsa.us]
>> Sent: Friday, July 06, 2012 9:06 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: Licensing: libvirt-java (from RBD thread)
>>
>> On Fri, Jul 6, 2012 at 11:08 AM, Wido den Hollander <wi...@widodh.nl> wrote:
>>> Since the RBD thread was spinning out of control I figured it would be
>>> best to start a new thread:
>>>
>>> "Wido: perhaps you could produce some packages for testing? at
>> least .debs?
>>>
>>> --David"
>>>
>>> I've been doing that today. I can now generate a libvirt-java debian
>>> package which should work on Debian and Ubuntu. I'll test it further
>>> and sent patches to libvirt so they can add it to the libvirt-java repo.
>>>
>>> We we could provide a deb, libvirt already provides an RPM and let the
>>> cloud-agent depend on it?
>>>
>>> That way we'll never ship the JAR inside the cloud-agent package and
>>> we can simply but it online.
>>>
>>> For Debian/Ubuntu I'm still voting for a APT repository where people
>>> can download/install the CloudStack packages from. When they install
>>> 'cloud-agent' they will simply also download libvirt-java from that
>>> same repository.
>>>
>>> I can than try to get the Deb into Debian and Ubuntu and David, you
>>> might get it into Fedora?
>>>
>>> Would this work?
>>>
>>> Wido
>>
>>
>> So a couple of things:
>>
>> * CloudStack (in its current form) won't build without libvirt-java.
>>
>> This means either:
>> a. CloudStack declares libvirt-java to be a system requirement b. We break
>> out KVM support and make it an optional/non-default part of the build
>
> We will definitely do (b) in the repackaging effort.  I think most of the hypervisors have been broken out now.  We missed kvm because it's hidden in the agent project.

I can live with that.

There are RPM's of these bindings and soon there will hopefully also be 
.debs

So this shouldn't be much of a problem.

Wido

>
> --Alex
>>
>> Both of the above result in cloud-libvirt.jar being removed from the repo.
>>
>> Take a look at:
>> http://www.apache.org/legal/3party.html   (I think we will become very
>> well versed in this particular page over the next month or so)
>>
>> --David


RE: Licensing: libvirt-java (from RBD thread)

Posted by Alex Huang <Al...@citrix.com>.

> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Friday, July 06, 2012 9:06 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Licensing: libvirt-java (from RBD thread)
> 
> On Fri, Jul 6, 2012 at 11:08 AM, Wido den Hollander <wi...@widodh.nl> wrote:
> > Since the RBD thread was spinning out of control I figured it would be
> > best to start a new thread:
> >
> > "Wido: perhaps you could produce some packages for testing? at
> least .debs?
> >
> > --David"
> >
> > I've been doing that today. I can now generate a libvirt-java debian
> > package which should work on Debian and Ubuntu. I'll test it further
> > and sent patches to libvirt so they can add it to the libvirt-java repo.
> >
> > We we could provide a deb, libvirt already provides an RPM and let the
> > cloud-agent depend on it?
> >
> > That way we'll never ship the JAR inside the cloud-agent package and
> > we can simply but it online.
> >
> > For Debian/Ubuntu I'm still voting for a APT repository where people
> > can download/install the CloudStack packages from. When they install
> > 'cloud-agent' they will simply also download libvirt-java from that
> > same repository.
> >
> > I can than try to get the Deb into Debian and Ubuntu and David, you
> > might get it into Fedora?
> >
> > Would this work?
> >
> > Wido
> 
> 
> So a couple of things:
> 
> * CloudStack (in its current form) won't build without libvirt-java.
> 
> This means either:
> a. CloudStack declares libvirt-java to be a system requirement b. We break
> out KVM support and make it an optional/non-default part of the build

We will definitely do (b) in the repackaging effort.  I think most of the hypervisors have been broken out now.  We missed kvm because it's hidden in the agent project.

--Alex
> 
> Both of the above result in cloud-libvirt.jar being removed from the repo.
> 
> Take a look at:
> http://www.apache.org/legal/3party.html   (I think we will become very
> well versed in this particular page over the next month or so)
> 
> --David

Re: Licensing: libvirt-java (from RBD thread)

Posted by Wido den Hollander <wi...@widodh.nl>.

On 07/19/2012 07:39 PM, Wido den Hollander wrote:
>
>
> On 07/06/2012 06:06 PM, David Nalley wrote:
>> On Fri, Jul 6, 2012 at 11:08 AM, Wido den Hollander <wi...@widodh.nl>
>> wrote:
>>> Since the RBD thread was spinning out of control I figured it would
>>> be best
>>> to start a new thread:
>>>
>>> "Wido: perhaps you could produce some packages for testing? at least
>>> .debs?
>>>
>
> I just sent a patch[0] out to the libvirt mailinglist.

I haven't heard back from this (yet).

I did however push the libvirt-0.4.8.jar bindings into the master repo 
with commit a1d53f288b56d2852b698b9ee49488fed6b5d231

The 0.4.5 jar in the repo was something we did not want at all. It 
contained homebrew code which should have gone upstream, but never did.

In the last few weeks I got all this code upstream towards libvirt and 
that eventually resulted in 0.4.8

The 0.4.8 bindings in the repo now are build from the libvirt-java 
source code and do not contain our own code.

It is still a release blocker, but right now we have less-dirty code in 
the repository.

Wido

>
> I also pushed to code to my Github account[1] for those who want to test
> it.
>
> Clone the repo and run:
>
> $ ant deb
>
> That's all.
>
> Wido
>
> [0] https://www.redhat.com/archives/libvir-list/2012-July/msg00978.html
> [1]
> https://github.com/wido/libvirt-java/commit/4c8d88fe8765f5d332db93a55b27747cb9acd4d8
>
>
>>> --David"
>>>
>>> I've been doing that today. I can now generate a libvirt-java debian
>>> package
>>> which should work on Debian and Ubuntu. I'll test it further and sent
>>> patches to libvirt so they can add it to the libvirt-java repo.
>>>
>>> We we could provide a deb, libvirt already provides an RPM and let the
>>> cloud-agent depend on it?
>>>
>>> That way we'll never ship the JAR inside the cloud-agent package and
>>> we can
>>> simply but it online.
>>>
>>> For Debian/Ubuntu I'm still voting for a APT repository where people can
>>> download/install the CloudStack packages from. When they install
>>> 'cloud-agent' they will simply also download libvirt-java from that same
>>> repository.
>>>
>>> I can than try to get the Deb into Debian and Ubuntu and David, you
>>> might
>>> get it into Fedora?
>>>
>>> Would this work?
>>>
>>> Wido
>>
>>
>> So a couple of things:
>>
>> * CloudStack (in its current form) won't build without libvirt-java.
>>
>> This means either:
>> a. CloudStack declares libvirt-java to be a system requirement
>> b. We break out KVM support and make it an optional/non-default part
>> of the build
>>
>> Both of the above result in cloud-libvirt.jar being removed from the
>> repo.
>>
>> Take a look at:
>> http://www.apache.org/legal/3party.html   (I think we will become very
>> well versed in this particular page over the next month or so)
>>
>> --David
>>
>

Re: Licensing: libvirt-java (from RBD thread)

Posted by Wido den Hollander <wi...@widodh.nl>.

On 07/06/2012 06:06 PM, David Nalley wrote:
> On Fri, Jul 6, 2012 at 11:08 AM, Wido den Hollander <wi...@widodh.nl> wrote:
>> Since the RBD thread was spinning out of control I figured it would be best
>> to start a new thread:
>>
>> "Wido: perhaps you could produce some packages for testing? at least .debs?
>>

I just sent a patch[0] out to the libvirt mailinglist.

I also pushed to code to my Github account[1] for those who want to test it.

Clone the repo and run:

$ ant deb

That's all.

Wido

[0] https://www.redhat.com/archives/libvir-list/2012-July/msg00978.html
[1] 
https://github.com/wido/libvirt-java/commit/4c8d88fe8765f5d332db93a55b27747cb9acd4d8

>> --David"
>>
>> I've been doing that today. I can now generate a libvirt-java debian package
>> which should work on Debian and Ubuntu. I'll test it further and sent
>> patches to libvirt so they can add it to the libvirt-java repo.
>>
>> We we could provide a deb, libvirt already provides an RPM and let the
>> cloud-agent depend on it?
>>
>> That way we'll never ship the JAR inside the cloud-agent package and we can
>> simply but it online.
>>
>> For Debian/Ubuntu I'm still voting for a APT repository where people can
>> download/install the CloudStack packages from. When they install
>> 'cloud-agent' they will simply also download libvirt-java from that same
>> repository.
>>
>> I can than try to get the Deb into Debian and Ubuntu and David, you might
>> get it into Fedora?
>>
>> Would this work?
>>
>> Wido
>
>
> So a couple of things:
>
> * CloudStack (in its current form) won't build without libvirt-java.
>
> This means either:
> a. CloudStack declares libvirt-java to be a system requirement
> b. We break out KVM support and make it an optional/non-default part
> of the build
>
> Both of the above result in cloud-libvirt.jar being removed from the repo.
>
> Take a look at:
> http://www.apache.org/legal/3party.html   (I think we will become very
> well versed in this particular page over the next month or so)
>
> --David
>


Re: Licensing: libvirt-java (from RBD thread)

Posted by David Nalley <da...@gnsa.us>.
On Fri, Jul 6, 2012 at 11:08 AM, Wido den Hollander <wi...@widodh.nl> wrote:
> Since the RBD thread was spinning out of control I figured it would be best
> to start a new thread:
>
> "Wido: perhaps you could produce some packages for testing? at least .debs?
>
> --David"
>
> I've been doing that today. I can now generate a libvirt-java debian package
> which should work on Debian and Ubuntu. I'll test it further and sent
> patches to libvirt so they can add it to the libvirt-java repo.
>
> We we could provide a deb, libvirt already provides an RPM and let the
> cloud-agent depend on it?
>
> That way we'll never ship the JAR inside the cloud-agent package and we can
> simply but it online.
>
> For Debian/Ubuntu I'm still voting for a APT repository where people can
> download/install the CloudStack packages from. When they install
> 'cloud-agent' they will simply also download libvirt-java from that same
> repository.
>
> I can than try to get the Deb into Debian and Ubuntu and David, you might
> get it into Fedora?
>
> Would this work?
>
> Wido


So a couple of things:

* CloudStack (in its current form) won't build without libvirt-java.

This means either:
a. CloudStack declares libvirt-java to be a system requirement
b. We break out KVM support and make it an optional/non-default part
of the build

Both of the above result in cloud-libvirt.jar being removed from the repo.

Take a look at:
http://www.apache.org/legal/3party.html   (I think we will become very
well versed in this particular page over the next month or so)

--David