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
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
