Nice. Microsoft has released the Hyper-V drivers as GPLv2. I know was a hard step for Microsoft to take, since it means acknowledging GPL and respecting the Linux community. The releasing of the drivers is good news for users, developers, and in the end Microsoft as well. Like most GPL related actions, a lot of work was done behind the scenes to get the offending company into compliance.
This saga started when one of the user's on the Vyatta forum inquired about supporting Hyper-V network driver in the Vyatta kernel. A little googling found the necessary drivers, but on closer examination there was a problem. The driver had both open-source components which were under GPL, and statically linked to several binary parts. The GPL does not permit mixing of closed and open source parts, so this was an obvious violation of the license. Rather than creating noise, my goal was to resolve the problem, so I turned to Greg Kroah-Hartman. Since Novell has a (too) close association with Microsoft, my expectation was that Greg could prod the right people to get the issue resolved.
It took longer than expected, but finally Microsoft decided to do the right thing and release the drivers.
Subscribe to:
Post Comments (Atom)
16 comments:
Nice job!
Nice !
"The GPL does not permit mixing of closed and open source parts, so this was an obvious violation of the license."
Naive question: How do ATIs and Nvidias drivers manage to do it??
ATI and nVidia use an open source shim that interface with the kernel ABI so that the binary blob can be the same and the shim can simply be updated to link to the kernel itself.
This is a bit of a gray area but Linus Torvalds considers this okay, so that's how that works.
Isn't that what we have here, though? A GPL shim with closed objects?
directhex@desire:/tmp$ ls drivers/dist/blkvsc/blkvsc_drv.c drivers/dist/closed/blkvsc/blkvsc.x86_64 | cat
drivers/dist/blkvsc/blkvsc_drv.c
drivers/dist/closed/blkvsc/blkvsc.x86_64
directhex@desire:/tmp$ grep GPL drivers/dist/blkvsc/blkvsc_drv.c
MODULE_LICENSE("Dual BSD/GPL");
(repeat for the other 3 drivers)
It does kind of look that way, doesn't it?
Hi,
> Isn't that what we have here, though? A GPL shim with closed objects?
No, at least not according to Don Marti:
http://marc.info/?l=linux-elitists&m=124845857504772&w=2
cjb, maybe it's insufficient caffeine, but I'm not seeing that in Don's email. Can you point out to me specifically where he's saying this?
Hi Lefty,
> cjb, maybe it's insufficient caffeine, but I'm not seeing that in Don's email. Can you point out to me specifically where he's saying this?
Don's responding to [this is a binary blob] with [no it isn't]. A binary blob is a phrase exactly used to describe "a GPL shim with closed objects", which is what we're talking about. So, I think "the actual Linux instance here is blob-free" is Marti saying "this is not a binary blob/closed object code/GPL shim situation", which is in disagreement with what directhex commented above.
Does that clear it up?
Well, it clears up the assertion, perhaps. I'm currently still a little more persuaded by directhex's description of the actual structure of the driver directories than I am by Don's assertion...
For better or worse, I don't have access to these drivers, so I have to rely on the information others (i.e. directhex) have provided...
Oops. Thanks, I see.
I'm still rather confused, though. With the kernel submission, we have a GPL driver that talks to the hypervisor but doesn't link to it -- I wouldn't say that this is a "binary blob", or at all objectionable.
So, what do we have with this package? What's the closed/ blob actually used for, and why isn't it needed with the kernel submission? Is the GPL driver in this package used as a shim, which would mean it's different code than the submitted driver?
(Sorry, I don't know anything about this, evidently. :)
The ISO I linked to is the original version of the "Linux integration components", for providing the virtual devices Hyper-V wants. It consists of GPL shims and closed binary-only object files (only vertified for SLES).
The recent news has been about their REPLACEMENT - which is all source, all GPL, including replacement GPL versions of what was previously closed-source.
The debate is whether the original image (not the current kernel submission) is a GPL violation or not. My stance is "only if nvidia-glx is" since I don't see any obvious difference
> The debate is whether the original image (not the current kernel submission) is a GPL violation or not.
Okay. Stephen and Greg K-H have stated that they think it was an obvious one, but Greg K-H is on record as saying that nvidia-glx is illegal too. I'm surprised that Microsoft is still distributing it.
Releasing it under the GPL was a great step, but getting Linux to perform well on Hyper-V still a tough task it require as much work as showing in an article I found on Optimize Linux for Hyper-V
I am not sure if there is any easier cut to get it perform well faster, but I still failed to find any.
So those are kernel drivers, right? So tell me which other license they shall have chosen for kernel drivers? AFAIK usung another license but GPL (and maybe BSD – IANAL) is grey area and asking for trouble when it comes to kernel drivers. My Blog : earn money chao!
Post a Comment