qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Jim C. Brown" <jma5@umd.edu>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] why is kqemu closed?
Date: Tue, 11 Apr 2006 12:22:14 -0400	[thread overview]
Message-ID: <20060411162214.GA16542@jbrown.mylinuxbox.org> (raw)
In-Reply-To: <443B618F.10600@wasp.net.au>

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	other threads:[~2006-04-11 16:22 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-10 15:16 [Qemu-devel] why is kqemu closed? Rakotomandimby Mihamina
2006-04-10 15:20 ` Hetz Ben Hamo
2006-04-10 15:47   ` Auke Kok
2006-04-10 15:55     ` Hetz Ben Hamo
2006-04-10 15:56     ` Leonardo E. Reiter
2006-04-11  4:37       ` Auke Kok
2006-04-11  7:58         ` Brad Campbell
2006-04-11 16:22           ` Jim C. Brown [this message]
2006-04-11  8:37         ` Ricardo Almeida
2006-04-11  9:46         ` Johannes Schindelin
2006-04-11 10:05           ` Jamie Lokier
2006-04-11 15:05         ` Leonardo E. Reiter
2006-04-11 15:14           ` Jonas Maebe
2006-04-11 15:25             ` Jim C. Brown
2006-04-11 16:04               ` Jonas Maebe
2006-04-11 15:36           ` Paul Brook
2006-04-11 15:43             ` M. Warner Losh
2006-04-11 16:00               ` Paul Brook
2006-04-11 16:29                 ` M. Warner Losh
2006-04-11 16:09           ` Jim C. Brown
2006-04-11 17:10             ` Enough already! " Bakul Shah
2006-04-11 15:17         ` Sebastian Kaliszewski
2006-04-11 15:31           ` M. Warner Losh
2006-04-11 12:33       ` andrzej zaborowski
2006-04-11 13:58         ` Jamie Lokier
2006-04-11 15:10         ` Sebastian Kaliszewski
2006-04-11 15:19           ` M. Warner Losh
2006-04-10 15:57     ` Brett (Mare) Henley
2006-04-10 16:02       ` Leonardo E. Reiter
2006-04-10 19:11     ` M. Warner Losh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060411162214.GA16542@jbrown.mylinuxbox.org \
    --to=jma5@umd.edu \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).