From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FTLdC-0003q6-7a for qemu-devel@nongnu.org; Tue, 11 Apr 2006 12:22:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FTLdB-0003ph-Jp for qemu-devel@nongnu.org; Tue, 11 Apr 2006 12:22:17 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FTLdB-0003pd-Ba for qemu-devel@nongnu.org; Tue, 11 Apr 2006 12:22:17 -0400 Received: from [128.8.10.163] (helo=po1.wam.umd.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FTLi5-0006hx-2O for qemu-devel@nongnu.org; Tue, 11 Apr 2006 12:27:21 -0400 Received: from jbrown.mylinuxbox.org (jma-box.student.umd.edu [129.2.253.219]) by po1.wam.umd.edu (8.12.11.20060308/8.12.10) with ESMTP id k3BGMFSY003748 for ; Tue, 11 Apr 2006 12:22:15 -0400 (EDT) Date: Tue, 11 Apr 2006 12:22:14 -0400 From: "Jim C. Brown" Subject: Re: [Qemu-devel] why is kqemu closed? Message-ID: <20060411162214.GA16542@jbrown.mylinuxbox.org> References: <41e41e7a0604100820y3a20e731n4fb22e14db01e54e@mail.gmail.com> <3ef9fbda81a71790b3cc0575ebf95538@localhost> <443A8033.9000409@win4lin.com> <443B32A6.20501@foo-projects.org> <443B618F.10600@wasp.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <443B618F.10600@wasp.net.au> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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.