Announcing: Open OVF project source code availibility

Announcing: Open OVF project source code availibility

[Mike D. Day]

Announcing the open-ovf project and source code availibility.

Hi folks, we are announcing the availibility of source code for the
open-ovf project. 

OVF is a standard packaging format for virtual machines and software
appliances. The open-ovf project is seeking contributors and users to
help establish OVF as a transparent and platform-nuetral method for
packaing virtual machine images. 

We anticipate being able to deploy a single OVF package to either Xen
or KVM. Eventually expanding that list to include VMware, Hyper-V, and
other platforms. Getting to that point will require community
contributions.

For a quick summary of OVF and the open source project, see the .pdf
from the recent Xen summit located at:

http://www.xen.org/files/xensummitboston08/open-ovf-proposal.pdf


The open-ovf project is hosted at sourceforge:

http://open-ovf.wiki.sourceforge.net/


And source code is hosted in a git repository:

http://gitorious.org/projects/open-ovf/repos


Scott Moser <smoser@us.ibm.com> is the project maintainer.

Please feel free to respond to this email if you have any questions!

Mike


-- 
Mike D. Day
IBM LTC
Cell: 919 412-3900
Sametime: ncmike@us.ibm.com AIM: ncmikeday  Yahoo: ultra.runner
PGP key: http://www.ncultra.org/ncmike/pubkey.asc

Re: Announcing: Open OVF project source code availibility

[Daniel P. Berrange]

On Tue, Aug 12, 2008 at 10:34:33AM -0400, Mike D. Day wrote:
> Announcing the open-ovf project and source code availibility.
> 
> Hi folks, we are announcing the availibility of source code for the
> open-ovf project. 

Why was the Eclipse Public License chosen ?  This license is not
compatible with the GPL[1], so no GPL licensed app can make use of
this code :-( For example it makes it impossible to use this code to
assist in supporting OVF in virt-manager, virt-install or virt-image

  http://en.wikipedia.org/wiki/Eclipse_Public_License

  "The EPL 1.0 is not compatible with the GPL, and a work created by
   combining a work licensed under the GPL with a work licensed under
   the EPL cannot be lawfully distributed."

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: Announcing: Open OVF project source code availibility

[Mike Day]

On 12/08/08 15:46 +0100, Daniel P. Berrange wrote:
> 
> Why was the Eclipse Public License chosen ?  This license is not
> compatible with the GPL[1], so no GPL licensed app can make use of
> this code :-( For example it makes it impossible to use this code to
> assist in supporting OVF in virt-manager, virt-install or virt-image
> 
>   http://en.wikipedia.org/wiki/Eclipse_Public_License
> 
>   "The EPL 1.0 is not compatible with the GPL, and a work created by
>    combining a work licensed under the GPL with a work licensed under
>    the EPL cannot be lawfully distributed."
> 

As a file format, the output from open-ovf can be used by any
code of any license. That is, any code can consume an OVF file.

For runtime integration, we are planning on implementing an XML-RPC
interface into and out of the ovf library, which will allow any other
runtime code to interact with it. 

Mike


-- 
Mike Day
http://www.ncultra.org
AIM: ncmikeday |  Yahoo IM: ultra.runner
PGP key: http://www.ncultra.org/ncmike/pubkey.asc

Re: Announcing: Open OVF project source code availibility

[Daniel P. Berrange]

On Tue, Aug 12, 2008 at 11:26:34AM -0400, Mike Day wrote:
> On 12/08/08 15:46 +0100, Daniel P. Berrange wrote:
> > 
> > Why was the Eclipse Public License chosen ?  This license is not
> > compatible with the GPL[1], so no GPL licensed app can make use of
> > this code :-( For example it makes it impossible to use this code to
> > assist in supporting OVF in virt-manager, virt-install or virt-image
> > 
> >   http://en.wikipedia.org/wiki/Eclipse_Public_License
> > 
> >   "The EPL 1.0 is not compatible with the GPL, and a work created by
> >    combining a work licensed under the GPL with a work licensed under
> >    the EPL cannot be lawfully distributed."
> > 
> 
> As a file format, the output from open-ovf can be used by any
> code of any license. That is, any code can consume an OVF file.

Yep, that's not what I'm concerned with.

> For runtime integration, we are planning on implementing an XML-RPC
> interface into and out of the ovf library, which will allow any other
> runtime code to interact with it. 

It is the runtime integration I was refering to. The open-ovf tools
are all python. So is virt-manage/install/image. If these tools were
under a license that were compatible with usage from a GPL  licensed
app, then I could simply call into the OVF APIs. Building an XML-RPC
interface just to call into functions for manipulating OVF files is
rather overkill. 

But perhaps you don't intend to maintain the python libraries as an
official 'public' API for other apps to use ?

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: Announcing: Open OVF project source code availibility

[Mike Day]

On 12/08/08 16:42 +0100, Daniel P. Berrange wrote:


> > For runtime integration, we are planning on implementing an XML-RPC
> > interface into and out of the ovf library, which will allow any other
> > runtime code to interact with it. 
> 
> It is the runtime integration I was refering to. The open-ovf tools
> are all python. So is virt-manage/install/image. If these tools were
> under a license that were compatible with usage from a GPL  licensed
> app, then I could simply call into the OVF APIs. Building an XML-RPC
> interface just to call into functions for manipulating OVF files is
> rather overkill. 

Perhaps locally, but certainly not overkill for remote access. Local
access to XML-RPC via the loopback is still pretty efficient within
the realm of interpreted languages. And the original OVA environment
specification requires a remote API. (The DMTF did not adopt the
environment services in its standard.) For example, a software
appliance running in a guest needs to query the OVF daemon for
information about its hosting hypervisor. This is best done by remote
procedure calls.
 
> But perhaps you don't intend to maintain the python libraries as an
> official 'public' API for other apps to use ?

We hope to establish remote APIs for use by guests at
runtime. Whatever else comes about is up to the community.

Mike
-- 
Mike Day
http://www.ncultra.org
AIM: ncmikeday |  Yahoo IM: ultra.runner
PGP key: http://www.ncultra.org/ncmike/pubkey.asc

Re: Re: Announcing: Open OVF project source code availibility

[Ian Jackson]

Daniel P. Berrange writes ("[Xen-devel] Re: Announcing: Open OVF project source code availibility"):
>  Building an XML-RPC
> interface just to call into functions for manipulating OVF files is
> rather overkill. 

Also it is far from clear whether merely changing the concrete
representation of the interface (eg from in-program function call to
XML-RPC, but with identical semantics) can be used to evade the GPL's
`work as a whole' provisions in this way.

This question is disputed and as far as I know has never been tested
in court.

Ian.