Enterprise Unix Roundup -- Will SPF Burn Developers?
|Main||In Other News||Security Roundup||Tips of the Trade|
Two weeks ago, we considered the turbulence intellectual property (IP) issues have been causing Linux and mentioned in passing the trouble between Microsoft and the Internet Engineering Task Force (IETF). Microsoft recently decided to become a loud champion of a popular spam-fighting technology called Sender Policy Framework (SPF). Redmond's support for the technology, which has already see widespread adopted from such notables as AOL, Earthlink, Google, and the W3C, came with one qualification: Its much less popular "Caller ID for E-Mail" technology was welded on.
Microsoft has never met a standard it didn't want to embrace and extend (with an eye toward a third "e-word" exclusion of rivals), so a "standard" issuing directly from Redmond is doubly suspicious to a certain set.
On its own, SPF is a promising, albeit somewhat flawed, technology that does something we should all be in favor of: It takes already entrenched technologies (i.e., DNS and SMTP) and adds a trivially implemented record that enables an SMTP listener (like Exchange Server, sendmail, or postfix) to verify that an e-mail claiming to come from a given domain truly originated from an authorized host in that domain.
Microsoft's Caller ID for E-Mail adds a layer to SPF that concerns itself with the headers of the message, not just the envelope, but it has never enjoyed the same popularity. The reasons for that are certainly less technical than social. Afterall, Microsoft has never met a standard it didn't want to embrace and extend (with an eye toward a third "e-word" exclusion of rivals), so a "standard" issuing directly from Redmond is doubly suspicious to a certain set.
Microsoft and SPF's author promptly submitted the new joint specification to the IETF for ratification as a standard (named "Sender ID for E-Mail"), which provoked an immediate hue and cry in the free software community. GNU Project founder Richard Stallman summed up the concerns most succinctly:
[...] This license is an example of Microsoft's strategy for killing off free software as an alternative to Windows. Microsoft first patents something, then incorporates it into a format or protocol, then tries to make it de rigueur while excluding those it wishes to exclude. In the absence of resistance, Microsoft has a good chance of imposing whatever standards it likes. Let us, therefore, resist it here and now.
Mr. Stallman's objections were prompted in part by Microsoft's licensing of its contribution to the joint specification, which subtly but plainly renders the technology incompatible with software licensed under the GNU Public License (GPL) or other free software licenses.
His objections were greeted with vaguely owlish resentment from the IETF working group, which is trying to come to an arrangement with Microsoft regarding that very licensing.
Since then, Microsoft has come back with a new license, but it's still ringing some bells.
As one developer told internetnews, "I write software. I'm sufficiently confused and concerned about the licensing terms and encumbrance of the Microsoft claims that I cannot be comfortable implementing Sender-ID. And I should not need to consult a lawyer just to understand my liabilities should I do so."
If all those patents need patent lawyers to mind them, the court system, in effect, is turned into an IP clearing house mediating between warring companies swapping patent portfolios around like trading cards.
We're not inclined to agree with the second half of that quote, or rather, we agree (it would be nice if no developer ever had to call in the patent attorneys just to write some code), but we don't think that's a realistic desire in today's climate. As the SCO mess has demonstrated, and as our own conversations with technology company leaders have reflected, one way out of the licensing/upgrade treadmill for companies running out of features to add to their products is the creation of a robust IP portfolio from which they can license assorted technologies to other companies. We once spoke to an embedded software executive who couldn't be bothered to discuss product. He wanted to talk about the patent lawyers he had standing by in 65 different countries, ready to swing into action and litigate over unauthorized duplications of a hinged card slot cover.
The social expense of this approach is clear. If all those patents need patent lawyers to mind them, the court system, in effect, is turned into an IP clearing house mediating between warring companies swapping patent portfolios around like trading cards: "I'll give you my revolutionary new imaging library in exchange for two of your metadata searching technologies and a million dollars."
That on its own has an exclusionary effect on the free software/open source models, which are largely initiated by small developer collectives before being taken up by corporate sponsors usually long after they've established their viability. These organizations aren't born as enterprises with patent attorneys, even if they do eventually become Sendmail, Inc.
In addition, the licenses that drive free and open source software place their own demands. They're not tolerant, in a legal sense, of heavy restrictions, and the Linux developer/distributor community has shown its willingness in the past to jettison popular packages that create onerous redistribution restrictions.
We're not here to propose a radical realignment of the nation's troubled IP laws, though. We have only 1,000 words; entire books have been written on the topic.
What troubles us though is the application of aggressive patent licensing in parts of the Internet that touch on infrastructure. Sender ID for E-Mail is connected very intimately to both SMTP and DNS. With broad enough uptake, it could become a technology that remote hosts demand before allowing mail from another host to pass over their electronic thresholds. This would make adopting the technology very much a matter of providing ongoing quality of service.
Linux comprised 9 percent of the server market in the last quarter, largely because of the value it offers for commodity server hardware. Part of its appeal is its robust collection of infrastructure software: DNS daemons, file serving software, and SMTP handlers. Some of this software will not be able to adopt Sender ID for E-Mail if its licensing continues to appear ambiguous or unduly restrictive.
We're resigned to the patent trading card game, even if we're not happy with it. Where matters of infrastructure are concerned, we're fairly sure enterprise Linux users will want to keep a close eye on matters like this one: Seemingly minor issues of software ideology might have a way of coming back around with unpleasant consequences if software companies continue to try to insinuate restrictive patents into the standards that drive the Internet commons.