Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Frank Mehnert]

Hi,

On Tuesday 06 January 2009, Anthony Liguori wrote:
> Frank Mehnert wrote:
> > On Wednesday 24 December 2008, Anthony Liguori wrote:
> >> Sharing implies a two-way exchange.  In reality, VirtualBox has taken a
> >> bunch of QEMU code and AFAIK has not shared any of their changes back
> >> with the QEMU community.  They are completely entitled to do this of
> >> course based on the licensing of QEMU.
> >
> > Sorry, that is not true.
>
> As I said, sharing implies a two-way exchange.  The VirtualBox
> development was not done publicly and to the best of my knowledge, no
> attempt has been made by the VirtualBox developers to push any of their
> changes back into QEMU.  All other virtualization projects (Xen and it's
> variants, KVM, etc.) have made an attempt to push changes back to QEMU.
>
> Yes, you have a public SVN that appeared long after your development
> started.  Are we supposed to troll through it looking for changes that

Our subversion repository is public since January 2007, so for more than
two years. It is true that we did internal releases before we started to
go public but I don't understand why do you complain. Note that we were
customer-driven from the beginning, unlike, for instance, Xen, which
was a community project when it started.

> may or may not be applicable to upstream?  It's extraordinarily
> difficult because you've made a huge number of changes to your QEMU fork
> that have nothing to do with bug fixes.

Believe me, it is difficult for us too, to follow the changes in Qemu.
And we use only a part of the Qemu code. As you mentioned in an earlier
post, VirtualBox and Qemu are quite different. We execute many code
inside the guest context (for performance reasons) while Qemu recompiles
the guest code in the context of the host. We depend on the Qemu code for
more rare cases where other mechanisms don't work (e.g. real mode). So
the most changes we did were adaptions to our environment.

> This is not how Open Source development works.  You don't make a bunch
> of changes private, put out a repo after the fact, and make no attempt
> to work with any of the projects you took the majority of your code
> from.  You can call it open all you want but it simply isn't.  We won't
> even get into the whole contributor agreement non-sense.
>
> >> Some of their most interesting changes (like SATA emulation, rewritten
> >> USB emulation) remain available only in their closed source version.  I
> >> find that extremely unfortunate because that would be some of the
> >> easiest and most useful code to try to merge from their project.
> >
> > Some of these parts might be available under GPL in the future.
>
> That would be nice but I'm not going to hold my breathe.

Do you really know our public SVN? The majority of the code was written
from scratch and the most interesting parts are available for public
re-use.

Btw, I'm subscribed to this list, no need to reply me directly.

Kind regards,

Frank
-- 
Dr.-Ing. Frank Mehnert    Sun Microsystems    http://www.sun.com/

signature.asc
Description: This is a digitally signed message part.