My recent reports regarding how Microsoft and IBM's control of next-generation Internet protocols could lead to the two companies' control of the Internet itself have resulted in a flood of responses via e-mail and ZDNet's TalkBack forums.
But one note--from ZDNet reader Frank Beier Jr.--stuck out as a call to action for me to explain what this controversy means to you. As my colleague David Coursey noted in "What Microsoft-IBM Web conspiracy?," "There are some things customers probably don't need to watch being made: The one we know about is sausage. The other is standards." Indeed, the issue of standards-setting seems esoteric to most of us.
But standards-setting affects everyone-consumers, IT managers, CxO's, companies large and small that provide technology products today (or are thinking of doing so tomorrow), and even the global community of nations. Here's why.
Consider the Web applications you've deployed in support of your business' bottom line. Most companies support simple applications, such as allowing customers to come browse their sites. Browsing is one example of an Internet application where all the protocols needed to make it work are freely available. To run your Web site, you can rely on a set of standard protocols like HTTP, HTML and TCP/IP, without any financial encumbrances from royalty seekers. That set of protocols is called a stack. Other Internet applications rely on other freely available protocol stacks. Examples include FTP for file transfer, NNTP for newsgroups, and SMTP for e-mail. Each application relies on a slightly different stack (usually with the same protocols like TCP/IP at the bottom). Today those stacks, from top to bottom, are royalty-free.
Will future applications be royalty-free?
But these rudimentary applications barely scratch the surface of the Internet's potential capabilities. The question is: Can you see yourself tapping into the more advanced applications that will emerge in the next decade? If so, there is an increasing possibility that those applications will rely on protocol stacks that are not entirely royalty-free. For example, royalty-free protocols such as TCP/IP and HTTP may still be at the bottom of the stack, but the new protocols that ride on top of them, such as WS-security may not be royalty-free.
Those royalties could reach into your pocketbook any number of ways. If you are hosting or supporting some of those next-generation applications on your Web site, the owners of the non-royalty-free parts might try to bill you. It's been tried before by Unisys, and currently by British Telecom.
Or perhaps those IP owners will charge the software vendors that make products that support the protocols. One category of software that could be affected is Web application development tools such as those from Borland or Macromedia. Another vulnerable category: application servers and Web servers. Examples of application servers are Oracle's 9iAS and BEA's WebLogic. Web servers are available from outfits like Netscape and Apache.
There's a degree of device independence built into these protocols, too. For example, they will make it easy for the manufacturers of handheld wireless devices and Net-enabled gaming consoles to build in capabilities for retrieving data and content available via Web services protocols. However, the manufacturers of those devices may also be subject to royalties and would no doubt pass that cost on to consumers.
Likewise, if the software vendor wants to build those new stacks into the next version of their software (the version that you might update to), that vendor may have to pay a royalty to the patent holders and then pass that cost on to you. But if the vendor can't afford those royalties, they may choose not to include the new stacks in their software. The same goes for device manufacturers.
As a result, you may have to turn to someone who does. You could turn to a third-party that offers the protocol stacks as an add-on. But that increases the number of products you have to keep track of and puts the burden on you to integrate them.
Patent holder's edge
But, if the patent holders offer the software or hardware that you need and that already includes the relevant protocol stacks, you'll have three reasons to prefer their products.
First, because they are the patent holders, they get to operate in a royalty-free environment. Their products could be cheaper than ones offered by other companies who must pay royalties.
Second, patent holders have inside information on how they plan to evolve the technology. They're not required to share that information unless a court of law steps in and says they must do so (as might be the case in the Microsoft antitrust proceedings). Based on the Microsoft or Apple business success, we are more likely to buy products from those who created and control the underlying platform.
Third, if other companies don't offer the standard protocol stacks in their products (perhaps because they can't or won't pay the royalties), we may have concerns about the long-term outlook for those products, and maybe even the company. IT managers don't want to buy products today that may be gone tomorrow, thereby forcing them into a costly rip-and-replace project somewhere down the line.
This last point is particularly important, especially in light of a Department of Justice/Federal Trade Commission hearing, now underway, that is addressing the intersection of antitrust and intellectual property law and policy. If the market begins to favor the patent holders' products for any of the aforementioned reasons, the result could be what antitrust experts call a "foreclosure on competition." When perfectly executed, such a foreclosure results in a monopoly. In this case, where the relevant intellectual property could end up belonging to just two companies (IBM and Microsoft), it would be called a duopoly.
In any market where a monopoly, duopoly or oligopoly exists, those who dominate have the power to charge their customers anything they want since no alternatives to their offerings exist. When multiple companies engage in such a practice, it is often referred to as price fixing, which requires a high degree of collaboration. Over the last two years, Microsoft and IBM have worked closely together on Web services protocols such as UDDI, SOAP, and WSDL and on the organisations that address them.
Home-grown code not immune
Finally, according to Karl Best, IT departments that grow their own code aren't immune from royalty fees either. Best is technical director of operations for the Organisation for the Advancement of Structured Information Standards (OASIS).
OASIS is the organisation that recently partnered with the United Nations to produce ebXML, a key Internet standard that greases the wheels of international e-commerce. The United Nations has a vested interest in making sure that developing nations can freely participate in international e-commerce. The Internet represents a potential revenue stream for fledgling economies. ebXML, especially if it's royalty-free, improves the chances that developing nations will be able to tap that Internet-based revenue stream. The United Nations expected ebXML to be royalty-free.
However, the royalty-free future of ebXML was suddenly jeopardised by an IBM disclosure that it owns relevant intellectual property and that "implementers" of two important ebXML specifications could obtain a license from IBM on a reasonable and non-discriminatory basis if they wanted to deploy the specs. In other words, IBM can charge a royalty. According to Best, the term "implementers" includes not only companies that make the products that support the relevant ebXML specifications, but a any IT department that chooses to write its own code. Days after ZDNet published that story, IBM said it will make the relevant material available at no cost.
Are IT departments that develop their own code to build support for Web services protocols running a risk of encountering royalties? That's still unknown, because most of the legal documents and disclosures needed to assess that risk are difficult to find and access or haven't even been written yet.
Are there other hidden ramifications when vendors assert their intellectual property rights over standards? What can be done to get this mess back on track? Come out of the woodwork and let your opinion be known on ZDNet Australia's Talkback.
