Hi Daniel,
First, thank you very much for improving the OpenNebula driver with
your comments. I am totally agree with you suggestion about the
configure.in, it should be a quick fix.
Regarding the licenses, I do not really see the problem. I mean, you
can link with GPL and Apache as libvirt is using LGPL. But the
OpenNebula driver is not using any GPL libraries; I mean, you have to
be license compatible with all the libraries you are using, but do all
those libraries need to be also license compatible among them?. I am
not an expert in license issues so you are probably right.
So, if finally there is some kind of incompatibility with OpenNebula
using Apache2, we have a couple of options:
1- use the conditional compilation. I do not like this one either
2- Change the license of the OpenNebula client API to LPGL (just the
library files)
3- License the OpenNebula client API with LGPL for the libvirt project
4- Include a GPL linking exception in those libraries/drivers using GPL
What do you think?
Cheers
Ruben
On Mon, May 25, 2009 at 2:08 PM, Daniel Veillard <veillard(a)redhat.com> wrote:
On Wed, May 20, 2009 at 04:07:12PM +0200, "Abel Míguez
Rodríguez" wrote:
>
> > On Wed, May 20, 2009 at 11:32:18AM +0100, Daniel P. Berrange wrote:
[...]
> > > > Here is the One driver & patches for the current git's
[...]
> > > My inclination at this point is to merge the driver and then
> > we can do
> > > incremental patches to fix further problems as they arise.
> >
> > Agreed, unless Abel has a newer version to submit, I'm
> > inclined to
> > push it before the end of the week,
> >
>
> Hi,
> This version is right to submit.
> I agree, after merged, any further modification needed will be solved by patches.
> Related with Daniel's question, we will submit a patch to populate the running VM
list at libvirt's startup.
Okay, I have commited the current set. There is however a few things
to look at relatively quickly in my opinion:
- we don't build the driver by default, this is a bit against the rule
we should fix this
- but the build depends on the ONE development environment to be
present, for example OneClient.h header
- another thing to note is that OpenNebula seems to be released under
the Apache-2.0 Licence, which is not a problem for tyhe LGPL, but
may become a problem within qemud if we link it against a GPL (v2?)
library coming from another driver.
So I think we should look at improving configure.in to try to locate
$ONE_LOCATION/include/OneClient.h with ONE_LOCATION coming either from
the environment, or from --with-one[=DIR] optional directory location or
from a predefined set of locations.
Right now the driver is disabled and ONE_LOCATION is assumed from
configure, but that really need to be fixed IMHO.
For the Licencing problem, it's a bit tricky, is OpenNebula released
only as Apache-2.0 ? If yes, then maybe at configure time a check should
also been made to avoid drivers under GPL and OpenNebula to be built
together. It's a bit of a pain, and hopefully I get this wrong, but I'm
afraid otherwise we would be in Licence violation of the GPL2 drivers
(if any are configured in, I think we have one but I can't remember
which one right now).
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
--
+---------------------------------------------------------------+
Dr. Ruben Santiago Montero
Associate Professor
Distributed System Architecture Group (
http://dsa-research.org)
URL:
http://dsa-research.org/doku.php?id=people:ruben
Weblog:
http://blog.dsa-research.org/?author=7
GridWay,
http://www.gridway.org
OpenNebula,
http://www.opennebula.org
+---------------------------------------------------------------+