[Qemu-devel] FreeOSZoo will stop March 1, 2005

[Qemu-devel] FreeOSZoo will stop March 1, 2005

[Jean-Michel POURE]

Dear friends,

Following Fabrice decision to transform QEMU into a proprietary closed 
solution without any kind of future, I don't find any reason to loose my 
company time and money fostering FreeOSZoo.

I will hand over the project to any interested person, for exampe Raphaël if 
he is interested by FreeOsZoo.

Thank you for your comprehension.

Kind regards,
Jean-Michel

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Magnus Damm]

On Sat, 12 Feb 2005 10:18:08 +0100, Jean-Michel POURE <jm@poure.com> wrote:
> Dear friends,
> 
> Following Fabrice decision to transform QEMU into a proprietary closed
> solution without any kind of future, I don't find any reason to loose my
> company time and money fostering FreeOSZoo.

I am sorry to hear that, FreeOSZoo is a great idea.

/ magnus

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Brad Campbell]

Jean-Michel POURE wrote:
> Dear friends,
> 
> Following Fabrice decision to transform QEMU into a proprietary closed 
> solution without any kind of future, I don't find any reason to loose my 
> company time and money fostering FreeOSZoo.

Woah.. what a severe knee jerk reaction based on nothing. Perhaps before throwing your toys out of 
the pram, taking your bat and ball and heading home you might actually wait for a reply from Fabrice 
clarifying his intentions?

Everyone seems so quick to scream and shout about a single little binary object and license for one 
tiny part of the project. Perhaps there is a good reason behind what Fabrice is doing. I'm just 
astonished at the reaction to this. Whinge, bitch, moan.. I'm sure he is a busy lad and will 
formulate a reply as time permits. Until you get a clear statement on the issue (Fabrice is a clever 
lad, I'm damn sure he knows *exactly* what he is doing) why not just stop pontificating, hurling 
abuse and accusations and get on with your lives!


Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Antti-Juhani Kaijanaho]

On 20050212T141832+0400, Brad Campbell wrote:
> Until you get a clear statement on the issue (Fabrice is a clever lad,
> I'm damn sure he knows *exactly* what he is doing) why not just stop
> pontificating, hurling abuse and accusations and get on with your
> lives!

If memory serves, this whole discussion was started by a clear
statement on the issue by Fabrice.  I think the reaction has been
entirely reasonable.
-- 
Antti-Juhani Kaijanaho                  http://antti-juhani.kaijanaho.info/

		Blogi - http://kaijanaho.info/antti-juhani/blog/
                 Toys - http://www.cc.jyu.fi/yhd/toys/

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 1558 bytes --]

On 12.02.2005, at 11:18, Brad Campbell wrote:

>> Following Fabrice decision to transform QEMU into a proprietary 
>> closed solution without any kind of future, I don't find any reason 
>> to loose my company time and money fostering FreeOSZoo.

> Woah.. what a severe knee jerk reaction based on nothing. Perhaps 
> before throwing your toys out of the pram, taking your bat and ball 
> and heading home you might actually wait for a reply from Fabrice 
> clarifying his intentions?

Your reply is pretty much bollocks. In the same way Fabrice is
free to start commercialising his smart product QEmu, no matter
what the intentions behind that action are, Jean-Michel is free
to stop his contribution to QEmu.

As much as I hate to see this I think we should all respect
each others actions. I suspect that recent changes will cause
some more contributors to cease their work simply because it
restricts[1] freedom which is what free software is all about.

[1] For instance it will at the moment only compile on certain
     Linux systems while OS X and Windows are still broke. Also
     kqemu will only work on 32bit x86 Linux kernels which means
     that a constantly increasing number of people of x86_64 users
     will not be able to benefit from the advantages. I for one
     will have to stick to qemu-fast for the time being because I
     certainly have no intention to reboot my Dual-Opteron into
     pure 32bit mode every time I want to use qemu; mind you that
     SMP on x86_64 does not work too well in 32bit mode.

Servus,
       Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 478 bytes --]

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Brad Campbell]

Daniel Egger wrote:
> On 12.02.2005, at 11:18, Brad Campbell wrote:
> 
>>> Following Fabrice decision to transform QEMU into a proprietary 
>>> closed solution without any kind of future, I don't find any reason 
>>> to loose my company time and money fostering FreeOSZoo.
> 
> 
>> Woah.. what a severe knee jerk reaction based on nothing. Perhaps 
>> before throwing your toys out of the pram, taking your bat and ball 
>> and heading home you might actually wait for a reply from Fabrice 
>> clarifying his intentions?
> 
> 
> Your reply is pretty much bollocks. In the same way Fabrice is
> free to start commercialising his smart product QEmu, no matter
> what the intentions behind that action are, Jean-Michel is free
> to stop his contribution to QEmu.

Indeed. My reply was more along the lines of waiting to find out exactly what is going on prior to 
chucking a wobbly.

> [1] For instance it will at the moment only compile on certain
>     Linux systems while OS X and Windows are still broke. Also
>     kqemu will only work on 32bit x86 Linux kernels which means
>     that a constantly increasing number of people of x86_64 users
>     will not be able to benefit from the advantages. I for one
>     will have to stick to qemu-fast for the time being because I
>     certainly have no intention to reboot my Dual-Opteron into
>     pure 32bit mode every time I want to use qemu; mind you that
>     SMP on x86_64 does not work too well in 32bit mode.

If you recall, the stated objective was to speed up x86 on x86, this meets the stated objective. 
Where is the problem? If you want to improve x86 on x86_64, then work on it. keqmu is alpha software 
at the moment. It was plainly stated that it will only work on x86 Linux kernels at present, but 
other hosts may follow. Give the guy a break before you bust his balls.

Can qemu-fast run anything other than free operating systems? The tested target for kqemu was win2k.
Everything has a reason, and I'm sure all will become clear in good time. Stop jumping to conclusions.

<quote>
KQEMU is _not_ open source as the rest of QEMU. It is a proprietary kernel module (read the LICENSE 
file) and will stay so until a gentle company decides to subsidy the QEMU project.

KQEMU usage is optional: you can disable it at compilation or run time, so no one is forced to use it.
</quote>

So don't use that part of the emulator. Simple.

<My own opinion ahead, take with sack of salt>

What is being built here is a system that will rival vmware. Doing this takes time and at the moment 
there are several companies watching qemu with an eye to using it as the core of their technology. 
(As they can with the current license). If Fabrice releases the accelerator under the same license 
as the rest of the project, these companies have no incentive to contribute financially to the 
project. Simple. It's a lever. I'm quite sure that in time, someone is going to value the product 
highly enough to pay for it, which in turn will allow the opening of the source. All in good time.

In the mean time, deal with it. Use it if you want to (I am and it's great). If you don't, then do 
what you were doing before. If you can't use it because it just does not work for your particular 
application, talk to Fabrice about helping out perhaps.

It's under development, the rest will come with time.

</My opinion>

Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 3623 bytes --]

On 12.02.2005, at 14:42, Brad Campbell wrote:

> If you recall, the stated objective was to speed up x86 on x86,
> this meets the stated objective.

x86_64 *is* x86 + 64bit additions. If implemented right you
can run a complete 32bit userspace in 64bit kernel and have
single 64bit applications in cases where that makes sense;
problem here is that you can't mix 64bit and 32bit kernel code
and userland helpers. Two examples for affected users would
be kqemu and 32bit iptables.

> Where is the problem? If you want to improve x86 on x86_64,
> then work on it.

I'm not necessarily interested in x86 on x86_64 bit
emulation simply because it would be sort of hard (like
reimplementing the 32bit mode from the kernel in qemu)
to run 32bit code natively from a x86_64 application.

What does work though (with qemu-fast) is to run qemu as
32bit application on x86_64 and get pretty close to native
speed. This does *not* work with kqemu for above reasons.

> Give the guy a break before you bust his balls.

I'm not busting anyones balls; I was just pointing out
that it is you who's judging by two different measures.

> Can qemu-fast run anything other than free operating systems?

No, it'll only run Linux with a special kernel. However
this is not a problem for some specialised applications
like several Linux VMs on one capable machine. Since all
powerful x86 machines now and in the future will support
64bit and running a 64bit kernel is really important for
SMP and to get around the memory limitations this is a
severe restriction.

> Stop jumping to conclusions.

I'm sorry?

> So don't use that part of the emulator. Simple.

You do understand that this comes with a huge performance
penalty which wasn't there before, do you?

> What is being built here is a system that will rival vmware. Doing 
> this takes time and at the moment there are several companies watching 
> qemu with an eye to using it as the core of their technology. (As they 
> can with the current license). If Fabrice releases the accelerator 
> under the same license as the rest of the project, these companies 
> have no incentive to contribute financially to the project. Simple. 
> It's a lever.

This is pure speculation on your side and very easy to
prove wrong. I personally know hundreds of people who are
paid for working on OpenSource projects, including me. And
I suspect you'll hardly find *any* project that has partly
gone from OpenSource to OSS with restricted binary or even
completely closed source to raise money.

I stand by my claim that this way is very unconventional and
may not have the effects Fabrice is hoping for; but hey,
everyone deserves the right to make mistakes.... ;)

I'm definitely not saying that I have any problems myself with
the new licensing other than that it is a step backwards for me
in terms of usability because it castrates the system for
certain uses which are becoming more and more common.

> I'm quite sure that in time, someone is going to value the product 
> highly enough to pay for it, which in turn will allow the opening of 
> the source. All in good time.

Interesting opinion.

> In the mean time, deal with it. Use it if you want to (I am and it's 
> great). If you don't, then do what you were doing before. If you can't 
> use it because it just does not work for your particular application, 
> talk to Fabrice about helping out perhaps.

Let's wait until we receive some response from Fabrice about
some of the proposals that were made on the list. Once we
know about his real incentives the people will try to address
them and arrange something.

Servus,
       Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 478 bytes --]

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Fabrice Bellard]

Just a small point: KQEMU will work on x86_64 very soon, for both legacy 
32 bit and 64 bit virtualization. This feature was planned from the 
start in KQEMU. It will be released under the same terms as the current 
x86 version.

Fabrice.

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Jernej Simončič]

On Saturday, February 12, 2005, 17:15:44, Daniel Egger wrote:

>> So don't use that part of the emulator. Simple.
> You do understand that this comes with a huge performance
> penalty which wasn't there before, do you?

Isn't the performance penalty only if you compare current Qemu with and
without the kernel module, and the speed without the module hasn't changed
compared to Qemu from before KQemu was available? Since Qemu's licence
hasn't changed, you aren't loosing anything compared to before the module
was available.

-- 
< Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >

The number of errors made is equal to the sum of the squares employed.
       -- Transcription Square Law

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

On 12.02.2005, at 19:11, Jernej Simončič wrote:

> Isn't the performance penalty only if you compare current Qemu with and
> without the kernel module, and the speed without the module hasn't 
> changed
> compared to Qemu from before KQemu was available?

Nope, qemu-fast uses a patched Linux kernel (yes, the guest can
*only* be Linux) to run Linux at very-close-to-native speed
with very little translation in a different address space.

If you only intend to run Linux VMs and don't have a problem
patching the kernel sources this is a very viable approach to
get something which is not possible anymore *without* kqemu
which is more flexible but does only run on 32bit kernels ATM.

Servus,
       Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 478 bytes --]

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Grzegorz Kulewski]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2640 bytes --]

Hi,

On Sat, 12 Feb 2005, Jean-Michel POURE wrote:
> Following Fabrice decision to transform QEMU into a proprietary closed
> solution

No, Fabrice did not transform QEMU into anything. He simply added another 
optional module than can make QEMU faster and more bug-free. You can still 
use QEMU without the accelerator and be perfectly happy with it. Also any 
further development in area of IO, devices and so on will make both 
versions better. KQEMU is only very small accelerator.

Think about PHP and different accelerators. PHP itself is free product 
(PHP licence, IIRC). But there are many (often commercial but not all) 
accelerators for it (one even made by Zend - autor of PHP). But this 
does not make PHP less free. There are milions of people using PHP without 
any accelerator, there are some using it with commercial accelerator and 
there are few using it with one of free accelerators. Exactly the same 
goes for QEMU.

QEMU is even better because no non-free part is linked with any code in 
QEMU (userspace). This way no QEMU based free products (for example GUIs 
or anything other) are affected by this addition and no licence is broken. 
GPL, of course, allows calling non-free program or using GPLed program on 
OS with non-free module.

Strictly speaking there are more problems at the kernel level. This is 
because Linus and other gave their permission to load non-free modules to 
the kernel but only as a special exception and mainly because some kernel 
modules were written for some other OSes and were ported to Linux and 
their code cannot be opened. This is not the case for KQEMU because it was 
written especially for Linux but I think this is still more-or-less ok. 
Nobody will hopefully complain.

[ Fabrice, please make sure that all files linked with QEMU are free 
because GPL demands that. I did not investigated this but if the header 
for the module is used in userspace please make it free (BSD?) too. 
Thanks. ]

Of course it will be better if KQEMU will go opensource but I hope it will 
happen fast.


> without any kind of future, I don't find any reason to loose my
> company time and money fostering FreeOSZoo.

Of course its your decision and you have perfect right to make it. But 
please think once more about it. I think that your project is very 
valuable for the community.


> I will hand over the project to any interested person, for exampe Raphaël if
> he is interested by FreeOsZoo.

How fast must be the connection for it? How large is it? How much GB/month 
does it generate currently?


Thanks,

Grzegorz Kulewski

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Darrin Ritter]

Here Goes the Flame war!!!!!

If a developer that is using GNU/linux for free is Developing a program
that will only be proprietary the they may as well stop using the free
software and go back to a proprietary system, they are already
benefiting from the hours of work that some one else has put into
developing software and it is hypocritical to close source your code and
use free (as in freedom) software

dv

On Sat, 2005-02-12 at 22:18 +0100, Daniel Egger wrote:
> On 12.02.2005, at 19:11, Jernej Simončič wrote:
> 
> > Isn't the performance penalty only if you compare current Qemu with and
> > without the kernel module, and the speed without the module hasn't 
> > changed
> > compared to Qemu from before KQemu was available?
> 
> Nope, qemu-fast uses a patched Linux kernel (yes, the guest can
> *only* be Linux) to run Linux at very-close-to-native speed
> with very little translation in a different address space.
> 
> If you only intend to run Linux VMs and don't have a problem
> patching the kernel sources this is a very viable approach to
> get something which is not possible anymore *without* kqemu
> which is more flexible but does only run on 32bit kernels ATM.
> 
> Servus,
>        Daniel
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
-- 

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Jernej Simončič]

On Saturday, February 12, 2005, 22:18:48, Daniel Egger wrote:

> If you only intend to run Linux VMs and don't have a problem
> patching the kernel sources this is a very viable approach to
> get something which is not possible anymore *without* kqemu
> which is more flexible but does only run on 32bit kernels ATM.

You don't understand - I was asking what are you loosing with "new" Qemu
without the kernel module compared to Qemu before the kernel module was
introduced. I know that with the kernel module Qemu runs much faster, but if
you don't want to use it due to it's licence, you haven't lost anything
compared to before the module was available. Or have you?

-- 
< Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >

Social innovations tend to the level of minimum tolerable well being.
       -- Albrecht's Law

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Jim C. Brown]

On Sat, Feb 12, 2005 at 02:18:32PM +0400, Brad Campbell wrote:
> Jean-Michel POURE wrote:
> >Dear friends,
> >
> >Following Fabrice decision to transform QEMU into a proprietary closed 
> >solution without any kind of future, I don't find any reason to loose my 
> >company time and money fostering FreeOSZoo.
> 
> Woah.. what a severe knee jerk reaction based on nothing. Perhaps before 
> throwing your toys out of the pram, taking your bat and ball and heading 
> home you might actually wait for a reply from Fabrice clarifying his 
> intentions?

That is a good question. Why is Fabrice making kqemu propertiary?

I prefer open source code myself (because then I can fix any bugs in the code
on my own) but I do use propertiary software from time to time and I can live
with kqemu being propertiary. I don't like it, but as long as it works it is not
a problem for me.

And if it was, I'd just use qemu-softmmu and stay open.

It may be closed source but it is still free (as in beer). At least he isn't
charging us for his hard work.

> 
> Everyone seems so quick to scream and shout about a single little binary 
> object and license for one tiny part of the project. Perhaps there is a 
> good reason behind what Fabrice is doing. I'm just astonished at the 
> reaction to this. Whinge, bitch, moan.. I'm sure he is a busy lad and will 
> formulate a reply as time permits. Until you get a clear statement on the 
> issue (Fabrice is a clever lad, I'm damn sure he knows *exactly* what he is 
> doing) why not just stop pontificating, hurling abuse and accusations and 
> get on with your lives!
> 

I agree that shutting FreeOSZoo down just because of kqemu is extreme (one
can check out cvs right now and get all the open source qemu w/o any
propertiary code whatsoever, so qemu is still free).

I can think of 3 reasons why kqemu is not free:

1) There are those that use qemu without giving Fabrice any money or credit
(such as iEmulator). This is best resolved by legal action, but it may be
difficult for a single person to fight against an entire company, financial-wise.

2) Fabrice wants to hold on to the source in order to make revenue from it in
the future.

3) (This one is a long shot) There may be patent issues that prevent Fabrice
from releasing his source code.

Remember that the rest of qemu is open source. So if it is such a big problem
for you, why not reimplement kqemu yourself? I'm trying, you can too.

> 
> Brad
> -- 
> "Human beings, who are almost unique in having the ability
> to learn from the experience of others, are also remarkable
> for their apparent disinclination to do so." -- Douglas Adams
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

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

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[James Mastros]

Jim C. Brown wrote:
> 1) There are those that use qemu without giving Fabrice any money or credit
> (such as iEmulator). This is best resolved by legal action, but it may be
> difficult for a single person to fight against an entire company, financial-wise.
If this is the reason, and I think it is part of it, then it is a bad 
reason.

a) iEmulator wouldn't use kqemu anyway.  kqemu is for running 
x86-on-x86.  iEmulator is for x86-on-PowerPC.  Thus, the iEmulator 
people aren't loosing anything.

b) A far more effective way would be to first verify that they are 
actually breaking the GPL -- when you purchase iEmulator, do they give 
you a copy of the qemu source with it?  Are you given all rights to the 
qemu source you get as you would under the GPL?  Do they link code 
licensed GPL-incompatabiliy with qemu code?

If iEmulator is not breaking the GPL, then put the code into the qemu 
CVS.  If they are, then start making quiet threats.  If they don't open 
up, then talk to GNU, http://www.softwarefreedom.org/.  If they still 
don't, then it's time to make loud threats -- post to /., etc.

Don't punish everybody because a few folks aren't playing by the rules.

> 2) Fabrice wants to hold on to the source in order to make revenue from it in
> the future.
This is really a much more reasonable position, but if this is his 
position, he should probably state what it would take to open the 
current source for kqemu, and set up a way to take donations for the 
fund.  If he gets to his target, then do it again when he's ready to 
make the next big leap forward -- assuming, that is, that it isn't based 
upon GPL code from other parties.  (There's nothing illegal about basing 
it on your own GPL'd code.)

Since he hasn't responded to any of the several attempts to give him 
money, I rather doubt money is his primary concern, but rather respect 
and credit, which I can certainly understand -- but making kqemu 
closed-source isn't a good way to cause this to happen.

Despite this, I will probably be making several code contributions to 
qemu in the nearish future.  (PC speaker support, and possibly faster 
graphics code.)  I probably won't be contributing money, as it's rather 
tight for me -- sorry, Fabrice.

	-=- James Mastros

PS -- It isn't the case that iEmulator doesn't give qemu any credit, but 
I agree that they should give him much more credit.  Under 
www-dot-iemulator-dot-com-slash-iemulator_faq.php, the third FAQ gives 
qemu credit -- including noting the name of "Fabrice Bellard".  (URL 
mangled so they don't get Google PageRank off of the reference.)

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Jim C. Brown]

On Sun, Feb 13, 2005 at 05:42:39AM +0100, James Mastros wrote:
> Jim C. Brown wrote:
> >1) There are those that use qemu without giving Fabrice any money or credit
> >(such as iEmulator). This is best resolved by legal action, but it may be
> >difficult for a single person to fight against an entire company, 
> >financial-wise.
> If this is the reason, and I think it is part of it, then it is a bad 
> reason.
> 
> a) iEmulator wouldn't use kqemu anyway.  kqemu is for running 
> x86-on-x86.  iEmulator is for x86-on-PowerPC.  Thus, the iEmulator 
> people aren't loosing anything.

But they are using qemu. If qemu was closed source, then iEmulator wouldn't have
been able to do that.

> 
> b) A far more effective way would be to first verify that they are 
> actually breaking the GPL -- when you purchase iEmulator, do they give 
> you a copy of the qemu source with it?  Are you given all rights to the 
> qemu source you get as you would under the GPL?  Do they link code 
> licensed GPL-incompatabiliy with qemu code?

Of course qemu isnt under the GPL at all, so that is impossible. Only qemu-user
code uses the GPL license, and that is probably due to the fact that it uses
linux kernel code.

qemu system emulation is under the BSD license iirc.

> 
> If iEmulator is not breaking the GPL, then put the code into the qemu 
> CVS.  If they are, then start making quiet threats.  If they don't open 
> up, then talk to GNU, http://www.softwarefreedom.org/.  If they still 
> don't, then it's time to make loud threats -- post to /., etc.
> 
> Don't punish everybody because a few folks aren't playing by the rules.

I agree, but the main problem would be legal. If you can't get the courts
to side with you, then you're sunk.

> 
> >2) Fabrice wants to hold on to the source in order to make revenue from it 
> >in
> >the future.
> This is really a much more reasonable position, but if this is his 
> position, he should probably state what it would take to open the 
> current source for kqemu, and set up a way to take donations for the 
> fund.  If he gets to his target, then do it again when he's ready to 
> make the next big leap forward -- assuming, that is, that it isn't based 
> upon GPL code from other parties.  (There's nothing illegal about basing 
> it on your own GPL'd code.)

Presumably he's going to sell kqemu, and he is using this as a test run before
he tries to sell the code to the big companies and get the megabucks. (At least
that is what I would do.)

> 
> Since he hasn't responded to any of the several attempts to give him 
> money, I rather doubt money is his primary concern, but rather respect 
> and credit, which I can certainly understand -- but making kqemu 
> closed-source isn't a good way to cause this to happen.
> 
> Despite this, I will probably be making several code contributions to 
> qemu in the nearish future.  (PC speaker support, and possibly faster 
> graphics code.)  I probably won't be contributing money, as it's rather 
> tight for me -- sorry, Fabrice.
> 
> 	-=- James Mastros
> 

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

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[James Mastros]

Jim C. Brown wrote:
>>a) iEmulator wouldn't use kqemu anyway.  kqemu is for running 
>>x86-on-x86.  iEmulator is for x86-on-PowerPC.  Thus, the iEmulator 
>>people aren't loosing anything.
> But they are using qemu. If qemu was closed source, then iEmulator wouldn't have
> been able to do that.
Yes, this is my point.  By making kqemu closed source, he isn't hurting 
iEmulator, but is hurting people who do use it.  The iEmulator people 
couldn't care less about the status of kqemu.  Sure, it may have a bad 
effect on some other people selling qemu wrappers.  It certainly has ill 
effects on people who are trying to run x86-on-x86, and having problems, 
because they can't try looking through the kqemu source, and fixing 
problems that may live there.

> Of course qemu isnt under the GPL at all, so that is impossible. Only qemu-user
> code uses the GPL license, and that is probably due to the fact that it uses
> linux kernel code.
Yes, it is, read LICENSE.  qemu-user is under the GPL (proper), 
qemu-proper and libqemu are under the lesser GPL.  I'd recommend to 
Fabrice re-licensing under the GPL proper instead of the LGPL -- if you 
don't like people selling products based on qemu without them being 
open-source, then the GPL is probably closer to your wishes then the 
LGPL.  (Of course, doing this requires consent from everyone you've ever 
taken a patch from, or removal of their modifications, which may or may 
not be feasible.)

> qemu system emulation is under the BSD license iirc.
That'd be very silly for him to get in a huff about what is completely 
legal to do under the license that he chose.

>>If iEmulator is not breaking the GPL, then put the code into the qemu 
>>CVS.  If they are, then start making quiet threats.  If they don't open 
>>up, then talk to GNU, http://www.softwarefreedom.org/.  If they still 
>>don't, then it's time to make loud threats -- post to /., etc.
>>
>>Don't punish everybody because a few folks aren't playing by the rules.
> 
> I agree, but the main problem would be legal. If you can't get the courts
> to side with you, then you're sunk.
Well, that's really not true.  The main problem is economic.  If you 
make it uneconomical for the "bad" people to behave the way they are, 
they will stop.  You can do that by going through the courts, and 
obtaining a judgment, but that's quite possibly worse for you then it is 
for them -- even if you win.

You can also go to the court of public opinion.  How many of iEmulator's 
customers read /.?  How many would still be customers if they found out 
that iEmulator rips off open-source code, which they could just as well 
use directly, and not pay thirty bucks for, to boot?  I suspect enough 
of them that they will want to comply with the license, and avoid 
embaressment.

> Presumably he's going to sell kqemu, and he is using this as a test run before
> he tries to sell the code to the big companies and get the megabucks. (At least
> that is what I would do.)
That's a possibility.  If that's true, then I hope the company that buys 
him out is very nice, or we're all going to be out a maintainer of an 
open source system emulator rather soon.  I'd much rather that he sell 
out to the collective of his users rather then to some faceless 
corporate overlord who will make us all use a vmware clone, rather then 
an open source project I've become somewhat fond of.

	-=- James Mastros

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Darryl Dixon]

[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]

Actually, for clarification, anyone (including the author :), at any
time, can fork an LGPL licensed programme into a GPL licensed program,
provided certain constraints are met.  I include the relevant section of
the LGPL below for reference:


------------------------------------------------------------------------------------

3. You may opt to apply the terms of the ordinary GNU General Public

License instead of this License to a given copy of the Library.  To do
this, you must alter all the notices that refer to this License, so
that they refer to the ordinary GNU General Public License, version 2,
instead of to this License.  (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.)  Do not make any other change in
these notices.
  Once this change is made in a given copy, it is irreversible for
that copy, so the ordinary GNU General Public License applies to all
subsequent copies and derivative works made from that copy.
------------------------------------------------------------------------------------


Many regards,
D


On Sun, 2005-02-13 at 07:21 +0100, James Mastros wrote:

> Jim C. Brown wrote:
> [snip]
> > Of course qemu isnt under the GPL at all, so that is impossible. Only qemu-user
> > code uses the GPL license, and that is probably due to the fact that it uses
> > linux kernel code.
> Yes, it is, read LICENSE.  qemu-user is under the GPL (proper), 
> qemu-proper and libqemu are under the lesser GPL.  I'd recommend to 
> Fabrice re-licensing under the GPL proper instead of the LGPL -- if you 
> don't like people selling products based on qemu without them being 
> open-source, then the GPL is probably closer to your wishes then the 
> LGPL.  (Of course, doing this requires consent from everyone you've ever 
> taken a patch from, or removal of their modifications, which may or may 
> not be feasible.)

[snip]
-- 
Darryl Dixon <esrever_otua@pythonhacker.is-a-geek.net>

[-- Attachment #2: Type: text/html, Size: 2851 bytes --]

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

On 13.02.2005, at 01:06, Jernej Simončič wrote:

>> If you only intend to run Linux VMs and don't have a problem
>> patching the kernel sources this is a very viable approach to
>> get something which is not possible anymore *without* kqemu
>> which is more flexible but does only run on 32bit kernels ATM.
>
> You don't understand - I was asking what are you loosing with "new" 
> Qemu
> without the kernel module compared to Qemu before the kernel module was
> introduced. I know that with the kernel module Qemu runs much faster, 
> but if
> you don't want to use it due to it's licence, you haven't lost anything
> compared to before the module was available. Or have you?

Please do read the mails before responding.

qemu-fast is the key point which you're obviously missing.

Servus,
       Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 478 bytes --]

[Qemu-devel] Re: FreeOSZoo will stop March 1, 2005

[Robert Wittams]

Jim C. Brown wrote:
> 3) (This one is a long shot) There may be patent issues that prevent Fabrice
> from releasing his source code.
> 

If he didn't have a patent licence at all, it wouldn't make a difference 
if it were open source or not. It would still infringe on this 
hypothetical patent.

If he had a patent licence which forbade disclosing source code, that 
would be very interesting... and kind of pointless given that patents 
require disclosure to get protection. But stupider things have happened.

Tbh, I'd take Fabrice at face value, and accept that this is a way of 
getting payment for work that he wants to release under a Free licence. 
I'd say it was an implementation of the Street Performer Protocol :
http://www.schneier.com/paper-street-performer.html

I just wish the terms of release were less vague than "a gentle company 
decides to subsidy the QEMU project".

We need a money value to be put on this, so a fund raising drive can be 
put together, both from distributions and other vendors (maybe via OSDL) 
  and interested users.

At the moment the requirement is just so up in the air that people don't 
know what to expect next.

Robert

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Jim C. Brown]

On Sun, Feb 13, 2005 at 07:21:28AM +0100, James Mastros wrote:
> Jim C. Brown wrote:
> >>a) iEmulator wouldn't use kqemu anyway.  kqemu is for running 
> >>x86-on-x86.  iEmulator is for x86-on-PowerPC.  Thus, the iEmulator 
> >>people aren't loosing anything.
> >But they are using qemu. If qemu was closed source, then iEmulator 
> >wouldn't have
> >been able to do that.
> Yes, this is my point.  By making kqemu closed source, he isn't hurting 
> iEmulator, but is hurting people who do use it.

Irrevevant. If qemu was closed source from the start, iEmulator wouldn't
have been able to do anything period (short of massive disassembly &
re-engineering).

>  The iEmulator people 
> couldn't care less about the status of kqemu.  Sure, it may have a bad 
> effect on some other people selling qemu wrappers.  It certainly has ill 
> effects on people who are trying to run x86-on-x86, and having problems, 
> because they can't try looking through the kqemu source, and fixing 
> problems that may live there.

Say kqemu was made open source, and say that iEmulator decided to expand by
releasing a new product, kVirtual. They could do this all over again, and
make more profit. Or maybe some other company unrelated to iEmulator could
use kqemu to make kVirtual.

The point I was making is that maybe Fabrice can't do anything about them
now, but he at least wants to avoid a repeat.

> 
> >Of course qemu isnt under the GPL at all, so that is impossible. Only 
> >qemu-user
> >code uses the GPL license, and that is probably due to the fact that it 
> >uses
> >linux kernel code.
> Yes, it is, read LICENSE.  qemu-user is under the GPL (proper), 
> qemu-proper and libqemu are under the lesser GPL. 

GPL != LGPL

The main difference being, LGPL makes what iEmulator is doing perfectly legal
as they don't need to give the source code unless they modify the qemu code.

Since it is LGPL & they give Fabric credit, iEmulator has done nothing illegal.

> I'd recommend to 
> Fabrice re-licensing under the GPL proper instead of the LGPL -- if you 
> don't like people selling products based on qemu without them being 
> open-source, then the GPL is probably closer to your wishes then the 
> LGPL.

I agree.

> 
> >>If iEmulator is not breaking the GPL, then put the code into the qemu 
> >>CVS.  If they are, then start making quiet threats.  If they don't open 
> >>up, then talk to GNU, http://www.softwarefreedom.org/.  If they still 
> >>don't, then it's time to make loud threats -- post to /., etc.
> >>
> >>Don't punish everybody because a few folks aren't playing by the rules.
> >
> >I agree, but the main problem would be legal. If you can't get the courts
> >to side with you, then you're sunk.
> Well, that's really not true.  The main problem is economic.  If you 
> make it uneconomical for the "bad" people to behave the way they are, 
> they will stop.  You can do that by going through the courts, and 
> obtaining a judgment, but that's quite possibly worse for you then it is 
> for them -- even if you win.

Exactly.

> 
> You can also go to the court of public opinion.  How many of iEmulator's 
> customers read /.?  How many would still be customers if they found out 
> that iEmulator rips off open-source code, which they could just as well 
> use directly, and not pay thirty bucks for, to boot?  I suspect enough 
> of them that they will want to comply with the license, and avoid 
> embaressment.

I didn't think of that.

Of course, how many VMware users read slashdot? How many coperate execs?
How many Windows users?

This approach could work (and imnsho it is worth the risk) but Fabrice might
want something more substantial. At this point I've gone beyond second guessing
tho.

> 
> >Presumably he's going to sell kqemu, and he is using this as a test run 
> >before
> >he tries to sell the code to the big companies and get the megabucks. (At 
> >least
> >that is what I would do.)
> That's a possibility.  If that's true, then I hope the company that buys 
> him out is very nice, or we're all going to be out a maintainer of an 
> open source system emulator rather soon.  I'd much rather that he sell 
> out to the collective of his users rather then to some faceless 
> corporate overlord who will make us all use a vmware clone, rather then 
> an open source project I've become somewhat fond of.

Agreed.

> 
> 	-=- James Mastros
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

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

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Jim C. Brown]

On Sun, Feb 13, 2005 at 12:28:03PM +0100, Daniel Egger wrote:
> On 13.02.2005, at 01:06, Jernej Simon??i?? wrote:
> 
> >>If you only intend to run Linux VMs and don't have a problem
> >>patching the kernel sources this is a very viable approach to
> >>get something which is not possible anymore *without* kqemu
> >>which is more flexible but does only run on 32bit kernels ATM.
> >
> >You don't understand - I was asking what are you loosing with "new" 
> >Qemu
> >without the kernel module compared to Qemu before the kernel module was
> >introduced. I know that with the kernel module Qemu runs much faster, 
> >but if
> >you don't want to use it due to it's licence, you haven't lost anything
> >compared to before the module was available. Or have you?
> 
> Please do read the mails before responding.
> 
> qemu-fast is the key point which you're obviously missing.
> 
> Servus,
>       Daniel

I read the email ... I got the impression that qemu-fast wasn't good enough
either and thus there was no alternative to kqemu.

To end this debate once and for all, I'd like to announce that I've begun work
on getting qemu to use the plex86 kernel module. (Lucky for me I use a 2.4
kernel.) Anyone who is mad that kqemu is closed source, feel free to email me
privately and help me make the necessary changes.

> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


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

[Qemu-devel] Plex86 and Qemu

[jeebs]

From: "Jim C. Brown" <jma5@umd.edu>

>To end this debate once and for all, I'd like to announce that I've begun work
>on getting qemu to use the plex86 kernel module. (Lucky for me I use a 2.4
>kernel.) Anyone who is mad that kqemu is closed source, feel free to email me
>privately and help me make the necessary changes.

Question...

Which version of Plex86 are you talking about?  The original one now at Savannah, or the Plex86 v2 at SourceForge?

The reason I'm asking is that I use Windows, not Linux.  And I'm usually wanting to run OS's other than Linux.  (Dos, Win98, WinXP.)  (And I usually get the semi-daily build off FreeOSZoo, since it's easier to do that than to build it myself.)

Therefor Fabrice's new module is useless to me.  Nice idea etc., but utterly useless to me.

Plex86 v2 is also Linux only, and requires patched guest kernels.

I think the original version was for any OS, wasn't it?  But it was never stable, was it?  Hence the reason it was abandoned.

And others, such as CoLinux, are also linux only.  (And require patched kernal or host.)


Anyway, the point I'm making (and asking about) is that the majority of potential users are either going to run Windows as the guest, or as the host..  (And possibly both.)

So for the majority of people, for the majority of cases, it seems like most of these 'fast emulator' projects are useless...  Nice idea and such, but not really helpful.

So... is your idea going to be helpful to the majority of potential users?

Re: [Qemu-devel] Plex86 and Qemu

[Jim C. Brown]

On Sun, Feb 13, 2005 at 11:40:21AM -0600, jeebs@yango.us wrote:
> From: "Jim C. Brown" <jma5@umd.edu>
> 
> >To end this debate once and for all, I'd like to announce that I've begun work
> >on getting qemu to use the plex86 kernel module. (Lucky for me I use a 2.4
> >kernel.) Anyone who is mad that kqemu is closed source, feel free to email me
> >privately and help me make the necessary changes.
> 
> Question...
> 
> Which version of Plex86 are you talking about?  The original one now at Savannah, or the Plex86 v2 at SourceForge?

v2

> 
> The reason I'm asking is that I use Windows, not Linux. 

I can tell by the length of lines in your email. ;)

> And I'm usually wanting to run OS's other than Linux.  (Dos, Win98, WinXP.)  (And I usually get the semi-daily build off FreeOSZoo, since it's easier to do that than to build it myself.)
> 
> Therefor Fabrice's new module is useless to me.  Nice idea etc., but utterly useless to me.

Mine will be too, unless someone ports plex86 to Windows.

> 
> Plex86 v2 is also Linux only, and requires patched guest kernels.

My idea is to use the module in cosimulation. This would not require a patch
guest kernel and would allow for any guest OS to be used, not just linux.

> 
> I think the original version was for any OS, wasn't it?  But it was never stable, was it?  Hence the reason it was abandoned.
> 
> And others, such as CoLinux, are also linux only.  (And require patched kernal or host.)
> 

I use v2 because the original version is not stable enough, and in fact has
extra code that I don't need (to handle virtalization of ring 0, hardware
emulation, and so on).

v2 also has extra code that isn't needed (I/O space, HAL, and so on), so someone
else is writing a replacement kqemu module from scratch.

> 
> Anyway, the point I'm making (and asking about) is that the majority of potential users are either going to run Windows as the guest, or as the host..  (And possibly both.)

Mine will support using Windows as guest, but not as host.

> 
> So for the majority of people, for the majority of cases, it seems like most of these 'fast emulator' projects are useless...  Nice idea and such, but not really helpful.
> 
> So... is your idea going to be helpful to the majority of potential users?
> 

Yes. It will let linux2.4 users run Windows and Windows apps.

> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

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

Re: [Qemu-devel] Plex86 and Qemu

[jeebs]

From: "Jim C. Brown" <jma5@umd.edu>

>> The reason I'm asking is that I use Windows, not Linux. 
> 
> I can tell by the length of lines in your email. ;)

Yeah... Some Linux mail readers do seem to have problems with line lengths.  You'd think they'd fix it and add reasonable line wrapping, but... Heck... even the old dial up BBS newsgroups (Fidonet etc.) in the 80's and 90's had mail readers that could handle long lines and do line wrapping...  [shrug]

>> Therefor Fabrice's new module is useless to me.  Nice idea etc., but utterly useless to me.
> 
> Mine will be too, unless someone ports plex86 to Windows.

Plex86 v2 is still limited to running only *modified* linux kernals.

So even for those who just want to run a copy of Linux aren't really going to be helped.  No Knoppix or any other Live! emergency boot cd.  No experimenting with other distro's, etc.

>> Plex86 v2 is also Linux only, and requires patched guest kernels.
> 
> My idea is to use the module in cosimulation. This would not require a patch
> guest kernel and would allow for any guest OS to be used, not just linux.

I'm not quite sure I follow...

I'm not quite sure how you are going to do that.

 
>> Anyway, the point I'm making (and asking about) is that
>> the majority of potential users are either going to run Windows
>> as the guest, or as the host..  (And possibly both.)
> 
> Mine will support using Windows as guest, but not as host.

Then that's still going to be extremely limited.  Effecting probably 95%+ of the potential users.

 
>> So... is your idea going to be helpful to the majority of potential users?
>> 
> 
> Yes. It will let linux2.4 users run Windows and Windows apps.

I wouldn't call that "majority of potential users"...  Maybe "many in this mailing list", but that's not quite the same thing.

[grimace]

Oh well.
 

Re: [Qemu-devel] Plex86 and Qemu

[Jim C. Brown]

On Sun, Feb 13, 2005 at 01:35:10PM -0600, jeebs@yango.us wrote:
> From: "Jim C. Brown" <jma5@umd.edu>
> 
> >> The reason I'm asking is that I use Windows, not Linux. 
> > 
> > I can tell by the length of lines in your email. ;)
> 
> Yeah... Some Linux mail readers do seem to have problems with line lengths.  You'd think they'd fix it and add reasonable line wrapping, but... Heck... even the old dial up BBS newsgroups (Fidonet etc.) in the 80's and 90's had mail readers that could handle long lines and do line wrapping...  [shrug]

Actually, it's the editor I use to reply to emails. I could edit it to support
wrapping long lines, I just haven't gotten around to it yet.

> 
> >> Therefor Fabrice's new module is useless to me.  Nice idea etc., but utterly useless to me.
> > 
> > Mine will be too, unless someone ports plex86 to Windows.
> 
> Plex86 v2 is still limited to running only *modified* linux kernals.
> 
> So even for those who just want to run a copy of Linux aren't really going to be helped.  No Knoppix or any other Live! emergency boot cd.  No experimenting with other distro's, etc.

For the reasons given below, this will not apply to qemu.

> 
> >> Plex86 v2 is also Linux only, and requires patched guest kernels.
> > 
> > My idea is to use the module in cosimulation. This would not require a patch
> > guest kernel and would allow for any guest OS to be used, not just linux.
> 
> I'm not quite sure I follow...
> 
> I'm not quite sure how you are going to do that.
> 

The 2 main reasons that plex86 v2 didn't support anything other than a modified
guest were:

a) It was a huge pain supporting ring 0 virtualization

b) Rather than go thru the trouble of hardware emulation, plex86 used a HAL
(Hardware Abstraction Layer) that the guest OS had to know about.

a) is taken care of by letting user space qemu use dynamic translation on
ring 0 instructions (same as qemu + kqemu works now), and b) is taken care of
by letting qemu emulate the hardware. The plex86 kernel module is needed only
for the virtalization, everything else is taken care of by qemu.

>  
> >> Anyway, the point I'm making (and asking about) is that
> >> the majority of potential users are either going to run Windows
> >> as the guest, or as the host..  (And possibly both.)
> > 
> > Mine will support using Windows as guest, but not as host.
> 
> Then that's still going to be extremely limited.  Effecting probably 95%+ of the potential users.
> 

It will support the same series of users that kqemu does. plex86 doesn't support
2.6 kernel series, but it shouldn't be too difficult to port either.

>  
> >> So... is your idea going to be helpful to the majority of potential users?
> >> 
> > 
> > Yes. It will let linux2.4 users run Windows and Windows apps.
> 
> I wouldn't call that "majority of potential users"...  Maybe "many in this mailing list", but that's not quite the same thing.
> 
> [grimace]
> 
> Oh well.
>  

Feel free to port it to a Windows host then. I noticed that you didn't complain
when kqemu was announced, despite the fact that it only supports linux hosts.
Care to explain why?

> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

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

Re: [Qemu-devel] Plex86 and Qemu

[Adrian Smarzewski]

Użytkownik jeebs@yango.us napisał:
> Yeah... Some Linux mail readers do seem to have problems with line lengths.

It's just a matter of keeping standards, netiquette and so on... by
users and software. majority of windows users can be detected using this
criteria ;) but it's an endless discussion.

> Plex86 v2 is still limited to running only *modified* linux kernals.

Yes and this is why qemu rocks! Fabrice give us posibility to send you a
money :)

Re: [Qemu-devel] Plex86 and Qemu

[Martin Koniczek]

> Użytkownik jeebs@yango.us napisał:
>> Yeah... Some Linux mail readers do seem to have problems with line
>> lengths.
>
> It's just a matter of keeping standards, netiquette and so on... by
> users and software. majority of windows users can be detected using this
> criteria ;) but it's an endless discussion.

i don't get this... at least outlook express, and i think this is the
program the vast majority of windows users use for sending mail, does proper
line breaking... or does this happen if you - *shiver* - send HTML mails?

Re: [Qemu-devel] Plex86 and Qemu

[jeebs]

From: "Jim C. Brown" <jma5@umd.edu>

> a) is taken care of by letting user space qemu use dynamic translation on
> ring 0 instructions (same as qemu + kqemu works now), and b) is taken care of

If I remember right (and I may not), one of the problems with Plex86 v1 was the difficulty of catching all possible transistions, from areas where it was safe to let the code run, to areas that had to be carefully monitored.

It sounds like your idea of letting qemu handle the ring 0 stuff is going to have the same kind of problems.

But, I could be wrong.  I'm not that good of a programmer, and I certainly am not familiar with emulator programming.


>> Then that's still going to be extremely limited.  Effecting probably 95%+ of the potential users.
> 
> It will support the same series of users that kqemu does.

Right.  And that's still very limited.

There has been a lot of excitement in the mailing list, but few have bothered to mention that for most users, the kqemu stuff doesn't matter.  I suspect most of those people either got distracted by the license, or just kept their mouth shut.


>> I wouldn't call that "majority of potential users"...  Maybe "many in this mailing list", but that's not quite the same thing.
>> 
>> [grimace]
>> 
>> Oh well.
> 
> Feel free to port it to a Windows host then. I noticed that you didn't complain

I'm not that good of a programmer.  I have never made any comments to suggest that I was.


> when kqemu was announced, despite the fact that it only supports linux hosts.
> Care to explain why?

1) I don't need a reason to not complain.

2) I don't need to *justify* not complaing.

3) The question is a little insulting.

But, to answer it anyway...

Fabrice mentioned long ago that his module would only work with Linux hosts.  I don't know why.  Whether its his familiarity with Linux, or if it's something that can only be done under Linux and not Windows.  (I have no idea how vmware & virtualPC do their stuff, or what method kqemu uses.)

So when he did finally release it, it was no surprise.  I was already resigned to the fact that it wasn't going to help me in the slightest.  And therefor I don't care what license it is released under.  If it ever works under Windows, then I'll care.

When you announced your plans, I was hoping that it might be something that I and 95% of the rest of the world could actually use.  You weren't clear in your original message, so I asked.

Turns out I was wrong though.

Since it's not going to help us, I have no further interest in your project.

Your project sounds like it falls into the exact same category as qemu-fast and now kqemu... Mildly worth knowing they exist, but of no practical value for me.  No reason to get excited or upset.

[Qemu-devel] coLinux and Qemu? --was-- Plex86 and Qemu

[Darryl Dixon]

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

Just a thought, but coLinux (www.colinux.org) has a low-level Windows
driver to give the Linux kernel access to the  CPU.  Perhaps this could
be modified to simply allow Qemu to execute user-space code (a la kqemu)
on Windows?

I'm afraid I'm not nearly enough of an uber-hacker to even assess the
viability...

Cheers,
D

On Sun, 2005-02-13 at 17:20 -0600, jeebs@yango.us wrote:

> From: "Jim C. Brown" <jma5@umd.edu>
> 

[snip]

> 
> Fabrice mentioned long ago that his module would only work with Linux hosts.  I don't know why.  Whether its his familiarity with Linux, or if it's something that can only be done under Linux and not Windows.  (I have no idea how vmware & virtualPC do their stuff, or what method kqemu uses.)
> 
> So when he did finally release it, it was no surprise.  I was already resigned to the fact that it wasn't going to help me in the slightest.  And therefor I don't care what license it is released under.  If it ever works under Windows, then I'll care.
> 
> When you announced your plans, I was hoping that it might be something that I and 95% of the rest of the world could actually use.  You weren't clear in your original message, so I asked.
> 
> Turns out I was wrong though.
> 
> Since it's not going to help us, I have no further interest in your project.
> 
> Your project sounds like it falls into the exact same category as qemu-fast and now kqemu... Mildly worth knowing they exist, but of no practical value for me.  No reason to get excited or upset.
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
Darryl Dixon <esrever_otua@pythonhacker.is-a-geek.net>

[-- Attachment #2: Type: text/html, Size: 2678 bytes --]

Re: [Qemu-devel] Plex86 and Qemu

[Jim C. Brown]

On Sun, Feb 13, 2005 at 05:20:04PM -0600, jeebs@yango.us wrote:
> From: "Jim C. Brown" <jma5@umd.edu>
> 
> > a) is taken care of by letting user space qemu use dynamic translation on
> > ring 0 instructions (same as qemu + kqemu works now), and b) is taken care of
> 
> If I remember right (and I may not), one of the problems with Plex86 v1 was the difficulty of catching all possible transistions, from areas where it was safe to let the code run, to areas that had to be carefully monitored.
> 
> It sounds like your idea of letting qemu handle the ring 0 stuff is going to have the same kind of problems.
> 
> But, I could be wrong.  I'm not that good of a programmer, and I certainly am not familiar with emulator programming.
> 

This has already been solved for kqemu. I don't actually have to code anything
for this, it has already been taken care of. (That's also probably why no one
aside from Fabrice himself has tried before now - getting a non CVS version of
qemu to work with plex86 would be consiberably more work.)

> >> I wouldn't call that "majority of potential users"...  Maybe "many in this mailing list", but that's not quite the same thing.
> >> 
> >> [grimace]
> >> 
> >> Oh well.
> > 
> > Feel free to port it to a Windows host then. I noticed that you didn't complain
> 
> I'm not that good of a programmer.  I have never made any comments to suggest that I was.
> 

Fair enough. This is the qemu-devel list (the developers list), so generally
it is a good idea to ask.

> 
> >> Then that's still going to be extremely limited.  Effecting probably 95%+ of the potential users.
> > 
> > It will support the same series of users that kqemu does.
> 
> Right.  And that's still very limited.
> 
> There has been a lot of excitement in the mailing list, but few have bothered to mention that for most users, the kqemu stuff doesn't matter.  I suspect most of those people either got distracted by the license, or just kept their mouth shut.
> 
> 

In my experience, most users of qemu tend to be using linux as the host OS,
and some version of Windows as a guest OS.

(Of course, I only read this list. It would make sense if users of Windows Qemu
were mainly on the user forum or such. Still, I honestly find that "95% of qemu
users use Windows as the host OS" a bit hard to swallow, but I digress.)

> 
> > when kqemu was announced, despite the fact that it only supports linux hosts.
> > Care to explain why?
> 
> Fabrice mentioned long ago that his module would only work with Linux hosts.  I don't know why.  Whether its his familiarity with Linux, or if it's something that can only be done under Linux and not Windows.  (I have no idea how vmware & virtualPC do their stuff, or what method kqemu uses.)
> So when he did finally release it, it was no surprise.  I was already resigned to the fact that it wasn't going to help me in the slightest.  And therefor I don't care what license it is released under.  If it ever works under Windows, then I'll care.
> When you announced your plans, I was hoping that it might be something that I and 95% of the rest of the world could actually use.  You weren't clear in your original message, so I asked.
> Turns out I was wrong though.
> Since it's not going to help us, I have no further interest in your project.
> Your project sounds like it falls into the exact same category as qemu-fast and now kqemu... Mildly worth knowing they exist, but of no practical value for me.  No reason to get excited or upset.
> 

Fair enough. I apologize for the unintended insult.

I'm not against the idea of getting qemu virtalization to work on a Windows
host, but I don't know enough to do it myself. That is the only reason
I'm not supporting it. If someone who knew enough wanted to work with me on it,
I'd be more than happy to do so.

I don't even know enough to get this to work for Linux, which is why I'm
modifying qemu to use the plex86 kernel module unmodified. It would actually
be easier and cleaner to rewrite the 4 functions in kqemu-mod-i386.o from
scratch (not to mention, far easier to maintain). The other person who is
working on replacing kqemu is doing this, more or less (that person is studying
plex86 as a reference in order to figure out what needs to be done).

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

Re: [Qemu-devel] coLinux and Qemu? --was-- Plex86 and Qemu

[Jim C. Brown]

On Mon, Feb 14, 2005 at 01:05:38PM +1300, Darryl Dixon wrote:
> Just a thought, but coLinux (www.colinux.org) has a low-level Windows
> driver to give the Linux kernel access to the  CPU.  Perhaps this could
> be modified to simply allow Qemu to execute user-space code (a la kqemu)
> on Windows?

I wasn't aware that CoLinux did this (or that it even needed to). I am not sure
how CoLinux works - whether or not this is possible depends on how CoLinux runs
linux executables (i.e. whether or not they need to be virtalized). If it does
do virtalization, this should be a viable approach.

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

Re: [Qemu-devel] coLinux and Qemu? --was-- Plex86 and Qemu

[Mark Williamson]

> On Mon, Feb 14, 2005 at 01:05:38PM +1300, Darryl Dixon wrote:
> > Just a thought, but coLinux (www.colinux.org) has a low-level Windows
> > driver to give the Linux kernel access to the  CPU.  Perhaps this could
> > be modified to simply allow Qemu to execute user-space code (a la kqemu)
> > on Windows?
>
> I wasn't aware that CoLinux did this (or that it even needed to). I am not
> sure how CoLinux works - whether or not this is possible depends on how
> CoLinux runs linux executables (i.e. whether or not they need to be
> virtalized). If it does do virtalization, this should be a viable approach.

It's paravirtualization, rather than full virtualization: the Linux kernel is 
modified to run in the CoLinux environment.  They therefore don't have to do 
the tricky bits from full virtualization of catching and emulating privileged 
operations.

That said, the code for taking over the IDT, etc. in order to get control of 
the system from Windows may be relevant.

CoLinux kernel modules exist for both Linux and Windows IIRC.

Cheers,
Mark

RE: [Qemu-devel] Plex86 and Qemu

[Andreas Bollhalder]

I'm using QEmu primarly on Windows too. But I wouldn't complain that
the current KQEmu module supports only Linux, because the current
version of QEmu works very well for my needs and I don't want to hurt
the people doing this great piece of software. For shure, I would be
happy if a kernel modul will exist for Windows one day.

Andreas

Re: [Qemu-devel] Plex86 and Qemu

[Phil Krylov]

On Sun, 13 Feb 2005 13:35:10 -0600, jeebs@yango.us <jeebs@yango.us> wrote:
> Yeah... Some Linux mail readers do seem to have problems with line lengths.  You'd think they'd fix it and add reasonable line wrapping, but... Heck... even the old dial up BBS newsgroups (Fidonet etc.) in the 80's and 90's had mail readers that could handle long lines and do line wrapping...  [shrug]

As well as some Web mail readers and mailing list Web archives. 

-- Ph.

Old version support. Was: Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Gregory Alexander]

I worry about the availability of patches for the old version, since the 
new one is so much faster.  (See bochs->Qemu mass move, when system 
emulation became available.)

Will Fabrice continue to support the userspace version of QEMU?

KQEMU would be an EXCELLENT way to test the CPU emulation of userspace 
QEMU.  Is anyone considering doing this?  Is it an option with the new 
license?

These are the kinds of problems that I foresee.

Anyways, I understand the rationale, just have a few fears.

Thanks,

GREG

Jernej Simončič wrote:
> On Saturday, February 12, 2005, 22:18:48, Daniel Egger wrote:
> 
> 
>>If you only intend to run Linux VMs and don't have a problem
>>patching the kernel sources this is a very viable approach to
>>get something which is not possible anymore *without* kqemu
>>which is more flexible but does only run on 32bit kernels ATM.
> 
> 
> You don't understand - I was asking what are you loosing with "new" Qemu
> without the kernel module compared to Qemu before the kernel module was
> introduced. I know that with the kernel module Qemu runs much faster, but if
> you don't want to use it due to it's licence, you haven't lost anything
> compared to before the module was available. Or have you?
> 

Re: Old version support. Was: Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Fabrice Bellard]

Gregory Alexander wrote:
> I worry about the availability of patches for the old version, since the 
> new one is so much faster.  (See bochs->Qemu mass move, when system 
> emulation became available.)
> 
> Will Fabrice continue to support the userspace version of QEMU?

KQEMU is just an add-on to QEMU. It cannot work without the user space 
version. So don't worry I am still supporting the user space version.

> [...]

Fabrice.

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Herbert Poetzl]

On Sat, Feb 12, 2005 at 11:41:55PM +0100, Grzegorz Kulewski wrote:
> Hi,
> 
> On Sat, 12 Feb 2005, Jean-Michel POURE wrote:
> >Following Fabrice decision to transform QEMU into a proprietary closed
> >solution
> 
> No, Fabrice did not transform QEMU into anything. He simply added another 
> optional module than can make QEMU faster and more bug-free. You can still 
> use QEMU without the accelerator and be perfectly happy with it. Also any 
> further development in area of IO, devices and so on will make both 
> versions better. KQEMU is only very small accelerator.

well, unfortunately together with the following mail ...

| From: Fabrice Bellard <fabrice@bellard.org>
| To: qemu-devel@nongnu.org
| Date: Sat, 29 Jan 2005 22:48:24 +0100
|
| Hi,
|
| I plan to remove the 'qemu-fast' target in the next release of QEMU. It
| is too painful to maintain, difficult to port and it needs a patched
| guest OS to work correctly.
|
| This target is replaced by the standard QEMU with soft mmu support. The
| QEMU Kernel Acceleration Layer which will be unveiled very soon will
| give much more performance while working with unpatched guest OSes.
|
| Fabrice.

the future looks more like this:

 - you want the same performance or better as before?
   then you have to use 'my' proprietary kernel module
   which isn't even open source (so that somebody
   could verify that it isn't that evil ...)

 - of course, you can use the slow version and
   contribute to the development of the commercial?
   version ...

> Think about PHP and different accelerators. PHP itself is free product 
> (PHP licence, IIRC). But there are many (often commercial but not all) 
> accelerators for it (one even made by Zend - autor of PHP). But this 
> does not make PHP less free. There are milions of people using PHP without 
> any accelerator, there are some using it with commercial accelerator and 
> there are few using it with one of free accelerators. Exactly the same 
> goes for QEMU.
> 
> QEMU is even better because no non-free part is linked with any code in 
> QEMU (userspace). This way no QEMU based free products (for example GUIs 
> or anything other) are affected by this addition and no licence is broken. 
> GPL, of course, allows calling non-free program or using GPLed program on 
> OS with non-free module.
> 
> Strictly speaking there are more problems at the kernel level. This is 
> because Linus and other gave their permission to load non-free modules to 
> the kernel but only as a special exception and mainly because some kernel 
> modules were written for some other OSes and were ported to Linux and 
> their code cannot be opened. This is not the case for KQEMU because it was 
> written especially for Linux but I think this is still more-or-less ok. 
> Nobody will hopefully complain.

proprietary kernel modules are a dangerous thing ...

 - first, you basically lose any support from the 
   kernel developers, when your kernel is tainted
 - then you do not know what the module will do to
   your system (i.e. what crashes it may cause)
 - and finally, if you're paranoid, you will not
   know what kind of information that module might
   gather and send to who-knows-where ...

> [ Fabrice, please make sure that all files linked with QEMU are free 
> because GPL demands that. I did not investigated this but if the header 
> for the module is used in userspace please make it free (BSD?) too. 
> Thanks. ]
> 
> Of course it will be better if KQEMU will go opensource but I hope it will 
> happen fast.

open source, good -- free software, even better ...

but don't get me wrong, it's totally up to Fabrice
under what license he releases his software, and
we have everything required to start of our own QEMU
branch (just under a different name if I got the 
Trademark comment right ;) and continue with free
software development based on qemu/qemu-fast ...

> >without any kind of future, I don't find any reason to loose my
> >company time and money fostering FreeOSZoo.
> 
> Of course its your decision and you have perfect right to make it. But 
> please think once more about it. I think that your project is very 
> valuable for the community.
> 
> 
> >I will hand over the project to any interested person, for exampe Raphaël 
> >if
> >he is interested by FreeOsZoo.
> 
> How fast must be the connection for it? How large is it? How much GB/month 
> does it generate currently?

I'm still hoping for the best, but expecting the
worst ... 

best,
Herbert

> Thanks,
> 
> Grzegorz Kulewski

> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Grzegorz Kulewski]

Hi,

On Thu, 17 Feb 2005, Herbert Poetzl wrote:

> On Sat, Feb 12, 2005 at 11:41:55PM +0100, Grzegorz Kulewski wrote:
>> Hi,
>>
>> On Sat, 12 Feb 2005, Jean-Michel POURE wrote:
>>> Following Fabrice decision to transform QEMU into a proprietary closed
>>> solution
>>
>> No, Fabrice did not transform QEMU into anything. He simply added another
>> optional module than can make QEMU faster and more bug-free. You can still
>> use QEMU without the accelerator and be perfectly happy with it. Also any
>> further development in area of IO, devices and so on will make both
>> versions better. KQEMU is only very small accelerator.
>
> well, unfortunately together with the following mail ...
>
> | From: Fabrice Bellard <fabrice@bellard.org>
> | To: qemu-devel@nongnu.org
> | Date: Sat, 29 Jan 2005 22:48:24 +0100
> |
> | Hi,
> |
> | I plan to remove the 'qemu-fast' target in the next release of QEMU. It
> | is too painful to maintain, difficult to port and it needs a patched
> | guest OS to work correctly.
> |
> | This target is replaced by the standard QEMU with soft mmu support. The
> | QEMU Kernel Acceleration Layer which will be unveiled very soon will
> | give much more performance while working with unpatched guest OSes.
> |
> | Fabrice.
>
> the future looks more like this:
>
> - you want the same performance or better as before?
>   then you have to use 'my' proprietary kernel module
>   which isn't even open source (so that somebody
>   could verify that it isn't that evil ...)
>
> - of course, you can use the slow version and
>   contribute to the development of the commercial?
>   version ...

Well

1. qemu-fast is still there but disabled by default,
2. qemu-fast used patched kernel and was very limited and probably buggy,
3. you can use UML or plex86(?) for the same (== running Linux under 
Linux),
4. you can always write your own accelerator (its very small),
5. looking at the output of nm this .o file is probably harmless - it does 
not call anything from kernel but the functions in its interface in .c and 
.h files. I think this is needed for example because of 2.4 <-> 2.6 
portability and proves good clean design. Of course theoreticaly this 
module can copy and steal some memory location but it is far from being 
trivial and it is probably nearly impossible to write this part of memory 
somewhere without calling anything... Besides Fabrice == spyware author??? 
:-)
6. contributing to userspace part means contributing to something free. 
Everybody could create some kind of accelerator even before Fabrice did 
and everybody can do it now... And everybody can sell his proprietary 
accelerator with the free userspace code (if some conditions are met).


> proprietary kernel modules are a dangerous thing ...

I agree...


Grzegorz Kulewski

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Fabrice Bellard]

Grzegorz Kulewski wrote:
> Hi,
> 
> On Thu, 17 Feb 2005, Herbert Poetzl wrote:
> 
>> On Sat, Feb 12, 2005 at 11:41:55PM +0100, Grzegorz Kulewski wrote:
>>
>>> Hi,
>>>
>>> On Sat, 12 Feb 2005, Jean-Michel POURE wrote:
>>>
>>>> Following Fabrice decision to transform QEMU into a proprietary closed
>>>> solution
>>>
>>>
>>> No, Fabrice did not transform QEMU into anything. He simply added 
>>> another
>>> optional module than can make QEMU faster and more bug-free. You can 
>>> still
>>> use QEMU without the accelerator and be perfectly happy with it. Also 
>>> any
>>> further development in area of IO, devices and so on will make both
>>> versions better. KQEMU is only very small accelerator.
>>
>>
>> well, unfortunately together with the following mail ...
>>
>> | From: Fabrice Bellard <fabrice@bellard.org>
>> | To: qemu-devel@nongnu.org
>> | Date: Sat, 29 Jan 2005 22:48:24 +0100
>> |
>> | Hi,
>> |
>> | I plan to remove the 'qemu-fast' target in the next release of QEMU. It
>> | is too painful to maintain, difficult to port and it needs a patched
>> | guest OS to work correctly.
>> |
>> | This target is replaced by the standard QEMU with soft mmu support. The
>> | QEMU Kernel Acceleration Layer which will be unveiled very soon will
>> | give much more performance while working with unpatched guest OSes.
>> |
>> | Fabrice.
>>
>> the future looks more like this:
>>
>> - you want the same performance or better as before?
>>   then you have to use 'my' proprietary kernel module
>>   which isn't even open source (so that somebody
>>   could verify that it isn't that evil ...)
>>
>> - of course, you can use the slow version and
>>   contribute to the development of the commercial?
>>   version ...
> 
> 
> Well
> 
> 1. qemu-fast is still there but disabled by default,
> 2. qemu-fast used patched kernel and was very limited and probably buggy,
> 3. you can use UML or plex86(?) for the same (== running Linux under 
> Linux),

My decision to disable qemu-fast is not because I fear that there is 
some kind of concurrence with kqemu. I wanted to do that since a long 
time. Here are a few reasons:

1) I feel that running patched OSes is not a good target for QEMU. The 
strength of QEMU is to run unpatched OSes. Otherwise there are many 
other good solutions (Xen, UML, new plex86). qemu-fast was just a hack 
before I got convinced to implemented the soft mmu.

2) qemu-fast is difficult to maintain - it uses too many hacks to have 
full control over the address space.

3) qemu-fast is not safe (no address space protection).

4) qemu-fast performance is limited by the mmap() performance, 
especially in case of frequent process switches (try a kernel 
compilation !).

qemu-fast can have some future, but it involves a lot of work and I 
don't have the time to do it yet. Here are a few ideas:

- Use a separate process to run the translator so that the UI can run in 
its own address space with dynamic libraries.

- Use segments limits to protect the translator code

- Use kqemu to execute the translator in a separate address space.

However, it is better to spend time on a better soft mmu (I plan to 
merge the last published patches for that) and on a better kqemu (when 
it will be GPLed).

Fabrice.

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[John R. Hogerhuis]

Fabrice,

I've followed this project for a while, and though I'm not surprised the
zealots are coming out of the woodwork, I am surprised by the vehemence
of some of the long time users.

I think your strategy is sound. You need a benefactor, and QEMU is
certainly useful enough to deserve that. I don't see the problem of
using your new kqemu as a temporary lever to get you and your project to
the next level. No one is losing anything, and if your strategy works,
everybody will gain. My point of view: Free software isn't about being
Jesus, holding hands and singing Kumbaya... it's about getting what we
want, the way we want it... Free, Open Source, High Quality, Soon, and
without putting developers in the poor house. If you have a stategy in
mind to maximize those benefits, utilizing some new code you wrote, I
say, why the heck not?

I hope your lever gets what you want. All of this doom-and-gloom is just
a lot of noise, the way you've licensed this from the beginning as free
and open source, your other FLOSS projects, and should engender a lot
more trust than people seem to be granting you.

The conspiracy theories about QEMU-fast are absolutely ludicrous. It was
a kludge, a stop-gap dead-end. Patched kernels is really not a long term
solution. Good for what it was. Personally I never bothered running
qemu-fast.

Good luck with your strategy, I hope it works out.

-- John.

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Asko Kauppi]

Another, or complimentary, way to make money would be to have a working 
"Linux on Mac" solution.  There is none.

This was discussed recently on the Mac-on-Linux (MOL) mailing list, and 
offers for 'donations' (against a working implementation ;) started to 
drop in.. I see both MOL and QEMU to have the capabilities to do what 
it takes, a 'Virtual Linux' box running under OS X. Oh, PowerPC flavor, 
not x86..

Still another.. Something like Scratchbox (embedded Linux sandbox 
environment, targetting Linux/ppc and Linux/arm from Linux/x86 host), 
but for the PowerPC host.  That's basically just an extension of the 
above plan.

-ak

18.2.2005 kello 06:29, John R. Hogerhuis kirjoitti:

  Fabrice,
>
> I've followed this project for a while, and though I'm not surprised 
> the
> zealots are coming out of the woodwork, I am surprised by the vehemence
> of some of the long time users.
>
> I think your strategy is sound. You need a benefactor, and QEMU is
> certainly useful enough to deserve that. I don't see the problem of
> using your new kqemu as a temporary lever to get you and your project 
> to
> the next level. No one is losing anything, and if your strategy works,
> everybody will gain. My point of view: Free software isn't about being
> Jesus, holding hands and singing Kumbaya... it's about getting what we
> want, the way we want it... Free, Open Source, High Quality, Soon, and
> without putting developers in the poor house. If you have a stategy in
> mind to maximize those benefits, utilizing some new code you wrote, I
> say, why the heck not?
>
> I hope your lever gets what you want. All of this doom-and-gloom is 
> just
> a lot of noise, the way you've licensed this from the beginning as free
> and open source, your other FLOSS projects, and should engender a lot
> more trust than people seem to be granting you.
>
> The conspiracy theories about QEMU-fast are absolutely ludicrous. It 
> was
> a kludge, a stop-gap dead-end. Patched kernels is really not a long 
> term
> solution. Good for what it was. Personally I never bothered running
> qemu-fast.
>
> Good luck with your strategy, I hope it works out.
>
> -- John.
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] FreeOSZoo will stop March 1, 2005

[Elefterios Stamatogiannakis]

  I prefer to stay out of threads like this, but (see below)

John R. Hogerhuis wrote:
> Fabrice,
> 
> I've followed this project for a while, and though I'm not surprised the
> zealots are coming out of the woodwork, I am surprised by the vehemence
> of some of the long time users.
> 
  Your use of words like "zealots" and "woodwork" reminds me of trolls. 
These words are certainly not used in a civilized conversation. Keep in 
mind that some of the "zealots" have put a lot of work on qemu.
  I'm not going to address the rest of your mail. I find it insulting 
(conspiracy theories?).

  I'll just put my 2 cents.

  First the problem:
  Other people take qemu and make money on it with little to no benefit 
to the people that created it - advanced it.

  Solutions:
1. Fabrice's way. Make a part of it proprietary.
Pros::
(Fabrice) When some company wants to sell this highly beneficial module 
they have to pay him.

Cons::
(Fabrice): Otherwise HE has to sue them.
(community): It divides the community.

2. Pure GPL it.
Pros::
(community): That way when some company wants to sell this highly 
beneficial module they have to give the changes (if any) back to the 
community.
(community): Otherwise contact FSF and it will sue them. The community 
protects us.
(community): It doesn't divide the community.

Cons::
(Fabrice): No immediate monetary benefit.

3. Double license it.
  Both of the above apply.

  Personally i would prefer 2 or 3. They benefit the community more. 
Nevertheless fabrice has the right to do what is best for him. I don't 
have hard feelings about that. I also understand people like Jean-Michel 
Poure (a little kneejerk reaction but i'm ok with it).