Slashdot Mirror
Microsoft Releases Linux Device Drivers As GPL
mjasay writes "Microsoft used to call the GPL 'anti-American.' Now, as Microsoft releases Hyper-V Linux Integration Components (LinuxIC) under the GPL (version 2), apparently Microsoft calls the GPL 'ally.' Of course, there was little chance the device drivers would be accepted into the Linux kernel base unless open source, but the news suggests a shift for Microsoft. It also reflects Microsoft's continued interest in undermining its virtualization competition through low prices, and may suggests concern that it must open up if it wants to fend off insurgent virtualization strategies from Red Hat (KVM), Novell (XEN), and others in the open-source camp. Microsoft said the move demonstrates its interest in using open source in three key areas: 1) Make its software development processes more efficient, 2) product evangelism, and 3) using open source to reduce marketing and sales costs or to try out new features that highlight parts of the platform customers haven't seen before."
Care to explain to me how this plan can follow after releasing something under the GPL?
They can sue for infringement of software patents.
I think you have this precisely backwards. The GPL is about protecting the rights of users to modify the software they use and distribute those modifications. So it does, in fact, give control to the end user--the sort of control that Microsoft does not tend to give--while the author relinquishes some control.
Oh, you mean like this: http://www.onekit.com/store/review/microsoft_deal_gives_samba_access_to_windows_protocol_documentation.html
Also, did you consider that TomTom had some patents on thing MS might be using, and thus only sued to get a deal to be struck? http://yro.slashdot.org/article.pl?sid=09/03/20/0215215
Na... just let your beliefs obscure any facts.
Even the GPL v.2 has this to say about patents:
For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
So basically, if MS holds patents on the code they are contributing, my reading of the GPL says they can't contribute it (or can't enforce said patents).
Care to explain to me how this plan can follow after releasing something under the GPL?
They can sue for infringement of software patents.
Um. Okay, let's dissect this. Microsoft has released device drivers under the GPLv2 which states:
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
Emphasis mine. I would find it more than hilarious to see the reaction on the faces at the EFF if Microsoft tried to sue someone who modifies/redistributes/forks this GPLv2 licensed code. By Microsoft releasing this under the GPL, Microsoft has basically announced there are no patents or copyrights on this code--otherwise they would not have been able to license it under the GPL. If so, Microsoft would have no one to sue but themselves before they demand people stop using the code.
I'm still not convinced on your argument. Don't get me wrong, I'm as cautious as the next guy. But isn't the GPL pretty rigorous (even v2) at protecting us from our fears?
My work here is dung.
They could have.
No, they couldn't have, at least not if they wanted it to be distributable with Linux (which was kinda the point). The Linux kernel is GPL v.2 only, which is incompatible with the GPL v.3.
Furthermore, even the GPL 2 provides some protection against patents, as a couple people have pointed out.
In short, FUD.
Our use of the GPLv2 license, as requested by the Linux community, means we will not charge a royalty or assert any patents covering the driver code we are contributing.
Sam
sramji@microsoft.com
Big deal. Such drivers are trivial.
Virtualizing physical I/O devices on PC-like architectures requires code in the hypervisor to emulate the device. The driver in the operating system does stores into "device registers" as if talking the real device. Each such store or load causes a trap to the hypervisor, which has a device emulator watching the register changes and pretending to be the real peripheral. When the right registers have been loaded with the right values, and the final register store is made that would start the I/O operation, the device emulator then figures out what the OS wanted to do, and makes a call to the hypervisor's I/O system to do it.
In many cases, the device driver in the OS is doing all the optimization for the device controller of a real disk, doing angular optimization and head movement minimization. Since the real device underneath may be completely different, most of this is wasted work, and may reduce performance instead of increasing it.
So it's common to have dummy device drivers for virtual machines that just pass the OS's request through to the hypervisor, without trying to manage a real device. Such drivers don't do much, and are usually trivial, although Microsoft will probably try to complicate them somehow.
This isn't a new idea; it first appeared in IBM's VM for the System/370, where such calls were passed through using the DIAGNOSE instruction (an opcode used for hardware diagnostics only, and thus never used in ordinary programs and available as a spare opcode.)
One of the hypervisor vendors calls this "paravirtualization".
You are really funny! Actually, I'm the head of Open Source and Linux Strategy for Microsoft Corporation. I'm from Oakland, California.
Sam
sramji@microsoft.com
First, the Hyper-V high-level specification is available under the Open Specification Promise; this can be used by 3rd parties to implement Hyper-V compatibility.
Second, we have a roadmap for the drivers that includes improvements to performance and manageability, including features like SMP support. These have been requested by our customers and are part of the engineering plan for these drivers.
Third, our maintenance plan for the drivers includes submitting patches to the kernel maintainers; and the process that Greg K-H and the team follow is designed to ensure that drivers can continue to be compatible with the kernel even if the kernel's model for device drivers changes.
Ultimately it will be the market success of this technology that will ensure its ongoing development by Microsoft - as we do with any product. So far the signs are good.
Sam
sramji@microsoft.com
It was specifically talked about. We considered other licenses (like the Clear BSD) which is considered "GPL-compatible" but the best choice was clearly the GPLv2.
This was the gentle advice we got from Greg K-H and we took it seriously. The more we thought about it, the more it made sense to follow Rosen's first law of open source licenses - "use the license of the community that you want to contribute to."
Sam
sramji@microsoft.com
I know this will probably sound snarky but I don't honestly get it. Why exactly would you want to run Linux server as a guest and have Windows server as the host? That just doesn't make any sense to me at all, and I'm a Windows guy.
I think you're confused. Hyper-V is a hypervisor, not host-based virtualisation. It runs on the bare metal, with a privileged Windows VM for management tasks (equivalent to dom0 on Xen, or the Service console on ESX).
You might want to use Hyper-V to run Linux because you have already committed to Hyper-V for your virtualisation infrastructure. This may be as simple as just having a single Hyper-V server running only one or two VMs, or as complete as multiple hosts with a substantial amount of established processes and procedures for managing that virtualisation infrastructure.