Microsoft has responded to claims that its Linux Integration Components (LIC) were only contributed under the GPLv2 after being out of compliance with the GPL in the first place.

It's important to note that LIC was pre-existing code available from Microsoft. The version I downloaded only supported Novel Suse, but it seems Red Hat Enterprise Linux was supported also. Until a few days ago, this code was not completely under the GPLv2. How much was, and whether GPLv2 and non-GPLv2 code was combined in a manner that violates the GPLv2, is at the root of this story.

A well-known Linux contributor, Stephen Hemminger found the LIC prior to its contribution under the GPLv2. He writes:

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.

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.

If I'm reading the statement correctly, Microsoft disputes that the decision to release LIC under the GPLv2 was based on any obligations resulting from the use of GPLv2 components within the original LIC code available prior to July 20. Sam does state that Greg K-H helped Microsoft understand the "community norms and licensing options." Hence, the decision to release LIC under the GPLv2 was simply a business decision. It is possible that the business decision was influenced by what customers and "the community" would think if the questions about the LIC compliance with the GPLv2 came to light.

Having said that, I can't understand what value Micrsoft would see in keeping this code under a non-Linux-friendly license. By ensuring that this code makes it into the Linux kernel, Microsoft is making it much easier for customers to deploy Linux on Microsoft Windows 2008. I go back to my "this was a business decision" view.