Microsoft's hand forced on open-source driver release

A licensing issue with its proprietary Linux drives appears to have helped lead to Microsoft's contribution of GPL code to Linux.

Gordon Haff
Gordon Haff is Red Hat's cloud evangelist although the opinions expressed here are strictly his own. He's focused on enterprise IT, especially cloud computing. However, Gordon writes about a wide range of topics whether they relate to the way too many hours he spends traveling or his longtime interest in photography.
Gordon Haff
4 min read

[Update: Additional commentary from Stephen Hemminger added.]

Microsoft set off a barrage of commentary earlier this week when it released three drivers under the GPL v2 to be part of Linux. The main purpose for doing so appeared to have been to make Windows Server and Hyper-V more effective as a virtualization foundation for Linux guest operating systems.

I was less shocked by the news than some. It struck me as a smart business move by Microsoft to further dispel both the reality and appearance of not playing well with other operating systems and tools. From a practical perspective, offering technology to Linux that lets it work better with Windows pretty much had to be done in the form of open-source code. At the same time, the Microsoft of today is far more accepting of the fact that like it or not, Linux is going to be a fixture at many of its customers and they're going to have to live with that.

Thus, releasing these drivers seemed to make a lot of sense and, while it was clearly a big step on the part of Microsoft, it certainly wasn't inconsistent with the company's recent posture toward open source, especially since Sam Ramji came onboard to be senior director of platform strategy.

However, it now turns out there's another layer to the story.

On Monday, Stephen Hemminger made a posting to his blog, Network Plumber's Journal. Stephen is a principal engineer with Vyatta, an open-source networking infrastructure vendor. Prior to Vyatta, he was with the Open Source Development Labs (and then the Linux Foundation) and was one of the largest contributors of Linux kernel code (PDF).

This saga started when one of the users 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.

By way of brief background, the GPL under which Linux is licensed considers static linking--the combination of software components by a developer--to create a "derivative work" of those components. There are a lot of complexities, nuances, and ambiguities, but for our purposes here, the bottom line is that if you statically link GPL libraries or other GPL'd code into your program, the entire program has to be released under the GPL.

Which Microsoft had not done.

I had a conversation with Stephen Hemminger, who initially reported the potential issue with Microsoft's driver, and he provided me with some additional technical specifics. According to Stephen, the issue revolves around a feature of the Linux kernel called EXPORT_SYMBOL_GPL that allows for interfaces to be marked as only available to modules with a GPL-compatible license. From Stephen's perspective, Microsoft's proprietary code had to use some of these interfaces that "the kernel did not want to offer to non-GPL [code]."

If that all seemed a bit geeky technical, well it is. Very possibly a violation of the GPL but hardly one that is simply flagrantly flouting the law. And, from Hemminger's perspective, "once Microsoft was aware of it, they were eager to resolve." He said that he first discovered this in March, so four months is actually fairly rapid resolution as such things go in large companies.

Greg Kroah-Hartman, who is a fellow at Novell and was very involved in the open-sourcing of the Hyper-V drivers, certainly seems to believe the licensing problem played a role in Microsoft's decision. In an e-mail exchange with ZDNet's Mary-Jo Foley, he writes:

MJF [Mary-Jo Foley]: Hemminger is claiming Microsoft put the LIC code under the GPL because it was in violation of the GPL. Is this true? Did you have to suggest to (Microsoft Platform Strategy Chief Sam) Ramji & Co. that they were in violation in order to get them to agree to release the code under GPLv2?

GKH [Greg Kroah-Hartman]: I didn't have to "suggest" anything, I only had to merely point out the obviousness of the situation  :)

MJF: If this isn't accurate, could you let me know how to interpret (Hemminger's) comments on his blog.

GKH: No, that sounds accurate.

Microsoft itself hasn't commented on the matter.

Based on what we know at this point, I draw a couple of conclusions. The first is that if Microsoft were the Microsoft of five years ago, it would have found some way to mitigate the problem that did not involve releasing code for Linux under the GPL.

At some level, it is now philosophically attuned to working with Linux in a way that it wasn't when one of Sam Ramji's predecessors, Martin Taylor, could be described as "Microsoft's Top Anti-Linux General."

But that said, it seems more than likely that their little license problem provided, at the very least, a forcing function to make their GPL contribution happen.