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.

[an error occurred while processing this directive]

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 organizations 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 Organization for the Advancement of Structured Information Standards (OASIS).

OASIS is the organization 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 jeopardized 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's Talkback.

Previous page |   1 2

[an error occurred while processing this directive]

[an error occurred while processing this directive]