Microsoft GPLv2 code – donation or obligation?

Earlier this week Microsoft announced that it was contributing driver code to the Linux kernel under the GPLv2, and we published a CAOS Theory Q&A to discuss the implications. It has subsequently become clear that there were two important questions that were not answered by our Q&A:

Q. Is this a donation, or an obligation?

A. In discussing the motivations for the Linux Integration Components (Linux IC) release, Microsoft cited enhancing the performance of Linux as a guest operating system where Windows Server is the host, and that the GPLv2 is “the Linux community’s preferred license”.

An alternative viewpoint began to emerge that suggested that perhaps Microsoft had little choice in the decision to release the code, however. It started with the publication of a post written by Stephen Hemminger, a principle engineer at Vyatta, which stated:

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

Kroah-Hartman runs the Linux Kernel Driver Project and is working with Microsoft to introduce the Linux IC code to the Linux kernel. He appeared to confirm Hemminger’s perspective when he wrote “Steve gives a little more of the backstory of what caused me to start talking to Microsoft in the first place,” and then told Mary Jo Foley that her suggestion that “Hemminger is claiming Microsoft put the LIC code under the GPL because it was in violation of the GPL” was “accurate”.

Cue stories such as “Linux community pushed Microsoft to hand over its code” and “Microsoft opened Linux-driver code after ‘violating’ GPL“.

Before commenting on these stories I took the opportunity to speak to Sam Ramji, who seemed genuinely surprised by the perspective that the driver code had violated the GPL and maintained that he was not aware of the account provided by Hemminger prior to its publication.

The two viewpoints are not necessarily mutually exclusive. In his exchange with Foley, Kroah-Hatmann notes that he “didn’t have to ‘suggest'” that Microsoft was in violation, he “only had to merely point out the obviousness of the situation”.

Additionally, Vyatta’s vice president of strategy and marketing, Dave Roberts, has noted that “nobody ‘accused’ anybody of anything. Stephen merely called the situation to Microsoft’s attention… There were no threats, no screaming, no broken fingers, no frothing at the mouth. Just a few calm phone-calls placed behind closed doors, out of the limelight and media focus. And that was that. Microsoft noodled on things. And then it decided to open source the drivers and contribute them to the kernel.”

I also put it to Ramji that if, *hypothetically*, Microsoft were to have discovered it was inadvertently in violation of the GPL, then from a PR standpoint, the company would have much more to gain by being seen to have responded appropriately than by trying to cover it up. He agreed.

(And I don’t think this can be understated actually, if you consider what the open source group within Microsoft is trying to achieve you begin to understand why they would be hyper-sensitive to the fact that trying to claim credit for something they didn’t do would be counter-productive).

Anyway, Ramji has subsequently posted his views on the issue, including:

“Microsoft’s decision was not based on any perceived obligations tied to the GPLv2 license. For business reasons and for customers, we determined it was beneficial to release the drivers to the kernel community under the GPLv2 license through a process that involved working closely with Greg Kroah-Hartman, who helped us understand the community norms and licensing options surrounding the drivers.

The primary reason we made this determination in this case is because GPLv2 is the preferred license required by the Linux community for their broad acceptance and engagement. For us to participate in the Linux Driver Project, GPLv2 was the best option that allowed us to enjoy the tremendous offer of community support.”

Q. So was Microsoft in violation of the GPLv2?

A. Of course, “not being accused of being in violation of the GPL” is not the same thing as “not being in violation of the GPL” but it is not completely clear whether that was actually the case.

Over on Cnet, Gordon Haff got some more technical details from Hemminger:

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

UPDATE – The Software Freedom Law Center’s Bradley Kuhn has told SDTimes that Microsoft *was* likely in violation of the GPL:

“It seems to me that Sam [Ramji] is likely correct when he says that talk inside Microsoft about releasing the source was under way before the Linux developers began their enforcement effort,” said Bradley Kuhn, a policy analyst and tech director at the SFLC.

“However, that talk doesn’t mean that there wasn’t a problem. As soon as one distributes the binaries of a GPL’d work, one must provide the source for those binaries, so Microsoft’s delay in this regard was a GPL violation.”

However, Ramji continues to deny that a GPL violation was the significant issue. “Greg’s coaching on how to get it contributed was invaluable, but it was not the original driver of our plan or decision,” he told SDTimes. “That’s the beauty of the real world. Different people have different perspectives, and that is what causes them to act. We appreciate Greg’s coaching regardless of his motivation.” – UPDATE

2ND UPDATE – Sam Ramji has once again denied that Microsoft violated the GPL. In a podcast published at Network World he points out (from 15.30) that the code did not statically link to libraries in the Linux kernel, but to the header files, and that Linux developers are split on whether that constitutes a violation of the GPL. “The act of compiling to a header file doesn’t generate a GPL obligation to my knowledge, that was never a consideration in our process.” – 2ND UPDATE

In his initial blog post, Hemminger stated that the saga was started by an inquiry about supporting Hyper-V network driver in the Vyatta kernel, presumably this one, from March, when Hemminger has said the issue was bought to his attention. Hemminger’s response at the time is that “Msft hyper-v driver is not open source, and redistributing it would require agreement with them”.

The driver cited in that query would appear to be the original Linux Integration Components for Hyper-V, which were released in September 2008, the same components that The H reported were previously withdrawn from release candidate distribution in July 2008 for a licensing review.

As Patrick O’Rourke noted at the time, “Licensing is tricky when open source and proprietary software are packaged.” No kidding.

A quick note while we are on the subject of timing, Hank Janssen says he proposed that Microsoft open source Linux IC driver code in October 2008. Sam Ramji told me Microsoft started seriously considering it in January this year and first heard from Greg Kroah-Hartman in May.

While Hemminger started that Microsoft’s release of the code under the GPLv2 “”took longer than expected”, Gordon Haff notes that Hemming “said that he first discovered this in March, so four months is actually fairly rapid resolution as such things go in large companies.”

Q. Anything more to add?

A. Probably. If anything new does arise, we’ll post details here.

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

8 comments ↓

#1 451 CAOS Theory » Microsoft contributes to Linux kernel: a CAOS Theory Q&A on 07.24.09 at 6:38 am

[…] were two important questions that were not answered by our Q&A. Those have been covered by an addendum – UPDATE. Permalink | Technorati Links | Bookmark on del.icio.us | digg it Categories: […]

#2 451 CAOS Links (caostheory) 's status on Friday, 24-Jul-09 11:39:45 UTC - Identi.ca on 07.24.09 at 6:39 am

[…] http://blogs.the451group.com/opensource/2009/07/24/microsofts-gplv2-code-donation-or-obligation/ […]

#3 Andy Ruddock on 07.24.09 at 7:03 am

Using symbols only intended for GPL code via the EXPORT_SYMBOL_GPL and then not licensing that code under GPl is more than “geeky technical”, it is indeed FLAGRANTLY flouting the GPL.

#4 451 CAOS Theory » Microsoft's GPLv2 code - donation or obligation? « Computer Internet and Technology Articles. on 07.24.09 at 9:49 am

[…] the rest here: 451 CAOS Theory » Microsoft's GPLv2 code – donation or obligation? July 24th, 2009 | Tags: conferences, licensing, links, linux, mobile, networks, podcast, security, […]

#5 What Is The Code To Enter Into A Dish Network Universal Remote For A Bose Wave Radio? | Electronics Audio Products, Reviews and Accessories on 07.24.09 at 1:47 pm

[…] 451 &#67AO&#83 Theor&#121 » M&#105crosoft's GPLv2 code – donat&#105on or obl&#105gat&#105on? […]

#6 Hank Paulson on 07.27.09 at 7:49 am

I’m in complete agreement with Andy Ruddock’s comment above. Claiming anything else is very biased and wrong.

#7 Microsoft embraces GPL, opens Hyper-V to Linux with LinuxIC | SataByte.com on 07.31.09 at 10:37 pm

[…] 451 CAOS Theory » Microsoft's GPLv2 code – donation or obligation? […]

#8 451 CAOS Theory » None leading Linux kernel development on 09.15.09 at 10:18 pm

[…] Microsoft is contributing more and doing more for Linux than Canonical? Microsoft’s recent contribution of GPLv2 Linux drivers, delays notwithstanding, marks perhaps a greater kernel contribution from […]