[Top][All Lists]

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

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

From: Leonardo E. Reiter
Subject: Re: [Qemu-devel] why is kqemu closed?
Date: Tue, 11 Apr 2006 11:05:56 -0400
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051013)

Hi Auke,

First, let me apologize for not giving you proper credit for suggesting the MODULE_LICENSE fix to Fabrice. But, without starting a flame war here, I want to respectfully disagree with a couple of points you make:

1. virtual machine software _is not_ trivial. Not by any means. It took my company about 20 years to fully develop what became Win4Lin 9x, if you trace its history back to before Linux existed (product called 'Merge'). This was paravirtualization mind you - basically what Xen is trying to do now, except that we didn't have the luxury of making source-level patches to the guest OS, like Xen does. The fact that Fabrice has been able to engineer KQEMU as quickly as he has, is a tribute to his design, and he has every right to keep that secret. He has done what has taken VMware far longer and cost them millions to develop, and in my opinion, the KQEMU implementation is better

2. I understand of course that applications are not kernel space... however, there are instances where useful applications must provide components in kernel space. To reiterate my point, it is very difficult to convince any vendor to write or port good software to Linux if they will be forced to accept a license as restrictive as the GPL in _any_ capacity. A *BSD type license is much better for everybody (consumer, business, hobbyist, academic, etc.) IMHO, but I respect your opinion to thinking the GPL is superior. You have the right to your opinion.

3. Yes of course the industry gravitates toward open standards. However, open standards are not necessarily "open source", and definitely not necessarily GPL even if they are open source. Having an open document format or an open communication protocol is something industry loves, but that doesn't force vendors to code everything in GPL. It still allows vendors to provide whatever value and protect whatever IP they choose, yet prevents vendor lock-in when it comes to data. All important vendors that I can think of except of course Microsoft are on board with this. As for fully open source implementations of VM software, can you name a single one that runs Windows (desktop or server) guests, at near-native speeds? I've been in this sector of the software industry for 5+ years (and many more years outside this sector), and I can't name one. Xen is awesome, but it won't provide this functionality until Vaderpool and Pacifica are deployed. And even then, there is a huge installed base out there of chips that do not have VT or Pacifica extensions, so there will be a market for other solutions rather than Xen for years to come. Trust me, it is my job to analyze such trends. And guess what? Windows servers surpassed all Unix server sales combined (including Linux) recently (see published studies by respected industry watch groups, not paid by Microsoft), so yes, virtualizing Windows operating systems is key to the widescale adoption of any VM software today. This may change in a few years, but you can't make the claim that industry is moving to open source when Microsoft is selling more servers than ever.

4. There is a slippery slope here - if Linux kernel policies can change to force all kernel-space binding to be GPL (even though Linus decreed that this is not the case years ago), what's next? Libraries that make kernel interface calls should be GPL rather than LGPL? Next of course any application using one of these libraries (read: any app on Linux) must be GPL? Forget that hypothesis for a second... what if I am a hardware vendor in a desperately competitive market, such as say, video cards. Releasing my source code to the driver would mean giving up some IP that allows me to surpass the capabilities of my competitor for a few weeks. What motivation do I have to show competitors my competitive advantage, just so I can say I released a driver for Linux? Do you think it's mere coincidence that most hardware vendors stick to Windows as their main driver platform? There are 2 things at play here: 1) not enough market share for their products on Linux, and when you combine that with 2) restrictive policies when it comes to making drivers available, then no self-respecting software engineering manager in any hardware company can make a good business case to release drivers for Linux. If we keep making it more and more difficult for closed source drivers to exist on Linux, more and more hardware vendors will just give up altogether. This means less adoption for Linux from end users (if you can't use your hardware, then why bother) - and of course means less quality closed source apps (like Photoshop, which is still the gold standard despite the excellent capabilities of GIMP) ported to Linux because there is less and less market share. If our goal here is "total world domination", then we cannot exclude vendors of any type. Of course "free software" developers spend night and day implementing open source drivers from the ground up, but this doesn't increase the end-user (pragmatist, non-hacker) adoption of Linux right away. Not when they can use their devices on Windows _right now_.

Anyway, I know that my points have little or no credibility with you because I am a vendor. Just wanted to clarify a few things (and this is my last note on the subject, so feel free to have "the last word"),

Leo Reiter

Auke Kok wrote:
I actually submitted this as a patch to him through this list ;^)
<snip> applications != kernel space code. It would be rather *good* for linux if all kernel-space processes were open sourced, even for trivial things like VM emulators ;^)

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 with that. Whatever the laywers say about it is moot - only judges listen to them and Open Source doesn't listen to laywers (in generally). Plenty of vendors are already backing up Open Source too, and not just with t-shirts and penguins.

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 ;^)

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.



Leonardo E. Reiter
Vice President of Product Development, CTO

Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501

reply via email to

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