CP RSS Channel
About Our Sponsors
Articles & Papers
Technology and Society
|Sun Microsystems Publishes Non-Assertion Covenant for SAML Implementations.|
Sun Microsystems has issued a 'SAML Non-Assertion Covenant' in connection with OASIS Security Assertion Markup Language (SAML) specifications being created by the OASIS Security Services (SAML) TC. Sun's unilateral, voluntary waiver of its right to enforce possibly relevant patent claims alleviates the burden upon implementers to negotiate license terms, eliminates paperwork, and creates a favorable environment for the develoment of open source software.
This most recent example of a non-assertion covenant follows Sun's public declaration in connection with ODF: on September 30, 2005 Sun Microsystems published a declaration of non-enforcement of its U.S. and foreign patents against any implementation of the Open Document Format for Office Applications (OpenDocument) v1.0 Specification or of any subsequent version of ODF. This non-assertion covenant was praised as a creative mechanism for patent management in the OASIS open standards development context. Similar declarations have been made by Fidelity Investments, RSA Security, and America Online, Inc. in relation to the SAML specification(s).
According to an official Sun comment, the Sun SAML Non-Assertion Covenant contains
"... proactive promises coming from Sun about not enforcing patents against developers using SAML v2.0... For SAML, this means that developers of SAML technology can be assured that Sun will not impose on them any licensing terms, conditions or fees for the use of any patents held by Sun related to SAML v2.0. Developers need not do anything active in order to get this assurance; they merely need to refrain from attempting to enforce their own (or others') patents against any other SAML-implementing developer.
Sun is doing this because SAML is a critically important technology, and we think it's important to provide as many assurances we can to developers implementing SAML technology — particularly open-source developers..."
The promise not to enforce applicable patents by Sun and others represents an attempt to "remove development barriers" by going beyond the nominal requirements of the Legacy OASIS Intellectual Property Rights (IPR) Policy, applicable to the work of the OASIS Security Services (SAML) TC as of 2006-06. Patents (potentially) applicable to SAML were identified in the 2002-2004 timeframe, and the Legacy IPR Policy only advocates for "reasonable, non-discriminatory terms" [RAND] licensing terms, with the clarification that "The OASIS Board of Directors will not make any explicit determination that the assurance of reasonable and non-discriminatory terms for the use of a technology has been fulfilled in practice; it will instead use the normal requirements for the advancement of OASIS specifications to verify that the terms for use are reasonable..." Many implementers, and presumably all open source software developers, need terms more concrete than "reasonable" and more appropriate to the Open Source Initiative software licensing model.
Furthermore, even "royalty-free" licensing is not of itself adequate for (most) open source implementation environments if the patent license, to be granted upon request, contains terms incompatible with open source (development, licensing, distribution) models. For example, an OASIS Intellectual Property Rights (IPR) Policy of 2005-04-15, applicable to some OASIS Technical Committees, provides IPR Modes for "Royalty-Free (RF) on RAND Terms" and "RF on Limited Terms." Both IPR Modes provide that an Obligated Party (patent owner) may require negotiation of an explicit executable license, with non-sublicensable patent license terms, and the license "may include reasonable,
customary terms relating to operation or maintenance of the license relationship." Such license terms may or may not be acceptable to open source software developers.
Thus: whereas earlier IPR statements from RSA Security Inc., HP, Sun, and Nokia used language such as [we will grant] "royalty-free licenses on a non-discriminatory basis...", the non-assertion covenant removes the necessity of an explicit (executed) license in the traditional sense. The non-assertion covenant is a public, blanket declaration asserting the freedom of anyone to implement the SAML 2.0 specification without needing to transact paperwork or otherwise to ask for Sun's permission.
Sun Microsystems irrevocably covenants that, subject solely to the reciprocity requirement described below, it will not seek to enforce any of its enforceable U.S. or foreign patents against that portion of a product that implements the Security Assertion Markup Language (SAML) V2.0 specification or any subsequent version of that specification in whose development Sun participates to the point where Sun would be obligated by the rules of OASIS to grant (or commit to grant) patent licenses or make equivalent non-assertion covenants ("SAML Implementation").
The foregoing covenant shall not apply and Sun makes no assurance, covenant or commitment not to assert or enforce any or all of its patent rights against any individual, corporation or other entity that asserts, threatens or seeks at any time to enforce its own or another party's U.S. or foreign patents or patent rights against any SAML Implementation.
This statement is not an assurance either (i) that any of Sun's issued patents cover a SAML Implementation or are enforceable, or (ii) that a SAML Implementation would not infringe patents or other intellectual property rights of any third party.
No other rights except those expressly stated in this Non-Assertion Covenant shall be deemed granted, waived, or received by implication, or estoppel, or otherwise. Similarly, nothing in this statement is intended to relieve Sun of its obligations, if any, under the applicable rules of OASIS. [posted as submitted by Sun Microsystems, 15 June 2006]
"A promise to you, dear developers." By Eve Maler. Blog 'Pushing String'. June 15, 2006. "Sun today issued two 'non-assertion covenants', one on the SAML V2.0 standard and one on the Web SSO Interop specs we published jointly with Microsoft last year. I had the pleasure of announcing this in a Burton Catalyst user-centric identity panel a couple of hours ago... You can find some definitions and context at Sun's On the Record blog, but the short version is: Developers using these specs need not fear Sun patent attorneys breathing down their necks to squeeze royalties or anything else out of them. No web forms to fill out, no baying at the moon on Thursdays, nothing. This is fairly similar to RSA Security's statement made in April . I notice that another statement is now appearing on the SAML group's IPR page: a non-assertion covenant from Fidelity. Wonderful news! And definitely a trend I'd like to encourage..."
"Rest assured, identity developers..." From On The Record: The Official Site for Breaking News and the Latest Information from Sun. June 15, 2006. "... Likewise, for Web Single Sign-On Metadata Exchange Protocol and Web Single Sign-On Interoperability Profile, Sun's non-assertion covenant means developers of Web SSO Interop technology can be assured that Sun will not impose on them any licensing terms, conditions or fees for the use of any patents held by Sun related to the Web SSO Interop specs. The Web SSO specs were jointly authored and published in draft form by Sun and Microsoft... Both authoring companies of these specs have already offered royalty-free terms on patent licensing, but Sun is simply choosing to be more concrete and to help remove development barriers by offering the non-assertion promise explained above. We want to provide as many assurances we can to developers implementing Web SSO Interop technology — again particularly for open-source developers..."
"The Spread of the Non-Assertion Covenant." By Andy Updegrove. Consortium Standards Bulletin Blog. June 15, 2006. "...A 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. 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... 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... 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..."
The declarations of patent non-enforcement (non-assertion) attested for the OASIS SAML specifications represent a growing trend whereby technology vendors are seeking to facilitate standards adoption by eliminating the detrimental effects of patents. Two examples are referenced here, including an additional Non-Assertion Covenant (by Sun) relative to the two Web SSO specifications, developed jointly with Microsoft. A related example is the recently approved UN/CEFACT IPR Policy, which drew inspiration from W3C's pioneering work that led to the creation of the W3C 'Royalty Free' Patent Policy — the goal of which is to assure that "Recommendations produced under this policy can be implemented on a Royalty-Free (RF) basis."
According to documents prepared for the UN/CEFACT Twelfth Session, the UN Office of Legal Affairs (UN OLA) approved an IPR Policy which governs specification development in UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business). This May 2006 policy requires "all Participants in a UN/CEFACT Forum Group to waive their rights to enforce any of their intellectual property ('IPR') that would be necessary to implement or use a Specification developed in [a] Forum Group ('Essential IPR')." Though the UN/CEFACT framework differs from the "Non-Assertion Covenant" as an instrument, some of the beneficial effects — e.g., use of waiver to eliminate patent licenses — are similar. The UN/CEFACT waiver "is automatic if the Participant does not disclose the IPR, and is required as a condition of participating in the UN/CEFACT open development process." See the complete text and commentary for details on the five key principles: Waiver, Disclosure, Exception Handling, Warranty, Disclaimer.
- On The Record: Rest Assured
- Sun Web SSO Interop Non-Assertion Covenant
- OASIS SSTC IPR Statements
- Security Services TC:
- Earlier news:
- UN/CEFACT IPR Policy Documents from the UN/CEFACT Twelfth Session (22-24 May 2006, Salle XI, Palais des Nations, Geneva), Agenda Item 12: Organizational Matters:
- UN/CEFACT Open Development Process (TRADE/R.650/Rev.4/Add.1). 17 May 2006. 13 pages. "The UN/CEFACT Open Development Process is open for anyone to provide comments at certain stages in the process. The resulting Standards and Recommendations must be open as well. That means: free of any constraints or restrictions associated with intellectual property rights (IPR)... Anyone should be able to produce a complete implementation of the specifications described by the UN/CEFACT Standards or advocated by the UN Recommendations without IPR related cost or red tape..." [cache]
- Executive Summary of the UN/CEFACT Intellectual Property Rights Policy (ECE/TRADE/CEFACT/2006/11/Add.1). 17 May 2006. Twelfth session, Geneva, 22-24 May 2006. 3 pages. "The UN/CEFACT IPR Policy ('Policy') is designed to promote the goal of enabling the implementation of UN/CEFACT Specifications without the burden of fees or restrictions. The Policy promotes this goal by requiring all Participants in a UN/CEFACT Forum Group to waive their rights to enforce any of their intellectual property ('IPR') that would be necessary to implement or use a Specification developed in that Forum Group ('Essential IPR')..." [cache]
- UN/CEFACT Intellectual Property Rights Policy (ECE/TRADE/CEFACT/2006/11). 17 May 2006. With presentation by the UN/CEFACT Bureau. "Subject to Section 3(b), as a condition of participating in UN/CEFACT, each Participant agrees to waive its rights to enforce its Essential IPR against any party implementing a Specification from any Forum Group of which Participant was a member or made a Contribution. The Participant's waiver of its rights to enforce Essential IPR against any party implementing the Specification extends only to the actual implementation of the Specification..." [cache IPR Policy, cache Presentation]
|Receive daily news updates from Managing Editor, Robin Cover.|