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

["David Rudin (LCA)" <[e-mail]>]

Thanks Stephan,

I've included my responses inline.

Best,

David

From: Stephan Wenger [mailto:[e-mail]]
Sent: Thursday, August 15, 2013 7:01 AM
To: David Rudin (LCA); [e-mail]
Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing

Hi David,
Please see inline.
Stephan

From: "David Rudin (LCA)" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 13 August, 2013 22:03
To: 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

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.

StW: I concur with most of what you say above, including the underlying sentiment that a signed and sealed RAND-Z license is preferable to many implementers (though not necessarily all the open source folks).  However, nothing what you write above changes that, at least based on my impression, the IETF as an organization indeed prefers non-assert statements, even with broad grant back provisions and other unpalatable terms, over RAND-Z licensing covenants.  As the very minimum, the overwhelming majority of participants, and the IETF is a consensus based organization, right?  The reason for my proposed modification lies in the alignment of the policy to the practice of the IETF as of today.  Let me also note that practically all non-assert disclosures include an offer for negotiation of a bilateral (typically RAND) license, for reasons I certainly do not need to explain to you :-)  That ought to alleviate some of your concerns.

DR:  You're correct than many non-asserts made at IETF include an offer to negotiate a RAND license in place of a non-assert, but it's by no means universal.  Even those that do, however, generally provide a royalty-free non-assert plus the option to negotiate a royalty-bearing RAND license.  In other words, in those non-asserts the free option is still a take it or leave it affair, but if you're not comfortable with the non-assert, you'll need to pay.  It's not at all clear to me why a non-assert with, for example, broad reciprocity with the option to pay if you want better terms would be preferable to a RAND-z commitment that says implementers will be able to get a royalty-free license.  In the case of a non-assert with a RAND option, it's hard to say that's a royalty-free grant, or that it's a grant that better than a RANDz commitment.

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.)

StW: I disagree with your first sentence. It helps, even if it is not clearly defined.  As I have already stated, it is up to the implementer community of an RFC--however that community may be composed--to beat up a non-assert disclosure that it considers incompatible with their business model.

DR:  While I still don't see it helps given the variety of OSS licenses that are available or could be drafted, perhaps a larger issue is why IETF would provide preferential treatment to one licensing model over others?  I am not aware of any other standards setting organization that does so, and I believe there are very good reasons for SSOs to operate in a non-discriminatory manner.

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?

StW: Once more, the preferences stated are what I believe (and others have concurred!) the current practice of the IETF at large.  The problem you mention may well exist in theory, but I have not seen an outcry--or even a civilized discussion--about a problem like the one you mention that has occurred in practice.

DR:  I actually am aware of at least one IETF group that has tried to encourage uniform licensing statements in an effort to avoid issues presented by multiple and potentially conflicting licensing statements.  That said, I think the problems presented around RAND-z commitments tend to be largely theoretical in practice, and the standards world has much more time and experience with RANDz commitments that we do with non-asserts.   I see no lack of implementation of RANDz standards in practice.  It's also exceedingly rare for implementers to seek a RANDz license and for patent holders to try to enter into RANDz licenses with implementers (or litigate over them).  Providing a preference to non-asserts over RANDz over the theoretical issues around RANDz appears to replace a proven approach that has worked extremely well with an alternative non-assert based approach that presents a new set of issues.

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.

StW: On a personal level, I prefer a signed bilateral or pool license any day over an uni-lateral non-assert statement, especially with broad reciprocity conditions or other unpalatable terms.  I'm even willing to pay for it.  Makes me sleep better, and my business model allows for it.  I'm not so sure, however, that a disclosure offering a RAND-Z license with undisclosed terms (minus the -Z, of course) makes me sleep better as well.  With a non-assert, at least I know the conditions beforehand, and can cope with them, or negotiate a license, or whatever...  With the type of RAND-Z offers the check-box system of the disclosure tool allows, I would actually have to negotiate a license before I know the conditions, which is not only an expensive and lengthily undertaking (at least in misty cases), but also incompatible with some open source business models.

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