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

[Leonardo E. Reiter]

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:
> <snip>
> 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.
>
> Cheers,
>
> Auke

--
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
http://www.win4lin.com