[Qemu-devel] Sponsorship for QEMU Developers...

[Qemu-devel] Sponsorship for QEMU Developers...

[Leonardo E. Reiter]

Hello QEMU Developers,

my name is Leo Reiter, and I am the VP of Engineering for Win4Lin, Inc. 
  My company is based in Austin, Texas, in the U.S.A.  We specialize in 
Windows-on-Linux software.  While we are U.S.-based, we welcome 
dvelopers and partners from all over the world (Europe, Asia, etc.)

As some of you may already know, QEMU is used extensively in our new 
Win4Lin Pro product for Linux.  I have personally been in contact with 
Fabrice for some time now.  It is with his permission that I send this 
letter.

We are now looking to sponsor open source developers to contribute to 
the open source QEMU project.  We will sponsor in two ways:

1. via a 3rd-party arbitration/escrow service, such as 
http://www.rentacoder.com , for individual fixed-price tasks.  We will 
always give priority to those who have contributed significantly to QEMU 
in the past.  We will use the mailing list archives to recognize these 
individuals.

2. via an individually negotiated hourly rate to work at our direction, 
on an as-needed basis.  Depending on the arrangement, part of the 
compensation may also include equipment and/or software.

Our goal is to accelerate the development of QEMU, while keeping it free 
and open.  At the same time, this obviously improves our own products. 
We are interested in using Fabrice's TODO list as a starting point for 
assignments, but there  will be other items as well.  All work will 
remain free and open source, and will be contributed back to QEMU 
developers mailing list in the form of patches for general use.  We will 
compensate the developers we sponsor independent of Fabrice accepting 
your work into the mainline.  (Understandably Fabrice is very busy and 
sometimes takes a while to review and integrate patches.)

Our mission is to make QEMU better on an ongoing basis, which also helps 
our own products.

In addition to Fabrice's TODO list, we are mainly interested in stable 
and portable softmmu optimization.  We are not interested in KQEMU 
functionality at this time, but wish Fabrice the best of luck in 
securing a sponsor for it.

If anyone is interested in learning more about these opportunities, 
please contact me directly.  If you are not yet subscribed to the QEMU 
developers list, my email address is:
     lreiter  < -A-t- >  win4lin  < -D-o-t- >  com.

Please note that if you are interested in option 1, you should register 
as a developer (or "coder") with http://www.rentacoder.com as soon as 
possible.  This will be the first service we use since we are already 
familiar with it, but we may consider others in the future as well. Send 
me an email in any case so that I can "invite" you with their service.

Best regards, and thank you all for helping Fabrice to make such amazing 
technology,

Leo Reiter

-- 
Leonardo E. Reiter
Vice President of Engineering

Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com

Re: [Qemu-devel] Sponsorship for QEMU Developers...

[Paul Brook]

On Friday 04 March 2005 20:11, Leonardo E. Reiter wrote:
> As some of you may already know, QEMU is used extensively in our new 
> Win4Lin Pro product for Linux.  I have personally been in contact with 
> Fabrice for some time now.  It is with his permission that I send this 
> letter.

Does this mean kqemu is going to be released under the GPL, or remain 
proprietary?

Paul

Re: [Qemu-devel] Sponsorship for QEMU Developers...

[Leonardo E. Reiter]

We are not involved with KQEMU at all... that's up to Fabrice.

- Leo Reiter

Paul Brook wrote:
> On Friday 04 March 2005 20:11, Leonardo E. Reiter wrote:
> 
>>As some of you may already know, QEMU is used extensively in our new 
>>Win4Lin Pro product for Linux.  I have personally been in contact with 
>>Fabrice for some time now.  It is with his permission that I send this 
>>letter.
> 
> 
> Does this mean kqemu is going to be released under the GPL, or remain 
> proprietary?
> 
> Paul

-- 
Leonardo E. Reiter
Vice President of Engineering

Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com

Re: [Qemu-devel] Sponsorship for QEMU Developers...

[Joshua Kugler]

Hey Leo!

Funny to run into you here. :)  I see your name all the time on the Win4Lin 
list.

> We are not interested in KQEMU functionality at this time, but wish Fabrice
> the best of luck in securing a sponsor for it.

If you're at liberty to explain why, can you elaborate?  KQemu would make 
Win4Lin Pro *fly* and would add a lot of value here.  Yes, it would be back 
to the module thing, but you wouldn't have to send out custom kernels, only 
modules compiled for certain kernels.  With the right scripting, downloading 
and compiling for the many kernels (and kernel updates) in a distro shouldn't 
be *too* bad.  And a user could always compile their own module if there 
wasn't one for their kernel.  Is this extra admin overhead the reason you 
don't want to use it?

Is there even the option of putting the needed hooks in Win4Lin Pro, and 
telling users if they want to, they can download and install KQemu on their 
own?

j----- k-----

-- 
Joshua Kugler
CDE System Administrator
http://distance.uaf.edu/

Re: [Qemu-devel] Sponsorship for QEMU Developers...

[Magnus Damm]

On Fri, 04 Mar 2005 15:11:05 -0500, Leonardo E. Reiter
<lreiter@win4lin.com> wrote:
> In addition to Fabrice's TODO list, we are mainly interested in stable
> and portable softmmu optimization.  We are not interested in KQEMU
> functionality at this time, but wish Fabrice the best of luck in
> securing a sponsor for it.

I plan to update the mmap patches and include ppc host support for
both Linux and OSX as soon as 0.6.2 is released. And I really would
like to see the x86 bios binary updated before the 0.6.2 release, but
that's another story.

/ magnus

Re: [Qemu-devel] Sponsorship for QEMU Developers...

[Marc Collin]

Le 4 Mars 2005 15:11, Leonardo E. Reiter a écrit :
> Hello QEMU Developers,
>
> my name is Leo Reiter, and I am the VP of Engineering for Win4Lin, Inc.
>   My company is based in Austin, Texas, in the U.S.A.  We specialize in
> Windows-on-Linux software.  While we are U.S.-based, we welcome
> dvelopers and partners from all over the world (Europe, Asia, etc.)
>
> As some of you may already know, QEMU is used extensively in our new
> Win4Lin Pro product for Linux.  I have personally been in contact with
> Fabrice for some time now.  It is with his permission that I send this
> letter.
>

> Leo Reiter

HI

where we can get source code of qemu you use in Win4Lin Pro?

thanks

Re: [Qemu-devel] Sponsorship for QEMU Developers...

[Leonardo E. Reiter]

Marc,

here is an easy link to use:

ftp://ftp.win4lin.com/pub/oss/

oss stands for Open Source Software of course.

the qemu tarball is a CVS head snapshot from the 2/20/05; mergepro.patch 
gets applied to it to add our 3rd party stuff.  Basically what we do is 
enable loading a dynamic shared object as a "plugin", and export symbols 
back and forth as needed by supplying pointers to them both in vl.c and 
in our plugin.  We do not use any additional header files or anything 
like that in our closed source bits, since that would of course violate 
the GPL.  We mainly did this so that we could "replace" the 
initialization of certain built-in peripherals in QEMU with our own 
proprietary versions that live in the plugin.  To date, we replace the 
GUI ("display") and the IDE driver with our own home-grown versions. 
You will notice that all QEMU structures are passed in as void pointers 
back and forth, since we don't use any of the QEMU header files which 
define them.  We instead get and set only the members we are interested 
in by address in our plugin.

Note that this is fairly temporary.  We are working on making all of 
QEMU a shared library object itself, and adding accessors (get/set) for 
each QEMU structure type that are exported from the shared library. 
This would encapsulate the GPL'd code in a much cleaner way, and would 
let us avoid having to calculate addresses of members in our 
closed-source code when getting or setting data from structures.

Let me know if you have any additional questions.

Best regards,

Leo Reiter

Marc Collin wrote:
> HI
> 
> where we can get source code of qemu you use in Win4Lin Pro?
> 
> thanks

-- 
Leonardo E. Reiter
Vice President of Engineering

Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com

[Qemu-devel] Re: Sponsorship for QEMU Developers...

[Robert Wittams]

Leonardo E. Reiter wrote:
> Marc,
> 
> here is an easy link to use:
> 
> ftp://ftp.win4lin.com/pub/oss/
> 
> oss stands for Open Source Software of course.
> 
> the qemu tarball is a CVS head snapshot from the 2/20/05; mergepro.patch 
> gets applied to it to add our 3rd party stuff.  Basically what we do is 
> enable loading a dynamic shared object as a "plugin", and export symbols 
> back and forth as needed by supplying pointers to them both in vl.c and 
> in our plugin.  We do not use any additional header files or anything 
> like that in our closed source bits, since that would of course violate 
> the GPL.  We mainly did this so that we could "replace" the 
> initialization of certain built-in peripherals in QEMU with our own 
> proprietary versions that live in the plugin.  To date, we replace the 
> GUI ("display") and the IDE driver with our own home-grown versions. You 
> will notice that all QEMU structures are passed in as void pointers back 
> and forth, since we don't use any of the QEMU header files which define 
> them.  We instead get and set only the members we are interested in by 
> address in our plugin.
> 
> Note that this is fairly temporary.  We are working on making all of 
> QEMU a shared library object itself, and adding accessors (get/set) for 
> each QEMU structure type that are exported from the shared library. This 
> would encapsulate the GPL'd code in a much cleaner way, and would let us 
> avoid having to calculate addresses of members in our closed-source code 
> when getting or setting data from structures.
> 
> Let me know if you have any additional questions.
> 
> Best regards,
> 
> Leo Reiter

Erm... does this sound exactly like linking to anyone else? You can't 
honestly think that manually passing pointers around is going to be an 
end run around the GPL?

Leo, where did you get the idea that not using header files means that 
the combined system is not a derivative work? If the combined system is 
distributed with the GPLed work included, and relies on it to function, 
I see no way it can escape being considered a derived work and therefore 
GPL covered or undistributable.


Re your future plans:
A client of a GPLed library is considered a derivative work. That is 
Trolltechs entire business model, for chrissakes. Please read the GPL 
Faq at least.

-----------------------
http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
-----------------------
If a library is released under the GPL (not the LGPL), does that mean 
that any program which uses it has to be under the GPL?

     Yes, because the program as it is actually run includes the library.
-----------------------


If you have received Qemu under another licence (eg GPL + exceptions), 
please let the list know about it.

If not, you need to try to get it under another licence. If that fails, 
you need to find a way to run your proprietary code in a separate 
process - ie not linked to existing GPLed code.

I'm not a copyright holder on any portion of Qemu.... but this still 
concerns me.

Re: [Qemu-devel] Re: Sponsorship for QEMU Developers...

[Leonardo E. Reiter]

Robert,

http://fabrice.bellard.free.fr/qemu/license.html

Specifically:

The following points clarify the QEMU licenses:

     * The QEMU virtual CPU core library (libqemu.a) and the QEMU PC 
system emulator are released under the GNU Lesser General Public License.

The Linux user mode QEMU emulator is the only GPL'd bit.  We do not 
enable that.

Let me state my intentions again: we want to do everything we can to 
sponsor QEMU to make it better and keep it free.  We are not interested 
in stealing its code and selling it.  The closed-source value added 
functionality that we sell is entirely home-grown, and we have taken all 
the precautions necessary to avoid contamination.  We would also like to 
contribute significantly ourselves in the form of code.  For example, a 
patch that converts the QEMU library and PC emulator into a shared 
library could be useful for many other projects, not just Win4Lin. 
While we don't expect Fabrice to admit it officially, we will certainly 
offer it to the community.  Like that piece, there will be others as well.

- Leo Reiter

Robert Wittams wrote:
> Leonardo E. Reiter wrote:
> Erm... does this sound exactly like linking to anyone else? You can't 
> honestly think that manually passing pointers around is going to be an 
> end run around the GPL?
> 
> Leo, where did you get the idea that not using header files means that 
> the combined system is not a derivative work? If the combined system is 
> distributed with the GPLed work included, and relies on it to function, 
> I see no way it can escape being considered a derived work and therefore 
> GPL covered or undistributable.


-- 
Leonardo E. Reiter
Vice President of Engineering

Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com

Re: [Qemu-devel] Re: Sponsorship for QEMU Developers...

[John R. Hogerhuis]

On Sat, 2005-03-05 at 21:48 -0500, Leonardo E. Reiter wrote:

> Let me state my intentions again: we want to do everything we can to 
> sponsor QEMU to make it better and keep it free.  We are not interested 
> in stealing its code and selling it.  The closed-source value added 
> functionality that we sell is entirely home-grown, and we have taken all 
> the precautions necessary to avoid contamination.  We would also like to 
> contribute significantly ourselves in the form of code.  For example, a 
> patch that converts the QEMU library and PC emulator into a shared 
> library could be useful for many other projects, not just Win4Lin. 
> While we don't expect Fabrice to admit it officially, we will certainly 
> offer it to the community.  Like that piece, there will be others as well.
> 

Leo,

I don't think anyone is accusing you of attempting to steal QEMU. You
are in fact, graciously making an offer to support development and are
being honest and open about your intent. That's fantastic.

I think the problem that Robert is referring to is that by turning QEMU
into a shared library, and linking that library into your closed source
code, you are (albeit dynamically) linking your closed source code to
GPLed code. In such a situation, you could, say, distribute your work by
itself, and have users download QEMU on their own. Otherwise, since you
are linking to the code (directly or indirectly, it doesn't matter), you
are prevented by the GPL from shipping the combined work unless
recipients can request and get the source code to *both* the closed
source parts and QEMU under a GPL license. At least that's the way I
have come to understand the implications of the GPL.

Otherwise, you would technically be guilty of copyright infringement if
you distribute both together and fail to release your closed source
parts if asked to by one of your customers. What that means practically
is up to the copyright holders. They may or may not care, or may ignore
transgressions when it is in their interest to do so. In such a case, no
immediate problem for you or anyone.

Of course there are limits here... your code, for instance, is in no
direct danger of having to be GPLed or anything like that, which is a
common misconception. The only danger for you is being sued for
copyright infringment.


It just appears to me and probably others that while you are making a
conscientious effort to avoid doing so, you are in fact "contaminating"
your code by linking to GPLed code. This is what the LGPL license is
for, it allows linking to GPLed code. If anyone could just throw a
wrapper around a GPLed binary and magically make its GPLed'ness
disappear, there would be no need for the LGPL. Including header files
would certainly trigger 'linking' provisions of the GPL. *Not* including
header files doesn't really mean anything. Dynamic linking is still
linking.

One way around this is negotiating directly with the copyright holders
for a different license. I hope you are able to work something out which
is in yours and everyone's best interest.

Good luck, hopefully this makes sense... I'm no lawyer, which is
information advice is free... do with it what you will.

-- John.

Re: [Qemu-devel] Re: Sponsorship for QEMU Developers...

[Jim C. Brown]

On Sat, Mar 05, 2005 at 07:32:51PM -0800, John R. Hogerhuis wrote:
> Leo,
> 
> I don't think anyone is accusing you of attempting to steal QEMU. You
> are in fact, graciously making an offer to support development and are
> being honest and open about your intent. That's fantastic.

Agreed,

> 
> I think the problem that Robert is referring to is that by turning QEMU
> into a shared library, and linking that library into your closed source
> code, you are (albeit dynamically) linking your closed source code to
> GPLed code. In such a situation, you could, say, distribute your work by
> itself, and have users download QEMU on their own. Otherwise, since you
> are linking to the code (directly or indirectly, it doesn't matter), you
> are prevented by the GPL from shipping the combined work unless
> recipients can request and get the source code to *both* the closed
> source parts and QEMU under a GPL license. At least that's the way I
> have come to understand the implications of the GPL.

Exactly.

What Robert overlooked is that QEMU is NOT GPL!!!

Qemu is NOT GPL!!!

Qemu is NOT GPL!!!

Qemu is NOT GPL!!!

qemu-user is GPL. But as Leo stated, he doesn't use qemu-user.

> 
> It just appears to me and probably others that while you are making a
> conscientious effort to avoid doing so, you are in fact "contaminating"
> your code by linking to GPLed code. This is what the LGPL license is
> for, it allows linking to GPLed code. If anyone could just throw a
> wrapper around a GPLed binary and magically make its GPLed'ness
> disappear, there would be no need for the LGPL. Including header files
> would certainly trigger 'linking' provisions of the GPL. *Not* including
> header files doesn't really mean anything. Dynamic linking is still
> linking.
> 

Of course the 2 parts of qemu that he uses (qemu-system-i386 and libqemu)
are under the LGPL and BSD. As you stated, the LGPL means he can link and keep
the linked code closed. BSD is even nicer, as he can modify the code and still
keep it private. (But he didn't do that, even though he could have.)

So legally, he is in the clear.

> One way around this is negotiating directly with the copyright holders
> for a different license. I hope you are able to work something out which
> is in yours and everyone's best interest.
> 
> Good luck, hopefully this makes sense... I'm no lawyer, which is
> information advice is free... do with it what you will.
> 
> -- John.
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] Re: Sponsorship for QEMU Developers...

[John R. Hogerhuis]

On Sat, 2005-03-05 at 22:47 -0500, Jim C. Brown wrote:

> Qemu is NOT GPL!!!
> 
> Qemu is NOT GPL!!!
> 
> Qemu is NOT GPL!!!
> 
> qemu-user is GPL. But as Leo stated, he doesn't use qemu-user.
> 

OK, I agree with you there. So many licenses involved. But yes, I'm
wrong.

Color me confused, but Leo made the point that he is avoiding including
any header files and instead dynamically linking. Why bother if the
pieces in question are LGPLed or even better for him BSD'ed? Talk of
code "contamination," etc.

> So legally, he is in the clear.
> 

Apparently!

-- John.

Re: [Qemu-devel] Re: Sponsorship for QEMU Developers...

[Leonardo E. Reiter]

Hi John,

I apologize for any confusion.  In fact I think I also used 'GPL' in my 
note by mistake instead of 'LGPL'.

The bottom line is just that we always prefer to err on the safe side, 
thus we chose not to include files such as 'vl.h' in our closed source 
bits.  Plus, it can get a bit dicey when the same tarball actually 
contains code with 2 or 3 (most files have BSD-style licenses in their 
comment headers!) types of licenses.  It was just the safe thing to do 
from our perspective, even if we were not even enabling the GPL'd code.

If you or anyone else has any other questions about how we interact with 
QEMU in our Win4Lin Pro product, please ask.  I want to be as honest and 
forward as possible with everyone, and hope that my company can work 
together in harmony with this great QEMU community.

Thank you for your understanding,

Leo Reiter

John R. Hogerhuis wrote:
> <snip>
> Color me confused, but Leo made the point that he is avoiding including
> any header files and instead dynamically linking. Why bother if the
> pieces in question are LGPLed or even better for him BSD'ed? Talk of
> code "contamination," etc.
> <snip>

-- 
Leonardo E. Reiter
Vice President of Engineering

Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com

Re: [Qemu-devel] Re: Sponsorship for QEMU Developers...

[John R. Hogerhuis]

On Sun, 2005-03-06 at 00:40 -0500, Leonardo E. Reiter wrote:
> Hi John,
> 
> I apologize for any confusion.  In fact I think I also used 'GPL' in my 
> note by mistake instead of 'LGPL'.
> 

Yep, noticed that. But I was still wrong. I just can't keep QEMU
licensing straight in my head. Maybe now that I stepped in it good, I'll
remember ;-) QEMU is LGPL or BSD. 

> The bottom line is just that we always prefer to err on the safe side, 
> thus we chose not to include files such as 'vl.h' in our closed source 
> bits.  Plus, it can get a bit dicey when the same tarball actually 
> contains code with 2 or 3 (most files have BSD-style licenses in their 
> comment headers!) types of licenses.  It was just the safe thing to do 
> from our perspective, even if we were not even enabling the GPL'd code.
> 

I suppose. But if its LGPL and Fabrice is amenable, it would seem you're
safe enough, particularly if you get something confirming your
interpretation from Fabrice. Then you get rid of any kind of overhead or
maintainability issues from your dynamic linking code.

> If you or anyone else has any other questions about how we interact with 
> QEMU in our Win4Lin Pro product, please ask.  I want to be as honest and 
> forward as possible with everyone, and hope that my company can work 
> together in harmony with this great QEMU community.
> 

More of an interesting intellectual excercise for me. That linking issue
just set off alarm bells in my head. But given LGPL or BSD everything
looks peachy.

> Thank you for your understanding,
> 

Thank you for taking an interest in sponsoring the work of QEMU
developers.

-- John.

[Qemu-devel] Re: Sponsorship for QEMU Developers...

[Robert Wittams]

Leonardo E. Reiter wrote:
> Robert,
> 
> http://fabrice.bellard.free.fr/qemu/license.html
> 
> Specifically:
> 
> The following points clarify the QEMU licenses:
> 
>     * The QEMU virtual CPU core library (libqemu.a) and the QEMU PC 
> system emulator are released under the GNU Lesser General Public License.
> 
> The Linux user mode QEMU emulator is the only GPL'd bit.  We do not 
> enable that.
> 
> Let me state my intentions again: we want to do everything we can to 
> sponsor QEMU to make it better and keep it free.  We are not interested 
> in stealing its code and selling it.  The closed-source value added 
> functionality that we sell is entirely home-grown, and we have taken all 
> the precautions necessary to avoid contamination.  We would also like to 
> contribute significantly ourselves in the form of code.  For example, a 
> patch that converts the QEMU library and PC emulator into a shared 
> library could be useful for many other projects, not just Win4Lin. While 
> we don't expect Fabrice to admit it officially, we will certainly offer 
> it to the community.  Like that piece, there will be others as well.
> 
> - Leo Reiter

Ah fine. Sorry, I was misled by your strange "we don't use the header 
files" justification. I have no idea why you are doing all that if all 
the bits you are linking to are LGPL.

Re: [Qemu-devel] Re: Sponsorship for QEMU Developers...

[Jonas Maebe]

On 06 Mar 2005, at 02:51, Robert Wittams wrote:

> Erm... does this sound exactly like linking to anyone else? You can't 
> honestly think that manually passing pointers around is going to be an 
> end run around the GPL?

Qemu is LGPL, not GPL. So long as they link to it as a dynamic library 
which can be updated by the user independently of their program, there 
is no problem afaik.

There are a few GPL'd files in Qemu as well though: *-dis.c and 
dyngen.c. I guess the former are not strictly needed, and the latter is 
not linked in the final binary.


Jonas

Re: [Qemu-devel] Re: Sponsorship for QEMU Developers...

[Jonas Maebe]

On 06 Mar 2005, at 10:45, Jonas Maebe wrote:

> Qemu is LGPL, not GPL. So long as they link to it as a dynamic library 
> which can be updated by the user independently of their program, there 
> is no problem afaik.

Sorry for the extra noise. I would like to ask people to simply reply 
to other people's messages and not to start a new thread when doing so, 
because the latter means that it becomes much more difficult to find 
out whether or not someone has already replied (unless you go over your 
mail in two passes or so).


Jonas