Microsoft's hand forced on open-source driver release

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

[monkeyfun14]

Wow..

[Random_Walk]

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

Err, Microsoft released and included GPL code in Microsoft Services For UNIX, long before five years ago... they just kept quiet about it (they had little choice, since the GPL code was there when Microsoft bought the company providing the original SFU package).

[ghaff]

Thanks for the info. I had forgotten about Services for Unix although, as you say, it was the Interix (?) team and not really core Microsoft code. But you're right that this wasn't the first time Microsoft had open sourced code. The SFU contribution (at least the initial one) was before Linux really hit it big and Microsoft started to view it as a serious threat. Microsoft had generally been reasonably accommodating to *nixes at that point because they were, in many cases they were the incumbents (and Microsoft was gaining on them) so they generally saw interoperability as something that advantaged them. But at some point after 2000, Microsoft started to hit back at Linux aggressively.

[Random_Walk]

I was thinking it was Interix too, but for some reason I'm not sure if that was the name ("Connectix" keeps barging into the memory as well... but it's probably Interix).

"...was before Linux really hit it big and Microsoft started to view it as a serious threat."

That would make sense. Even @ the 2001 Networld conference, there was a Microsoft guy happily compiling code on Windows 2000, with gcc (using SFU and --I think Cygwin?-- to do it) right there in the Microsoft pavilion. He was happily bragging on how interoperable SFU made things in a Linux-heavy environment.

I'm thinking that at that time, Microsoft was of two minds about Linux - one half was hating how they no longer could compete against the "expensive" UNIX servers (Solaris, AIX, and the like) for server business, while the other half didn't really think that --outside of Internet properties-- the enterprise would take Linux seriously.

I think it all gelled at around late 2001 with the "cancer" comment and the beginning of some really ugly FUD campaigns.

[ghaff]

@Random_Walk

Connectix was the company that did the hosted virtualization software that became Virtual Server after Microsoft bought them.

[Random_Walk]

Ah - that makes sense... and it became VirtualPC (which I still have on my old PPC/G5 Mac).

Thx for helping ease the Alzheimer's :)

[jimmyed2000]

My guess is that, when faced with the situation, they only had a few choices:

1) Withdraw the drivers - and withdraw from that market.

2) Fight the GPL in court. This would directly contradict Microsoft's stated position and generate a huge amount of negative press.

3) Put the drivers out under GPL V2, and turn it into a PR win. There is probably not much code, and no patented code in the drivers, but they would have checked this first.

Given these three options they chose the one that was the least painful.