If Microsoft uses those IPR rights to erect obstacles--in the form of royalties or denials of licenses--the result could well be the antithesis of a standard. Compliant products might be available only from one company--Microsoft. Imagine the color red established as the international standard for stop signs, but the color is only available from one company.
According to Microsoft, third-party developers who want to develop or deploy an implementation of C# development tools and CLI-compliant virtual machines, which are part of the .Net framework, must enter into a reasonable and non-discriminatory (RAND) license agreement with Microsoft. That's the short answer.
The complete answer requires delving into the intricacies of how Microsoft has structured its .Net technology.
.Net has several components. One is a virtual machine called the Common Language Runtime (CLR) that bears some resemblance to the more robust version of Sun's Java Virtual Machine (JVM), known as Java 2 Enterprise Edition. Other .Net components, such as ADO.NET and ASP.NET, bridge that runtime environment to the various services available from the Windows operating system. Today, companies can enhance Windows servers with .Net by obtaining the .Net components from Microsoft's Web site or if they use Microsoft's Visual Studio.Net software development tool. Starting with the next edition of the server versions of Windows--Windows .Net Server--the various .Net components will come built-in to the software.
Usually, the advantage of runtime environments like Sun's JVM and the Microsoft's CLR is the "write once, run anywhere" portability of the code. If a programmer writes code to deploy on such a runtime, that code should run unchanged on any version of that runtime. Part of Java's appeal has been the availability of the JVM on numerous platforms such as Windows, Macintosh, Linux and various proprietary versions of Unix including Solaris, AIX, HP-UX, and Tru64.
So far, however, Microsoft's CLR is only commercially available for Windows. There is also a trimmed down version of the virtual machine for PocketPC 2002 that Microsoft calls .Net Compact. Because of the limited number of target platforms, JVM-like portability is not the CLR's chief selling proposition. In lieu of portability, the CLR features support for languages beyond C#. The CLR framework is designed to support all of the languages that Visual Studio.Net supports as well as other languages snapped in by third parties. ActiveState, for example, has snap-in support for Perl, Python, and XSLT.
The benefit of this feature is that it's much easier to get modules developed in different languages to interact with each other. This offers programmers the flexibility to pick the language they prefer for the task at hand. While the CLR isn't commercially available on Unix or Linux, for example, a subset of it (code-named Rotor) was developed for non-commercial deployment on FreeBSD.
Whereas the CLR consists of some 3,800 classes, the number of classes in the Rotor subset is around 1,200. In turn, the CLI is a subset of Rotor and consists of a mere 350 classes. "The CLI standard is a minimal set of things you needed to deploy an execution environment," according to Microsoft's group program manager David Stutz, "Unlike the CLR or Rotor, however, the CLI is not a product you can run. Rotor and the CLR are strictly implementations that are compliant with the ECMA standard. The idea behind a standard specification like the CLI then (as with any standard) is that third parties could develop their own commercial implementations of the specification."
But the first question that those third parties must ask is whether another commercial deployment of the CLI standard--say, for Linux or Unix--could infringe on a Microsoft patent. According to Microsoft's director of intellectual property Michele Herman, who I interviewed earlier this year, the answer is a qualified yes. "If someone implemented a product that conforms to the specification, we believe we have a patent or one pending that's essential to implementing the specification." Herman also cautions that "to the extent that other vendors that have developed other applications or middleware and have patents on them, those vendors could also choose to enforce those patents if the relevant intellectual property is essential to deploying an implementation of the CLI."
According to Herman, third parties will have to enter into a reasonable and non-discriminatory (RAND) license agreement with Microsoft. "But," says Herman, "while RAND sometimes means there could be a financial obligation, [Microsoft] …will be offering a conventional non-royalty non-fee RAND license. We've always made that clear to anyone who has asked." In other words, there will be no financial obligation.
If the specification is royalty-free, then why need a license at all? Herman says that there are some standard parts to such a "conventional" license. Let's look at a few.
Reciprocity: : "This is where I say I will license a royalty-free license to my essential patents, and in return I expect you to license your essential patents to me on an royalty-free basis. This keeps you from charging me a fee for the same thing," Herman explained. This gray area of what is essential could be a thorny problem. For example, if you're a software developer, could reciprocity allow Microsoft to claim that it now has access to your entire patent? This industry is full of patent suits borne from cross-licensing disagreements.
While the fear may be valid, Herman raises another point that is in some ways unique to Microsoft. From a business perspective, Herman asks if the publicity of such a lawsuit would be worth it to Microsoft. Good point. Not only is the company already perceived as being one of the industry's biggest bullies, but governments all over the world now have it under their microscopes because of Microsoft's business practices (some which have been deemed illegal, and others not). Initiating a lawsuit that splits hairs over what's relevant and what's not in a cross-licensing agreement would probably cause more problems than they're worth to Microsoft.
Defensive suspension: "This," says Herman, "is where I say I'm granting you this license, but if you sue me, I have the right to revoke it." This also has a thorny problem attached to it. Apparently, the legal community is not in agreement about when it's appropriate to revoke a license. For example, can the original suit be about anything, or does it have to be relevant to what was licensed? The jury is apparently still out on this question.
Field of use limitation: According to Herman, "This is where I'm granting a license to you to use my patent, but only for the purpose of implementing this standard." In other words, it describes the scope of the allowed use, which seems reasonable to me.
Sub-licensing prohibition: "This means someone else can't come along and license the patent or transfer the license we issued to them to someone else," Herman said.
Sub-licensing is the stipulation that enrages open-source advocates. If an open-source developer agrees to the license, the resulting implementation cannot be re-licensed under something like the General Public License (GPL). According to Herman, "the field of use (you get a license only to implement the standard for the purpose of conformance) and the prohibition on sub-licensing are inconsistent with the requirements of Sec. 7 of the GPL. Sec. 7 of the GPL says that if you do not have the rights to distribute the code as required under the GPL then you do not have the right to distribute at all. The GPL says you must have the rights to sublicense and to freely modify outside the field of use limitation."
It's probably for this reason that Microsoft's Chief Technical Officer Craig Mundie is getting flack from the GPL community for making it clear that Microsoft will enforce its patents against open source projects and, referring to the legal warchest needed to fight such a battle, for open-source advocates who want to legally challenge that to "get their money out." If a .Net implementation leaked into the open-source community, Microsoft would lose the benefit of the controls that the aforementioned conventions put into place. So, after all this, what's my gut sense of whether this is another IP quagmire like the one that's been brewing over the future protocols of the Internet?
First, given the limited functionality of the CLI when compared to Rotor, or even the full-blown CLR, it's hard to imagine a lot of third parties racing to create implementations of the CLI when there are much more full featured virtual machines available from Microsoft and Sun. Perhaps this is the reason that when you talk to Ximian founder Miguel de Icaza, he's quick to remind you that Mono, Ximian's Linux-based version of .Net, is neither a reproduction of Rotor or the CLI. His intent is to duplicate the full functionality of .Net. To that extent, Mono falls far outside any licensing agreement Microsoft has published and it's no wonder that when I last spoke with Icaza, he wasn't sure whether Microsoft was going to anything about Mono. Reproducing .Net's functionality has never been one of the options in Microsoft's licensing agreements.
Secondly, to the extent that Microsoft is a high volume software company and has pretty much stuck to that business model, it's not clear whether Microsoft would benefit more from widespread availability of third-party versions of .Net (or some subset thereof) or from the restricted availability of the same.
On one hand, the widespread adoption of .Net and its parts could mean a windfall for Microsoft's development tools. Few products would be as well tuned to developing for the .Net environment as Visual Studio.Net.
On the other hand, if the best implementation of .Net is only available from Microsoft, widespread adoption of .Net (and demand for the development tools) might be softened. That softness in the demand for the development tool however could be offset by the fact that those who want to deploy the most robust version of .Net would probably pick Windows .Net Server to do it--thus an increase in demand for Windows .Net Server.
Of the two--the development tools or the server--Microsoft stands more to gain from selling more servers since it's desperately trying to unseat bigger iron incumbents like Unix and IBM mini/mainframes from corporate data centers. But if Microsoft did attempt to manipulate the standards setting bodies and the industry in a way that so blatantly tried to disadvantage competing application server and operating system competitors, governments, industry and the press would probably hold Microsoft's feet to the fire in ways that Microsoft just can't afford.
