[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.
Standards evolve in a lot of different ways. However, broadly speaking, they fall into two main buckets: de jure and de facto (to use the Latin-derived legalese). By law and by fact.
In high tech as elsewhere, it's often a matter of historical accident and political maneuvering that determines which approach wins out in a particular area of technology. And it can be a high-stakes game for the companies involved, with big players often seeking to position their approach as a "standard" even if it's only standard in the sense of being ubiquitous (think Microsoft Windows) while the smaller guys tend to favor approaches blessed by standards bodies or at least industry corsortia.
In cloud computing, we're seeing almost all the forms of standards-making coming into play with the primary goal of promoting interoperability among different cloud service providers and between private and public clouds.
On the de jure side, the most significant standards-making effort is taking place under the auspices of the Distributed Management Task Force (DMTF), an established organization in the management standards space. AMD, Cisco, Citrix, EMC, HP, IBM, Intel, Microsoft, Novell, Red Hat, Savvis, Sun Microsystems, and VMware announced in April 2009 (PDF) that they would comprise the board for an Open Cloud Standards Incubator within the DMTF.
If you were to observe that none of those companies currently have a big play in public cloud infrastructure, you would be correct. Microsoft has its Platform-as-a-Service Windows Azure play, and a number of those companies are very active in working with enterprises to build internal cloud-style IT, but none have an Infrastructure-as-a-Service (IaaS) offering in the vein of the conspicuously absent Amazon.
And it's Amazon Web Services (AWS) that has clearly emerged as the de facto standard for IaaS. The fact that Amazon is one of the first vendors that comes to mind in just about any discussion of public clouds is one indication. Another is the growing ecosystem of companies like RightScale that add additional features to AWS--not uniquely, but first and foremost. We now even have an open-source project and company, Eucalyptus, that lets organizations implement their own clouds that are compatible with many AWS services.
Now one of Amazon's competitors, Rackspace, is taking yet another approach to promoting its implementation as a standard. It's open-sourcing the specifications for its Cloud Servers and Cloud Files API under the Creative Commons 3.0 Attribution License. It also has made available its Cloud Files language bindings for Java, PHP, Python, C#, and Ruby under the MIT license.
The Creative Commons license that Rackspace is using lets users both share and change the work so long as they provide attribution to the creator, in this case Rackspace. The MIT license is a very permissive license in the vein of BSD that allows essentially any use of the code including its use within proprietary software.
Rackspace has emerged as a major player in public cloud infrastructure. Cloud Servers competes with Amazon EC2 and Cloud Files with S3. It also has a product called Cloud Sites, based in part on technology from its Mosso acquisition, that is more of a PaaS offering with dynamic scalability (but that's not part of this announcement).
This announcement doesn't fundamentally change the landscape. However, it does give an already well-established IaaS vendor a point of clear differentiation from its biggest competitor.
If the license wars aren't over, they've certainly muted.
The adoption of the new version of the General Public License, used by Linux and many other open-source projects, was a long, loud, and contentious process. But after all the sturm und drang, it's not clear to me what real impact GPL 3 will have.
Depending on whom you ask, clauses concerning ideological sticking points such as digital rights management were either narrowed in scope or defanged almost completely. And it seems entirely possible that Linux, perhaps the best-known open-source project licensed under the GPL, may never move to the new license version.
More broadly, I just don't feel that there's a whole lot of interest, much less passion, out there in the various open-source communities for fighting license battles. That's not to say that everyone agrees that there is one perfect approach to licensing. Not all all! But there is, for the most part, a pragmatic understanding and a realization that the license for a given open-source project has to match up with its governance, collaboration, and even business model. It's just one piece of the puzzle.
In a similar vein, there are just so many accumulated examples of different approaches that have succeeded. Yes, Linux is successful, and it uses GPL 2. But the very popular Apache Web server uses a much more permissive license (in the sense that enhancements don't need to be contributed back to the commons). The Firefox Web browser uses a license that's somewhere in between.
We've also accumulated a lot of evidence that open source is simply a pretty effective development model that can bring a lot of benefits to those who use it. As a result, there's less of a sense that open source needs protection through a restrictive license.
None of this is to say that lawyers and license geeks don't sometimes get into squabbles over how various licenses interact, and so forth. But, in the grand scheme of things, these are micro issues, not macro ones.
I think the best evidence for the winding down of the license wars comes from what's happening around cloud computing, which I define generally as software and infrastructure accessed in the network.
As I've written about previously, the provisions in the GPL, and many other open-source licenses requiring that modifications and enhancements to source code be contributed back to the public, often don't apply in a cloud-computing world. That's because accessing software in the form of a service over the network isn't "distribution," the event that triggers the requirement to make source code available.
Some view this state of affairs as a loophole, one that a variant on the GPL 3--the Affero GPL (AGPL)--explicitly plugs by expanding the definition of distribution to encompass the delivery of services over the network. The AGPL effectively remaps the rules from the original Unix-like environment in which the GPL was born into a network computing one.
What's striking to me is how few people seem to really care about the AGPL and the supposed problem it's trying to solve. Yes, there are the zealots who go apoplectic at the thought of open source being used for profit-making purposes. And there's a fair bit of discussion about how to best protect portability, privacy, and so forth in a cloud-computing world.
There's also no small degree of what might be best called social or community pressure on large cloud vendors such as Google to make meaningful contributions to open-source projects. But forcing all this through licenses? Not so much.
"Real world" examples of some trend or business model are great. Theory is fine up to a point but eventually it's awfully nice to connect up with a concrete example that gives the theory some real cred.
At the same time, examples can mislead us. Often they turn out to be anomalies. Maybe a company is some sort of historical quirk, a product of a very specific time and place. Or maybe some technology approach is valid enough--but only for a very narrow set of needs. One warning sign is seeing the same tired examples trotted out for every discussion, every news article, and every conference.
I see some of that in all the following cases. I certainly won't go so far as to say that the underlying trends or business models are illusory. But I do think they're more limited or further away than their most overenthusiastic proponents suggest.
The Long Tail, as popularized by Wired's Chris Anderson is a hot meme of the blogging and Web 2.0 crowd. Simply put, the Long Tail states that bestsellers aren't in the majority when you tally up the sales at Amazon or Netflix. Rather it's the total of the far more numerous other 80 or 90 percent of content. From a business perspective, the significance is that there's money to be made selling what's in the long tail.
However, the number of true long tail businesses gets thin outside of aggregators of digital media--the companies who have minimal costs to acquire, inventory, and sell incremental low-volume products. Amazon, in particular, is a highly atypical, if not unique, retailer in terms of scale. In fact, we're starting to see a body of evidence that suggests that the long tail is, if not necessarily wrongheaded exactly, more limited in applicability and degree than some of its proponents have suggested.
We've also seen pure Open Source much touted as a viable business model. By "pure," I mean a model that doesn't hold any software back for paying customers only. The hope is that enough users will elect to pay for support and other services to cover a company's cost and profit. Red Hat, a profitable and growing company, is the poster child here.
But Red Hat is exceptional really. It's emerged as the unquestioned leader among enterprise Linux distributions, one of the most visible and core elements of the entire Open Source world. And its financial success is helped, in no small part, because it's selling a value, ISV application certification against Red Hat Enterprise Linux, that doesn't have the equivalent in layered software products. Other pure Open Source plays have also been modestly successful, but we're certainly not talking Oracle or Microsoft levels of success--nor, indeed, Sybase or SAS levels. Even Red Hat pulls in well under $1 billion in annual revenues, and may also be starting to hit the limits of low-cost customer acquisition enabled by free downloads.
Other cases involve long-term trends that almost certainly will have an increasing impact over time. More software is moving out into the network "cloud," and--in an at least peripherally-connected shift--thin clients of various stripes are beginning to move beyond their historical ghettos in call centers and other narrow use cases. However, the oft-cited Salesforce.com and many Citrix case studies aside, these shifts will be far more gradual and incremental than the enthusiasts would have us believe. Enterprises will be slow to adopt Software as a Service for anything they consider even vaguely core and the traditional fat client PC model may be flawed in a lot of ways, but it is familiar, well-understood, and has huge inertia.
I love examples. They help give me confidence that something has at least a patina of reality. But, in the singular, they constitute anecdotes and not data. And anecdotes don't really prove anything. In fact, they can mislead by giving the atypical more weight than it deserves.
- prev
- 1
- next
