qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jim C. Brown
Subject: Re: [Qemu-devel] why is kqemu closed?
Date: Tue, 11 Apr 2006 12:22:14 -0400
User-agent: Mutt/1.4.2.1i

On Tue, Apr 11, 2006 at 11:58:07AM +0400, Brad Campbell wrote:
> Auke Kok wrote:
> 
> 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.

Agreed.

A case can be made that the code for the linux kernel wrapper is a derivataive
of the linux kernel (since that part is linux specific) but IIRC that is under
the BSD license, and it is legal to combine GPL and BSD code and distribute
that, and equally legal to combine BSD and closed source code and distribute
that. Finally it is legal to combine GPL + BSD + closed source code in a
running kernel image, provided that you don't distribute said image to anyone
else. (How many people actually try to do dd if=/dev/kmem of=... anyways?)

So there is no legal problem here.

> 
> 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.
> 

Agreed in full.

If people really wanted a GPL version of kqemu, we'd have more ppl working on
qvm86.

> 
> >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 disagree here as well - industry will take the more stable and mature
technology, not necessarily the more open one.

However, unless Fabrice is benefiting by keeping secret some IP of his,
I do agree in that I don't see how keeping kqemu closed source is necessarily
benefiting him. But that is not my business.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]