The Spread of the Non-Assertion Covenant
Thursday, June 15 2006 @ 02:31 PM CDT
Contributed by: Andy Updegrove
An hour or so ago Sun Microsystems made good on an earlier pledge to issue further "non-assertion covenants" (NACs) in support of open standards. In doing so, Sun has taken an important step in helping propagate and popularize a useful new tool to facilitate the implementation of open standards. The new NAC appears here, and relates to the OASIS Security Assertion Markup Language (SAML) V2.0 standard. Simultaneously, Sun is announcing a separate NAC relating to two other specifications co-developed with Microsoft: Web Single Sign-on Metadata Exchange Protocol and Web Single Sign-on Interoperability Profile.
These new NACs are modeled on the earlier commitment delivered by Sun to OASIS in connection with ODF. You can find a detailed analysis of what that NAC promised in this earlier blog post (Sun's Simon Phipps describes it here), which contrasted the Sun NAC to one issued shortly thereafter by Microsoft with respect to its XML Reference Schema (since submitted to Ecma, and now referred to as Open XML). The Microsoft NAC is further examined here.
The reason all of this matters is that an NAC has a number of distinct advantages over a traditional open standards commitment, and offers a way to streamline both the standards development, as well as the standards implementation, processes. Here's why.
First of all, a vendor can issue an NAC unilaterally, and even in advance of the commencement of a standard setting process. This would typically occur at the time that the vendor offered technology to a standards organization to serve as the basis for a needed standard. In doing so, it can set everyone's mind at ease regarding the absence of any hooks or "gotchas" later in the process.
Second, the commitment can also be far more specific than is currently permitted in the antitrust-sensitive environment of standard setting, where multiple competitors meet in the same place. In such a setting, any mention of specific price or terms involves the risk that price fixing or other market manipulations may be in process. While such "ex ante" disclosures are currently very much under discussion in the IEEE and elsewhere, these discussions are still in their early stages, and many in-house counsel (and others) are understandably nervous over the potential for incurring unwanted legal risks.
Third, unlike many RAND commitments, the NAC's referred to above are self-executing, meaning that that no implementer has to go to the trouble of obtaining a license at all. Instead, the NAC (also sometimes called a "covenant not to sue) simply states that anyone that implements the specification need not worry that the patent owner granting the NAC will "assert a patent" against - i.e., sue -against the infringer (hence, the name "non-assertion covenant" or "covenant not to sue").
A further advantage is that with an NAC, everything is out in the open - and everyone gets the same deal. In contrast, as I pointed out in a recent post, a RAND (reasonable and non-discriminatory) license commitment can either lead to a publicly-posted clickwrap license that anyone can use, or to just the contact information for the patent owner. In the latter case, this leaves the terms between the patent owner and the implementer to be negotiated in private, with no implementer knowing in fact whether its terms were the same as another's.
Contrast the self-executing, absolute nature of an NAC, for example, with the current contretemps between Adobe and Microsoft, where Adobe is under an obligation to license its PDF patents - but is still entitled to negotiate the terms of that license with each would-be implementer.
And last, but hardly least, NACs can be very friendly to open source implementation. Typically, with a RAND commitment each person or entity in the distribution and/or development chain needs to return to the patent owner to get its own license, violating the terms of many open source licenses. With an NAC, the rights to implement already exist for everyone. Hence, unless the NAC includes a restriction that is otherwise incompatible with open source licensing, the way is clear.
Hopefully, this clean and simple practice will become more common in the standards arena, just as the statement by IBM that it would not assert 500 patents against open source software implementations was quickly followed by similar assertions by Sun, Nokia and others. The result of those declarations has been a growing "patent commons" in support of open source software.
It seems that the non-assertion approach is also gaining ground. Scan downwards on the same Webpage at which the Sun NAC appears and you will see that in April, RSA upgraded an earlier RAND licensing commitment it had made o an NAC, and that the percentage of NACs to RAND commitments is tipping towards the former over time, as evidenced by the IPR disclosure record of SAML.
The bottom line is that this is a good thing, and a practice that one can hope will be repeatedly adopted by other technology vendors as well.
For further blog entries on Open Source and Open Standards, click here