decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


To read comments to this article, go here
What is Wrong with RAND?
Thursday, April 17 2008 @ 12:02 PM EDT

I wrote the day before yesterday that RAND terms can be discriminatory, and that in fact due to the Microsoft OSP, OOXML is discriminatory against the GPL and Open Source licenses, despite being made available under RAND terms. Microsoft's Jason Matusow responded with a blog entry suggesting I need to bone up on standards and licenses. Why Microsoft folks can't be polite is a mystery to me, but I persist in responding with decency. He thought it would be helpful to hear from lawyers on the subject. So, I did some research for him, and I find that there are quite a number of lawyers who agree with me.

So here you are, Jason: what is wrong with RAND from folks whose credentials you will respect. They are not radical or extreme, and neither is Groklaw, as you will see. The problem, rather, is that Microsoft is wishing that time would stand still for it, and that the old, proprietary software model were all that there was in the world. However, like the music industry, Microsoft -- and standards bodies -- now have to cope with the new and modern software development model and licenses that foster and underpin it, not just the old-fashioned, closed, and patent-licensed model that Microsoft represents. And isn't it you at Microsoft, and your friends at CompTIA, who have told the governments of the world that one business model should not be favored over any other? How much less should a standard?

It isn't just me noticing this problem with RAND terms. Some lawyers have already said pretty much the same thing I did, as collected by Wikibooks. Here's a lawyer for you, Seow Hiong Goh, Director of Software Policy/Asia, Business Software Alliance, yes, the BSA itself:

Certain FOSS licenses, particularly the GPL (see note below), contain restrictive terms concerning free redistribution, derived works and distribution of license that create a direct conflict with RAND terms. Even where there are no royalties or other fees associated with a RAND patent license, the GPL is still at odds with the field-of-use limitation, restriction on sublicensing and reciprocity requirement, the three common terms in standards-related patent licenses....

Note: Unlike the vast majority of FOSS licenses, the GPL prohibits the distribution of software under the GPL if the software includes any patented technology that is licensed under terms at odds with the GPL. Hence, the requirement that the software be freely distributable, for example, is at odds with any RAND license which permits reasonable royalties, and accordingly the patented technology associated with such a RAND license may not be included in FOSS distributed under the GPL. A developer of FOSS distributed under the GPL may be unable to implement open standards covering RAND-licensed patented technology in its products, thereby impairing such software's interoperability potential.

It is a known problem, therefore. Responding that RAND is widely used and you believe in patents doesn't alter the effect of this combination Microsoft crafted. The end result is that OOXML is not usable by your number one competition, and you have to know it. Responding that it's up to your competitor to change its license terms is not a realistic option, since that is the same as saying that the entire development model of FOSS has to change and be more like you. The whole point of the model is to encourage sharing, and that is why Linux and other projects continue to advance so rapidly, while you folks give us Vista. We don't wish to be like you.

Dan Ravicher of the Software Freedom Law Center has also explained how RAND terms can be discriminatory:

RAND, to the extent that it has the historical meaning of allowing an owner of a patent that covers a standard to charge a license fee to any person that adopts the standard, is an oxymoron for free and open source software, because any requirement of the charging of a license fee is - by definition - neither reasonable nor non-discriminatory. Thus, most RAND licensing is - in fact - unreasonable to and severely discriminatory of free and open source software because it precludes such software from existing. As such, standards covered by patents licensed on a RAND basis generally cannot be implemented into free and open source software, unless the RAND license is actually royalty free.

See? And that is precisely the problem with the OSP. RAND worked fine when everyone was proprietary and all followed that closed off model; but it clashes with the new open model, and some adjustment needs to be made to accommodate the new, along with the old. That is obvious. It's no more fair for Microsoft to demand the GPL and other FOSS licenses stop being what they are than it would be for FOSS to demand that Microsoft has to go GPL. We make no such demand, and Microsoft shouldn't try to compel the GPL to give way to a more proprietary model either, and that is what Microsoft is doing, throwing tacks in the roadway for the GPL. RAND terms limit patent licensing to a degree, but they don't change the obvious incompatibility with the GPL and any patent license fee, and that is the problem.

Here's an opinion on what true interoperability should mean, from "The Roadmap for Open ICT Ecosystems", published by Harvard's Berkman Center for Internet & Society. First, though, they tell us who developed this paper:

This Roadmap represents an unprecedented collaborative effort of senior government officials from thirteen nations, thought leaders from five global organizations, experts from two leading technology companies and academics from one of the world’s most respected universities.

On page 4, it lists some guiding principles of an open IT ecosystem. Here's what it says interoperability means:

Interoperable -- allowing, through open standards, the exchange, reuse, interchangeability and interpretaion of data across diverse architectures.

Even the BSA says the same, in "Technology Standards & Interoperability - Why We Should Care About Them" [PDF], p. 7:

Open standards can be implemented by both proprietary and open source software.

Would you honestly claim that OOXML meets that definition? Neither would I. The GPL is the license on Linux, which is open source software. Therefore, a standard that excludes it is not an open standard, and if a license deliberately excludes the GPL it is discriminatory in effect and intent. If you want true interoperability, you need to implement ODF. Seriously. Any limitations to interoperability are entirely on Microsoft's side of the aisle, and the whole world knows it. So why not let the GPL in? You aren't going to get any money to shake a stick at from your patent licenses via OOXML anyhow. So why not fix the OSP to let the GPL in too?

The Roadmap paper was edited by Jeff Kaplan, Founder & Director, Open ePolicy Group, Berkman Centre for Internet and Society, Harvard University, and here's what he is quoted as saying about RAND:

Despite its appealing rhetoric, RAND is not an objective benchmark. "Reasonable" is in the eye of the beholder; it is an undefined criteria only a lawyer could love. Worse, RAND can be a wolf in sheep's clothing, bringing new forms of lock-in under the guise of "openness."

Standards have degrees of openness, mainly due to restrictions and encumbrances placed upon them by vendors. The fact that a standards organization labels a standard open is not determinative. Its effect in the marketplace is a better guide.

At a minimum, open standards must allow all possible competitors to operate on a basis of equal access to the ability to implement the standard. They should not drive others to follow any specific proprietary path or effectively foreclose any software development model. A standard that in effect blocks open source developers from its implementation is not an open standard.

Any conditions (RAND or otherwise) that have the effect of limiting competition, leaving control in the hands of a single vendor, or hindering interoperability - for example, proprietary extensions of a standard- are incompatible with open standards. Ultimately, open standards must allow for self-directed innovation.

This, obviously, is where ISO fell down on the job.

The Microsoft OSP does discriminate against the GPL and other FOSS licenses, because it does not "permit all possible competitors to operate on a basis of equal access to the ability to implement the standard." Hopefully the EU Commission will focus on this issue, since ISO failed to do so.

And the problem with the OSP isn't just patent license fees. It's the restrictions on sublicensing. That too keeps the GPL from being able to use OOXML. But, you may say, maybe Microsoft just doesn't realize this is a problem. So I thought it was worth pointing out that the OSP's restriction on sublicensing, which directly conflicts with the GPL and most Open Source licenses, is the identical issue that a number of lawyers, including Lawrence Rosen, informed Microsoft was a problem back in 2004 when Microsoft was pushing SenderID under a similarly restrictive license.

Microsoft knows perfectly well that any license, like the OSP, that prevents or restricts sublicensing rights can't be used by for FOSS developers, therefore, because a number of lawyers and organizations clearly informed them of it publicly in 2004, so the limitations on sublicensing in the OSP are not due to mistake or confusion, I'd have to conclude, but to a policy of deliberate exclusion. So any pretense that RAND terms are sufficient to create a fair and nondiscriminatory playing field is a sham, and I would think we would be forgiven for believing it is a deliberately crafted one.

For that reason, my hope is that the EU Commission in its investigation will look beyond just the irregularities, many though they were, and hone in on the real anticompetitive issue surrounding OOXML -- that Microsoft's only real competitors can't use the license for OOXML. And Microsoft knew it when it published it.

So you can hear this from lawyers and not just little ol' me, here's what Rosen informed Microsoft personally back in 2004:

"The open source development and distribution process works as well as it does because everyone treats open source licenses as sublicenseable, and most of them are expressly so. Open source licenses contemplate that anyone who receives the software under license may himself or herself become a contributor or distributor. Software freedom is inherited by downstream sublicensees. Meanwhile, the Microsoft Sender ID patent license continues the convenient fiction that there are 'End Users' (S1.5) who receive limited rights. That is unacceptable in open source licenses. "I have explained to Microsoft that their license is expressly incompatible with the warranty of provenance in the Academic Free License and the Open Software License: 'Licensor warrants that the copyright in and to the Original Work and the patent rights granted herein by Licensor are owned by the Licensor or are sublicensed to You under the terms of this License with the permission of the contributor(s) of those copyrights and patent rights.' (AFL/OSL S7) "The 'nontransferable, non-sublicenseable' language in their reciprocal patent license (S2.3) also imposes an impossible administrative burden on the open source development community and, in essence, creates additional downstream patent licenses that will be incompatible with the AFL/OSL and similar open source licenses, and with the open source development process. "The requirement that Microsoft Sender ID patent licenses be formally executed (e.g., S6.10) is incompatible with the way the open source development and distribution process actually works. Furthermore, the requirement that 'If you would like a license from Microsoft (e.g., rebrand, redistribute), you need to contact Microsoft directly' (S2.2) gives Microsoft information about its competitors' plans that it has no reason to know. No open source license -- and *all* of them allow rebranding and redistribution -- can be conditioned on informing Microsoft of anything at all.

You may be asking what Microsoft's reaction was on learning of this incompatibility, and here's a report from "Sender ID: A Tale of Open Standards and Corporate Greed?" published in CircleID:

After the new Microsoft license was published, it was reviewed by Eben Moglen, the legal counsel of the Free Software Foundation (FSF) and Larry Rosen, the legal counsel of the Open Source Initiative (OSI). They have both stated that this license is not compatible with the General Public License (GPL) and possibly other open source licenses.... Microsoft lawyers have concurred with that analysis in regards to the GPL in their updated FAQ published a few days ago. Aside from this, the very act of Microsoft knowing about possible competitors in the email business, is in itself rather disturbing. And to stir the pot, the viewpoint of Microsoft lawyers on the subject is rather die hard and strange. They have stated that they would rather see Sender-ID die than change the license, according to Eric Allman of Sendmail. Eric commented on this by stating that "it's pretty clear that it's going to take an act of whatever deity Microsoft worships in order to get them to back down on the sublicensing issue."

The Debian project, the Apache Project, and attorney Eben Moglen all publicly mirrored these concerns. Richard Stallman said this about the SenderID license restrictions:

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.

And Microsoft said in a FAQ -- which used to be at http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx but is now completely gone from the Internet (Update: Wayback has it, and here's the July 1, 2004 version), other than some place like on Groklaw which quoted it at the time, which is why you shouldn't rely on any promise from Microsoft that appears only on its own website, by the way -- that they understood that there was a fundamental conflict between the sublicensing restrictions of its license and the GPL:

"Q15: Is Microsoft’s Royalty Free Sender ID Patent License compatible with the GPL?

"A: Unlike other open source software licenses, the GPL includes a provision that appears to prohibit the distribution of code that is subject to patent licenses that are not sub-licensable and/or are limited for a particular purpose like implementing a specification. While almost all open source licenses require that the code be freely modifiable and redistributable with or without modification, only the GPL appears to expressly prohibit distribution of code if those requirements can not be satisfied. Microsoft's Royalty Free Sender ID Patent License Agreement does not prohibit the use of any open source license including the GPL. However, because the Royalty Free Sender ID Patent License Agreement is offered for implementation, distribution and use of the specification, Microsoft believes that the GPL would prohibit the distribution of this patented technology. As discussed in the answer to Question 7, it might be possible to use and distribute Sender ID implementations with Linux and other software released under the GPL.

"Q16: What happens if I combine my Sender ID implementation with GPL code?

" A: Where conditions of the GPL can not be satisfied, the GPL prohibits you from distributing your code under the GPL. If you combine your Sender ID implementation with code that purports to subject your Sender ID implementation to the terms of the GPL, you could be violating this requirement of the GPL. You should seek your own counsel concerning whether or not your implementation would be subjected to the GPL and, if so, whether the GPL would prohibit the distribution of your code. The Free Software Foundation www.fsf.org may also be an appropriate source for your inquiries about the GPL."

So, what has changed? The OSP doesn't require notifying Microsoft of anything, so that is progress, but the sublicensing issue remains. And until that is changed, the anticompetitive nature of any such licensing restriction remains as well, and no RAND terms can mask that simple reality.

And finally, speaking of modernization, I'd say this to Jason directly: Others have already tried to damage Groklaw's reputation to try to keep the public from believing what it reads here. It didn't work. Here's why. The Internet means everyone has unlimited ink nowadays, so to speak. It used to be possible to destroy reputations in a controlled media. But you can't do it now, because the intended victim gets to respond.


  View Printable Version


Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )