X
Tech

Apache falls victim to OASIS patent shelter

Ever since a debacle with ebXML (subsequently diffused) and, later, the way the Web Services Interoperability organization (the WS-I) selected Organization for the Advancement of Structured Information Standards (OASIS) as the venue for "ratifying" certain Web services standards (as opposed to going through the more IP-progressive World Wide Web consortium -- the W3C), I've been meaning to out OASIS for what I think it really is: a patent shelter.
Written by David Berlind, Inactive

Ever since a debacle with ebXML (subsequently diffused) and, later, the way the Web Services Interoperability organization (the WS-I) selected Organization for the Advancement of Structured Information Standards (OASIS) as the venue for "ratifying" certain Web services standards (as opposed to going through the more IP-progressive World Wide Web consortium -- the W3C), I've been meaning to out OASIS for what I think it really is: a patent shelter. [Update 7/13/05: The WS-I has officially objected to my statement that it was the entity responsible for selected OASIS. For details and a clarification, see my Talkback]. ebXML, by the way, is an international e-commerce standard that was designed by IBM and Sun in record breaking time at the request of the United Nations. 

Whenever vendors need to collaborate on something that they hope the rest of the industry will regard as a standard (open or not), they need to do it under the auspices of some sort of intellectual property (IP) agreement -- an agreement that basically lays out the ground rules for contributing IP to the standard and what if any rights can be asserted by the contributors after the standard is complete.   So, when vendors get together, their choices are to draft a new agreement that everybody has to work with, or turn to one of the existing IP regimes.  "IP regimes" is industry insider talk.  It refers to any of the existing organizations that already have an IP framework in place under which vendors can begin collaboration on a standard.  One advantage of turning to an existing IP regime is that most of their legal frameworks are well understood by the many vendors in the industry.  Not only are they well understood but, by turning to an existing regime, vendors don't have to start a new, stand-alone legal framework from scratch.  They can short-cut the painful process of drafting new legal documents and take advantage of some of the organizational  infrastructure  (staffs, web hosting, etc.) that the existing regimes have to offer. 

Examples of existing IP regimes are the W3C, the Java Community Process (JCP), OASIS, the Internet Engineering Task Force (the IETF), the ISO (International Standards Organization), the WS-I, and ECMA International.  Although virtual, some consider  open source licenses such as the GNU General Public License (the GPL)  to be an IP regime as well (this, however, gets into the netherworld of copyrights vs. patents and I won't be going there, for now).  All of these organizations have boilerplate legal frameworks that their members can use to initiate a project with the hopes that the result of that project will get widely adopted (aka, a standard).  The argument over how open a standard is often focuses on which of the IP regimes it is listed under and how stringent the boilerplate legal framework of that IP regime is.   Not all IP regimes are created equal and vendors looking to start a new project will often pick a regime that's best suited to their business goals.  Those goals can involve everything from the rights they want to maintain once a standard specification is completed to how quickly they want to get the standard ratified.  The W3C and the JCP, some vendors argue, involve way more overhead than do organizations like OASIS.  The more overhead, the longer it takes to complete the standard.  The less overhead, the more quickly a few vendors can get down to business and iron something out.  OASIS fits more into this latter category than does the W3C or the JCP.  ebXML, for example, was finished in 18 months -- regarded by many as record breaking time.  It was done under an OASIS framework.  Several OASIS-based Web services standards may have happened even faster.  

But, in addition to speed, OASIS also offers an incredibly patent-friendly environment.  It's the choice of vendors who want to get some specification out into the market -- one that has the imprimatur of OASIS on it -- without being bound to commonly accepted rules of openness (beauty, by the way, is in the eyes of the beholder.  See Public discourse underway over the definition of "open").   Unlike the imprimatur of the W3C, OASIS' imprimatur gives off the feeling of the specification being some open standard when, in reality, the standard may be nothing of the sort.    Why do I say OASIS is a patent shelter?  Because, at the end of the day, specifications bearing the OASIS imprimatur (one that deceptively communicates "this is an open standard") can still end up with unbearable encumbrances that could come back later to haunt those who adopted them under the false pretense that they were as open as standards from other organizations such as the W3C.  In fact, the patent policies of the two organizations were a central issue to the competition between two Web services specifications (BPEL4WS and WSCI)  for doing the same thing.  Each was backed by a different group of vendors with the WSCI/W3C camp claiming to have the more open, and therefore more broadly adoptable of the two specifications.

So misleading is the OASIS imprimatur with respect to OASIS' patent policy that it sparked a boycott by several open source and free software advocates earlier this year.  And now, perhaps for the second time (but this time a bit more public), the OASIS effect is being felt in open circles.  According to a report in InfoWorld, the Apache Foundation has hit a roadblock in implementing WS-Security -- one of the many Web services specifications that the WS-I made a priority and that was subsequently produced under the auspices of OASIS' patent policy.  Wrote report author Paul Krill, "Although WS-Security is available for implementation royalty-free, it still must be licensed from Microsoft and IBM. Apache has raised concerns about this, mostly pertaining to a non-transfer clause that appears incompatible with open source licenses that allow for uninhibited transfer of technologies, Apache officials said."  The story goes on to point out that WS-Security isn't the only specification with the OASIS imprimatur that requires licenses to be executed with IBM and Microsoft.

This of course cuts to the chase of what it means to be open.  Some believe that royalty-free -- the promise of never having to pay royalties in order to use the standard -- is open enough.  Others say that it's OK for the business terms behind a license to fall to the more patent-holder flexible "reasonable and non-discriminatory" or RAND terms -- terms that OASIS permits.  I say more flexible because, even though many vendors attach a RAND license to their patents without ever charging royalties, the door is left open to do so in the event they change their mind (particularly with new licensees because pre-existing ones may have negotiated RF terms that survive any more sweeping changes in posture).  According to open source advocates, RAND licenses have another major drawback -- that of impeding open source altogether.  In its call to action to OASIS, 29 leaders of the open source community said "This patent policy (available, grouped together with other unrelated legal issues, here) permits standards to be based upon so-called 'reasonable and non-discriminatory' patent license terms--terms which invariably and unreasonably discriminate against open source and free software to the point of prohibiting them entirely."

Quite often, the frequent analyses of the many terms say nothing of the more subtle  encumbrances that can get under the skin of the open left (or is that right? I can never tell with this debate). For example, if I have to execute a license with a patent holder, are there circumstances under which that patent holder can revoke my license -- circumstances that aren't quite in the spirit of "open."   As noted earlier, one such encumbrance -- one that gives open source advocates serious indigestion -- is the non-transferability that comes with licenses that must be officially executed with their licensors.  Every licensee must execute their own license with the licensor.   Such non-transferability is the antithesis of copy-left licenses like the GPL (again, the GPL applies strictly to copyrights and not patents) and runs counter to the open source world's idea of open.  This isn't the first time the Apache Foundation and the issue of non-transferability have intersected with each other. When, during IETF MARID's deliberations over the viability of sender authentication (a standard that could have helped combat spam), it became apparent that a Microsoft  patent might come into play -- one with non-transferable terms -- the discussions suffered an irretrievable breakdown.  The Apache Foundation was one of the first to take umbrage with Microsoft's disclosure and pull its support.

Other encumbrances include onerous IP cross licensing terms, sometimes couched in terms of revocation or non-repudiation. For example,  one open source license that gave licensors a virtual license to steal IP from licensees was the one that was originally assigned to the Eclipse integrated development environment -- the IBM-authored (and Open Source Initiative-approved) Common Public License.  While many open source licenses include MAD terms -- those of mutually assured destruction in the event that licensees or licensors breach the license's terms or attempt to sue one another for misappropriation of relevant IP --  the CPL went one step further than most such terms by invoking mutually assured destruction if a licensee sued the licensor over non-relevant IP.   So, although there were never any reports of it happening, the license cleared a legal path for IBM (the original licensor of Eclipse) to misappropriate any of the IP of Eclipse licensees (even if it wasn't relevant to Eclipse) without fear of reprisal.  If an Eclipse licensee sued IBM for misappropriation of IP -- even of IP that wasn't relevant to Eclipse -- it lost its license to Eclipse.  While the Eclipse Foundation has published a new license (the Eclipse Public License) that falls back to more commonly accepted terms of mutually assured destruction, the CPL has recently turned up on some of Microsoft's open sourced code (take note).

So, while open source advocates have been quick to criticize RAND terms, it's not as if the open source world doesn't have a few of its own skeletons in its licensing closet.  

This brings me full circle back to OASIS and my assertion that it's a patent shelter.   As I implied earlier,  open is in the eyes of the beholder.  Some want licenses that are fully and completely unencumbered--copy-leftable and transferable where appropriate.  Others just wish we could get rid of the legacy of RAND licensing that haunts supposedly open standards and, at the very least, replace them with royalty-free terms (not necessarily open, but at least a big step in the right direction).   One example of where patent regime discussion is sufficiently vague is in what's required and what's permitted.  Thanks in part to its recently revamped IP policy, OASIS now has a boilerplate framework for developing royalty free standards.  Actually, two of them.   But that same patent policy doesn't require or insist on the application of RF terms to all OASIS standards (and I use that phrase very loosely) moving forward.  Instead, it still preserves the option to develop RAND-based standards.   In an internal e-mail to OASIS members, OASIS president and CEO Patrick Gannon wrote "We have not suddenly adopted a RAND policy. The RAND baseline was part of the OASIS IPR Policy that was approved five years ago....To completely eliminate RAND as an option (as the signers of the Rosen petition advocate) would deny those OASIS members who choose to work under those terms their current rights."  Rights that protect patents.   Rights that OASIS members will continue to invoke.

There are may subtleties to standards setting that are not well understood by the consuming masses.  One of those is the OASIS imprimatur which isn't just wrongly taken by many to mean that the specification in question is an open standard, but is also abused to make a specification seem as such in vendor presentations.  It would take many hands to count the number of times that I've experienced the cavalier use of the phrase "OASIS standard" in vendor briefings and at trade events.  Invariably, when it's a one-on-one briefing,  the presenter assumes I'm unaware of the subtleties.   The backtracking starts the minute I say, "But wait a minute." 

Three years ago, I made repeated attempts to contact Gannon about the patent shelter-like nature of the organization he heads out of Billerica, MA.   At the time, I had adopted a fairly aggressive stance in my columns on the issue,  particularly in relation to the direction that Web services standards were taking.  Not surprisingly, those calls were never returned.  My opinion drifted to the back burner where it has been sitting these last three years.  With InfoWorld's recent story, I decided it was time to finally bring it back to the front burner and get it done. 

Editorial standards