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

[Jim C. Brown]

On Tue, Apr 11, 2006 at 11:05:56AM -0400, Leonardo E. Reiter wrote:
> 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

Agreed, in full.

The only 2 open source virtualization efforts I know of are the old plex86 which
failed and vmbear, which is brand new (and has the easier goal of virtualizing
only linux for the time being).

If we are allowed to step outside of the x86 platform, I can think of one more
open source virtualizer:  Mac-On-Linux. This one is fully open source and does
real virtualization so it is probably as fast as VMware (though the speeds can
not be directly compared obviously) - but it doesn't have to do the hard job of
virtualizing the braindead x86 instruction set.

> 
> 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. 

This currently is not the case anyways. Vendors can release non GPL modules.
This of course translates into more work for them (as the official kernel
maintainers can not help to provide support, fix bugs, help with new ports, etc)
but that is the cost of giving up an open source license.

> 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.

My own personal opinion: the GPL is superior because it ensures that all the
software under it remains open source. And open source (GPL, BSD, etc) is
superior to closed source because I can hack on the code myself to make
desired customizations or do my own bug fixing.

I will grant that it is possible to hack on and do these same changes to the
machine code of software released in closed binary form. But most closed source
licenses/EULAs prevent disassembly or modification to the binary form, so even
if I wanted to try it would be illegal for me to do so.

For non programmers however, there is no difference between BSD and GPL.
For these kinds of users, it is arguably important to keep the vendors happy.

> 
> 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. 

Agreed.

> 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.

I don't keep up to date on the number of servers bought/sold, so no comment
there.

I agree with you on the comment about there not being an open source virtualizer
that can run windows yet (qemu w/o kqemu can, but that is not virtualization,
and qvm86 is far behind kqemu) - but I honestly do not see the market rushing
to choose kqemu here.

> 
> 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? 

To be absurdly pendantic, GPL-compatible. :)

If this situation ever actually occured, it would be possible to fork a version
of the Linux kernel (and the GNU parts like glibc, etc) and keep those under
the original license (with the original exceptions).

But if it ever came to that, we'd probably have a large migration to FreeBSD,
so no one would actually bother to make the effort. ;)

> 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? 

Ironically, this is what software patents are for.

I think the GPL3 has a good compromise here - put ur IP in a patent and then
release the driver as open source. Either the competitor stays closed and thus
can't take advantage of the code, or it opens up and thus gives you the chance
to take advantage of their code.

Another acceptable compromise - keep the product closed source as long as it is
competitive so you can make money - but when it is no longer a cash crop, give
up the source code.

> 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. 

I doubt the "restrictive" policies play any part in this. We have plenty
of binary 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_.

I agree with you here, on the part of hardware vendors leading to less linux
adoption.

I disagree that closed source is superior for hardware vendors - but this is
getting very off topic.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.