Re: [Qemu-devel] why is kqemu closed?

[Brad Campbell]

Auke Kok wrote:

> no matter how you turn Linus' arguments, he doesn't like anything else 
> than ports from windows driver objects linked, and I can really agree 

I think you best re-read anything from Linus on that subject.
What he has said is something derivative of the kernel.

Now we have kqemu for linux, freebsd and windows and its all relatively the same code. If it were a 
derivative of the kernel it would be using  functions within the kernel that were special and/or 
unique. Given it was easily ported to other OS, it's pretty clear it does not use some of the funky 
features of the kernel (VFS comes to mind) and therefore not likely to be a derivative.

Now don't get me wrong, I'd love for the code to be open, but Fabrice has his reasons. It's his code 
and he can choose to license it as he pleases.


> I do not think that kqemu benefits from being closed source, and 
> probably more people with me. People will pick an open implementation 
> before any closed one, even industry, they're picking up faster than you 
> think ;^)

Really? so where are the open implementations of VM technology that work as fast, or are as 
relatively unintrusive as qemu/kqemu?

> I did not agree with kqemu being released without the proprietary flag, 
> which is why I submitted the issue, and,if I can help it, it'll be open 
> source or surpassed by something that is - no offense.

Cool.. as soon as you come up with some open code that does what kqemu does and does it well, I'll 
look at switching. Hell I'll even spend time testing and reporting bugs to you as long as it does 
not take down my kernel. (which kqemu has *never* done)

Take with a grain of salt as usual. And this will be my last post on the 
subject.
His code, his license.

I'm just grateful I've got it and it works :)

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