Re: RFC3979bis section 7 -- hierarchy of preference for licensing

[Stephan Wenger <[e-mail]>]

Hi Kim,
Long time…
Please see inline.
Stephan

From: <Turner>, Kimberly A <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 15 August, 2013 11:30
To: "David Rudin (LCA)" <[e-mail]<mailto:[e-mail]>>, Stephan Wenger <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: RFC3979bis section 7 -- hierarchy of preference for licensing

I also agree with David on the issues are the use of the statement “[w]ith respect to technologies with IPR claim(s) against them, the IETF prefers open-source-friendly non-assert terms over reasonable and non-discriminatory royalty-free terms (RAND-Z)”.  I don’t agree that this is clear enough to even understand what is truly meant and, as David points out, leaves open the opportunity for many questions and interpretations.

StW: Intentionally so, as explained before (in my initial email).  Tightening this up would be a nightmare, and remember: the IETF does allow free-form declarations of licensing terms, and the use of free-form is the norm.

I also agree that having this hierarchy will lead to quite a bit of difficulty within the work groups because we have no idea how or when or who will decide when to invoke the hierarchy.

StW: You are aware that we have such a hierarchy already, since at least 2004 (RFC 3668, and RFC 3979, Section 8)?  All I did was adding the non-assert, and a bit of tightening up the language.  I have closely followed the IETF's IPR developments between 2004 and now, and I do not recall any issues that have come up with respect to this.

Also, it will make it difficult for the IETF to liaise with or submit specs to organizations like the W3C and other international bodies who rely on RAND terms as the non assert can cause confusion in various jurisdictions.

StW: I disagree.  I assume the issue with "liaising" is related to normative referencing and things like Rec. A.5 in the ITU, and corresponding policy restrictions in other SDOs.  With respect to that: A majority of IETF disclosures, today, are non-assert statements.  IETF RFCs with disclosed patents under non-assert terms are routinely normatively referenced by bodies such the ITU, 3GPP (ETSI), and others.

Kim Turner

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of David Rudin (LCA)
Sent: Tuesday, August 13, 2013 10:04 PM
To: Stephan Wenger; [e-mail]<mailto:[e-mail]>
Subject: RE: RFC3979bis section 7 -- hierarchy of preference for licensing

Hi Stephan,

I think there are a lot of issues in this statement “[w]ith respect to technologies with IPR claim(s) against them, the IETF prefers open-source-friendly non-assert terms over reasonable and non-discriminatory royalty-free terms (RAND-Z)” that need to be considered.

One issue is the notion that non-asserts are preferred over RANDz.  A royalty-free non-assert and RANDz licensing commitment are very different things.  While a RANDz commitment generally doesn’t include specific terms, it does mean that an implementer will be able to get a reasonable and non-discriminatory license, and those terms can be negotiated by the parties (though in reality actual RANDz licenses tend to be extremely rare).  We also have an increasing amount of case law to tell us what kind of terms are reasonable and non-discriminatory.

Unlike a RANDz commitment, which can be negotiated, non-asserts tend to be take it or leave it affairs.  If you don’t like the terms, there are no assurances that you can get different ones.  And that leads directly to the non-assert terms themselves.  I’ve certainly seen non-asserts that are solid, but I’ve also seen a number that can be extremely problematic to implementers.  With a take it or leave it non-assert, an implementer can be held up by patent holder providing unacceptable terms.

For just one example, non-asserts can include extremely broad grant back provisions that effectively require an implementer not to assert any of its patents, even for those that read on things that have nothing do to with the covered RFC, in exchange for a patent grant for a single RFC.  There are certainly good arguments that broad grant back provisions are not RANDz terms, and providing a preference to non-RANDz terms just because they’re in the form of a non-assert is not going to help adoption.

Requiring compatibility with OSS licenses also doesn’t help much since it’s not at all clear what that means.  Is it ok if the non-assert is compatible with BSD but not Apache?  What about if it’s compatible with Apache and not GPL? (Even Apache is not considered to be compatible with GPLv2.)

It’s probably also worth considering whether the non-asserts themselves would be compatible with each other.  I’ve seen a number of non-asserts at IETF that are conditioned on the recipient  making their patents available under the same terms, yet most IETF declarants providing non-asserts use their own custom terms.  If you have two non-asserts each requiring recipients provide the same terms, whose terms trump?  Or, does it result in a cascading effect where everyone needs to provide multiple terms to satisfy the conditions of the various non-asserts for a given RFC?

Like any other legal agreement, with non-asserts the devil is in the details.  Expressing a preference for non-asserts that may include problematic terms is just as likely to hurt adoption as it is to help.

At least speaking for one implementer, a RANDz commitment provides a much greater level of comfort compared to the situation posed by various incompatible and potentially onerous non-asserts.

David



From:[e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Stephan Wenger
Sent: Tuesday, August 13, 2013 9:19 AM
To: [e-mail]<mailto:[e-mail]>
Subject: RFC3979bis section 7 -- hierarchy of preference for licensing

Hi all,

In Berlin's IPR BOF, one of the topics discussed was language in section 7.  I had specific comments, and was asked to provide input on the list.  In the process of composing my input, I noted that a section 7 has a number of issues that could benefit from clarifications or modifications that go beyond editorial input.  I had some private discussions with Scott and Jorge, and was asked by them to provide input on a few major (non-editorial) topics the list.  This is the first of a series of emails all concerning this section.

To set context, section 7 is arguably one of the more important sections in the RFC3979, because it covers the application of the IETF IPR policy in the day-to-day operations of the IETF.  The title of the section is "Evaluating Alternative Technologies in IETF Working Groups".  It explains, among other things, how working groups can react to received IPR disclosures.  (Note that RFC3979 covers only WGs, and not other IETF bodies, such as the IESG or individuals ADs or whatever-none of these are currently mentioned-but I believe that Jorge and Scott will fix that bug in the next revision).

This post is about the first sentence of RFC 3979, which reads:

In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing.

I propose to replace this sentence with:

In general, to solve a given problem, the IETF prefers technologies with no known IPR over technologies with IPR claim(s) against them.  With respect to technologies with IPR claim(s) against them, the IETF prefers open-source-friendly non-assert terms over reasonable and non-discriminatory royalty-free terms (RAND-Z), over technologies offered under reasonable and non-discriminatory terms but possibly incurring royalties (RAND), over technologies with IPR against them where the terms are non-RAND or, in the worst case, where the IPR is declared as being not licensable.

I believe that the above change reflects reality in the IETF at large as of 2013, and obviously only to the point I have insight.  I believe that the RFC3979 text does not reflect reality as of 2013.

The perhaps most important change is to acknowledge the existence of a (free and) open source ecosystem which, in at least some cases, has difficulties in accepting technologies for which bi-lateral licenses need to be signed, regardless of whether those licenses are royalty-free or not or whether unlicensed use of the technology generally is tolerated even if it were against the text of the disclosure. Let me also note that we have (moderately) recent examples of IETF RFCs with IPR claims that cover all categories mentioned above, including the final one.

The list of categories could easily be extended, especially with respect to the broad "open-source friendly non-assert" part.  However, doing so meaningfully would quite likely require references to licensing schemes supported by certain open source "camps", and I do not believe that the IETF needs to go down to that granularity, nor could I stand the flame wars that would likely break out.  So I tried to keep it simple by saying that there is something "better" from an adoption viewpoint than RANDZ, but "worse" than IPR-claim-free, without going into details.

I also stayed away from defining "RAND".  I mentioned RAND a because the vast majority of IETF disclosures mention RAND for reasons that are known to the disclosers, the requirement for reasonable and non-discriminatory licensing is commonly believe to offer some protection, even if the amount of protection offered is currently unclear, and because RAND is a requirement for normative down referencing to many other SDOs.  I do not believe that the cumulative expertise of this list has the expertise--let alone the authority--to define the term RAND.

Thanks for your consideration of my proposal.

Stephan