I've spent a lot of time in Dot-Tech Perspectives discussing how .NET applications are intended to communicate by using the proposed Global XML Web Services standards. What I haven't discussed is how those standards can potentially affect the people using them—specifically, how we're paying for them.
Paying for them? Yup. The mechanisms that you're using to read this column online or have this electronic newsletter delivered to your mailbox didn't fall out of the sky; someone (or a lot of someones) developed them. The same is true for the Global XML Web Services we've been exploring for the past several months. However, although you don't pay a license fee to use HTTP or SMTP, you might pay to use Web services, albeit indirectly. Whether you pay depends on what the companies that develop those mechanisms decide to do.
Let's do a little background. Members of the World Wide Web Consortium (W3C) can submit documents, which the W3C calls Submissions, to be made part of the public record. Submissions aren't official proposed standards but rather publications offered by W3C members. A Submission includes the terms under which W3C members have access to the technology that the Submission describes. That access can be either on a royalty-free (RF) basis, or on reasonable and nondiscriminatory terms (RAND), to use the usual proposal wording, and each company with intellectual property in a Submission specifies the terms under which it's offering the technology. For example, Ariba might want to leave open the possibility of receiving royalties for its intellectual property in a particular technology, whereas Compaq might expressly allow companies that implement its intellectual property in the same technology to use the technology without paying royalties.
W3C Submissions aren't "official" proposed standards but might address usage guidelines should the information the Submissions contain become standards. And there's the rub, to coin a phrase—even if a Submission as it is proposed is RF, the owner of the intellectual property that the Submission documents can state that the property will be available on RAND terms if implemented as a standard. As a consequence, developers or companies who follow the standards could be charged for using them. Not punitively charged to favor certain companies (or so I interpret the "nondiscriminatory" in RAND) but charged nonetheless. Because the logistics of charging consumers on a per-usage basis present horrific obstacles, the cost would most likely go straight to developers.
I don't suggest that companies shouldn't be able to make money off intellectual property. But in the case of Global XML Web Services, the standards are proposed alternatives—they don't lock you into one way of doing things. If you don't like one of the Web services options, you can pick another. But if companies such as Microsoft and IBM propose protocols to be used as standards and also patent those protocols, then they can charge companies who try to comply with the standards for using the standards. Yes, individual companies could develop their own ways of implementing Web services—but at the cost of standardization. The W3C is working on a patent policy that would recommend only technologies that are available on an RF basis (that's the plan for now, anyway), but the consortium's working group is still determining how to accomplish this.
If Web services standards do become available only on RAND terms, the range of Global XML Web Services choices will be limited—no question about it. That situation will probably also drive up the price of .NET-compatible software by increasing development costs and reducing competition. It's hard to imagine a royalty dispute blowing .NET out of the water entirely, but making companies pay to follow standards certainly isn't going to help adoption. Perhaps companies that charge fees for using Global XML Web Services standards should send a check to Tim Berners-Lee.
You can go straight to the source and read some W3C Submissions and the W3C's Patent Policy Working Group Royalty-Free Patent Policy at