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

From: Stephan Wenger <[email-masked]>
Date: Tue, 13 Aug 2013 16:19:27 +0000

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 13 Aug 2013 18:38:27 +0200

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

Oh, my.  Only a lawyer could love that.  I find it entirely
incomprehensible.  Over, over, over.  Over.

Are you really trying to set up a hierarchy, wherein option A is
preferred over B, and B is preferred over C, and so on?  Then why not
set it up that way, as a list?  How's this?:

-------------
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
considers the following list of terms to be in decreasing order of
preference:

1. open-source-friendly non-assert terms
2. reasonable and non-discriminatory royalty-free terms (RAND-Z)
3. technologies offered under reasonable and non-discriminatory terms
but possibly incurring royalties (RAND)
4. technologies with IPR against them where the terms are non-RAND
5. the worst case, where the IPR is declared as being not licensable
-------------

Barry

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 13 Aug 2013 17:05:26 +0000

Barry,
Your formulation is certainly more accessible.  I'm fine with it.
Stephan

On 8.13.2013 18:38 , "Barry Leiba" <[email-masked]> wrote:

>>with no

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 13 Aug 2013 11:23:29 -0600

> Your formulation is certainly more accessible.  I'm fine with it.

Agreed.

Formatting aside, is that hierarchy of options complete and accurate? It
looks fine to me and consistent with our "running code" in these
matters. I wonder: do we need to specify a bit more what we mean by
"open-source-friendly non-assert terms"?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Aug 2013 21:02:25 +0100

> "open-source-friendly non-assert terms"?

Overall this is a good change IMO, thanks Stephan.
I prefer Barry's formulation.

I think we should ask some folks who care a lot about OSS, IPR and
licensing to see what they think at some point since it'd be a real
shame to make this change but then discover that some important OSS
group find it objectionable. (I do however agree with Stephan's
approach of not going into too much detail in case we accidentally
prefer one OSS camp over another.)

One other comment, I'd add a 2.5 to Barry's list:

- 2.5. same-as-2 but with mutually assured destruction (MAD).

Someone would have to figure out how to phrase that but there're
plenty of examples (e.g. most or all Cisco declarations) where
you lose the right to an RF license if you sue the IPR declarer
over your claimed IPR.

S.

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 13 Aug 2013 21:03:17 +0000

Steve,
Please see inline.
Stephan

>prefer one OSS camp over another.)

Feel free :-)

(Let me note that I ran my idea, before posting, against two colleagues
who have some experience in the field, but prefer not to be named.
Neither of them had a concern.)

>you lose the right to an RF license if you sue the IPR declarer

MAD sounds scary.  But a patent lawsuit hardly falls under the category of
"destruction".  Even small companies get occasionally sued over patents,
without going down.  Big ones get sued every other week or so.  It's not
the end of the world.  Moderately scary sometimes, and surely annoying,
but not necessarily (not even frequently, in my personal experience)
destructive.

2.5 would be called something like "open-source friendly non-assert terms
with reciprocity condition."

I have yet to see a non-assert covenant anywhere (inside or outside the
IETF) that does not include a reciprocity clause (termination of promise
not to sue in case of litigation or, in some cases, assertion of a patent
against the rightholder, or his friends, or his customers, or another user
of the standard, ...).  AFAIR, all IETF disclosures with non-assert terms
would fall under 2.5 according to your definition.  And, while we are at
it, I have yet to see a license agreement under RAND or RAND-Z that does
not include reciprocity conditions.  Therefore, let me suggest it would be
an unnecessary add of word count and confusion if we were adding 2.5 (and
corresponding 3.5, 4.5, etc.).

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Aug 2013 09:07:24 +1200

> - 2.5. same-as-2 but with mutually assured destruction (MAD).

There are good reasons why we never tried to define RAND in an RFC.
(Basically WANL and WADNJ, we are not lawyers and we are *definitely*
not judges.) The same reasons mean that we shouldn't try to define
any of these terms precisely in an RFC. "Open-source friendly"???
Of course that is way out of our competence to define.

So, while expressing some preferences (and mine might well agree
with the proposed list), we have to be extremely clear that we
are not laying down rules and that the only criterion in the end
is WG rough consensus to adopt or not adopt a particular technology.
In fact I wonder about putting this in a BCP rather than in RFC3669bis.

    Brian

> _______________________________________________
> Ipr-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipr-wg
>

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 13 Aug 2013 21:12:57 +0000

Hi Peter,

On 8.13.2013 10:23 , "Peter Saint-Andre" <[email-masked]> wrote:

>matters. 

That's what I aimed for.  Not being creative, but simply reflecting what
has been going on for years.

>I wonder: do we need to specify a bit more what we mean by

In my original email I recommended against an attempt to be more specific
in defining RAND.  The same thought applies here.

The term "non-assert term", in the context of Section 7, is, I believe,
well understood and does not need further explanation or description.

What is "open-source friendly" is not up to the IETF to decide.  It is to
be decided by the open source communities, each of which may well have
their own criteria and may well arrive at different conclusions for the
same disclosure text.  And whether they are right or wrong in their
assessment is ultimately to be decided the courts.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Aug 2013 22:28:00 +0100

Hiya,

> Neither of them had a concern.)

Good to hear. I'm sure it'd happen as part of IETF LC anyway,
but sooner is better.

> MAD sounds scary.  

Sorry, its a slang-term I've heard used for these. Not sure
how widely its used.

> But a patent lawsuit hardly falls under the category of

I do think I've seen declarations without reciprocity, though yes
they're perhaps getting very scarce these days.

Nonetheless reciprocity is problematic for some OSS folks I believe.
I think the issue was if a user of the OSS s/w sues the IPR holder
then was it ok for the developer to write that OSS in the first
place? (I might have gotten that wrong though.)

However, I don't really mind too much about this part - the main good
thing here IMO is reflecting the reality that we do prefer our work
to be usable in OSS (for those things where that makes sense, which
is most things).

S.

---

From: "David Rudin (LCA)" <[email-masked]>
Date: Wed, 14 Aug 2013 05:03:43 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Stephan Wenger
Sent: Tuesday, August 13, 2013 9:19 AM
To: [email-masked]
Subject: RFC3979bis section 7 -- hierarchy of preference for licensing

Hi all,

Stephan

---

From: Ted Hardie <[email-masked]>
Date: Wed, 14 Aug 2013 08:48:07 -0700

So, I've read the thread to this point, and as I watched I got more and
more niggled with the feeling that it was heading in the wrong direction.

As I thought about why, I realized that the whole of hierarchy of
preference discussion is disconnected from what a WG does:  make
tradeoffs.   A working group faced with technology A with license FOO and
technology B with license BAR is almost never going to pick solely on
license; it's a balance of the benefits of the technology and the
consequences of the license.  Creating a hierarchy of preference for
license terms has a sort of theoretical advantage in that it tells people
who are considering what licenses the IETF likes.  Those people probably
have lawyers with other things to think about it, so I suspect it of being
pretty theoretical, but harmless.

This section, though, does not seem to me good enoughfi  we are going to
state a preference hierarchy.:

   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.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.

I think we need language that says explicitly that the working group makes
the trade-off between the technology's advantages and the license's
conditions.  Otherwise, I foresee WGs with people arguing that technology B
must be chosen because its license is higher in the hierarchy and
acceptable (for some value of acceptable).

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 15 Aug 2013 14:13:42 +0000

Hi Ted,
I very much agree that the any hierarchy of licensing schemes MUST NOT be the only, or even the key criteria in evaluating competing technologies.  The balance between technical merits and commercial impact, as seen by the individual participant, is all that really counts.  With that in mind, please note that there is a lot more in the existing section 7 than just this first sentence.  Much of it is directly related to your concern.  In particular, right after the sentence I try to improve on, follows:
"
But IETF working groups have the discretion
to adopt technology with a commitment of fair and non-discriminatory
terms, or even with no licensing commitment, if they feel that this
technology is superior enough to alternatives with fewer IPR claims
or free licensing to outweigh the potential cost of the licenses.
"
Isn't that already addressing your concern?
Should we change the order of the parts of the section, such that the above citation (or something similar) appears prominently at the begin of section 7?

Stephan

From: Ted Hardie <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 14 August, 2013 08:48
To: Stephan Wenger <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing

So, I've read the thread to this point, and as I watched I got more and more niggled with the feeling that it was heading in the wrong direction.

As I thought about why, I realized that the whole of hierarchy of preference discussion is disconnected from what a WG does:  make tradeoffs.   A working group faced with technology A with license FOO and technology B with license BAR is almost never going to pick solely on license; it's a balance of the benefits of the technology and the consequences of the license.  Creating a hierarchy of preference for license terms has a sort of theoretical advantage in that it tells people who are considering what licenses the IETF likes.  Those people probably have lawyers with other things to think about it, so I suspect it of being pretty theoretical, but harmless.

This section, though, does not seem to me good enoughfi  we are going to state a preference hierarchy.:

I think we need language that says explicitly that the working group makes the trade-off between the technology's advantages and the license's conditions.  Otherwise, I foresee WGs with people arguing that technology B must be chosen because its license is higher in the hierarchy and acceptable (for some value of acceptable).

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 15 Aug 2013 14:01:03 +0000

Hi David,
Please see inline.
Stephan

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

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.

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.

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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Stephan Wenger
Sent: Tuesday, August 13, 2013 9:19 AM
To: [email-masked]<mailto:[email-masked]>
Subject: RFC3979bis section 7 -- hierarchy of preference for licensing

Hi all,

Stephan

---

From: Michael Cameron <[email-masked]>
Date: Thu, 15 Aug 2013 14:20:53 +0000

Ted is correct--the WG should be focused on adopting the best technology for the problem at hand, with the IPR profiles of alternatives initially, at least, in the background.  If, during the discussion of technology alternatives, a holder of essential IPR declares they will not make the IPR related to one of them available under any circumstances, then the WG can switch to plan B.  But it is the WG that makes the trade-off between the technology's advantages and the license's conditions.  Otherwise, I also foresee WGs with people arguing that technology B must be chosen because its license is higher in the hierarchy.  Perhaps we can state that notwithstanding a IPR hierarchy, the technical advantages of a solution should be predominant in the WG.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Wednesday, August 14, 2013 10:48 AM
To: Stephan Wenger
Cc: [email-masked]
Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing

---

From: "Turner, Kimberly A" <[email-masked]>
Date: Thu, 15 Aug 2013 18:30:19 +0000

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

Kim Turner

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

Hi Stephan,

David

Hi all,

Stephan

---

From: tsg <[email-masked]>
Date: Thu, 15 Aug 2013 11:55:43 -0700

On 08/15/2013 11:30 AM, Turner, Kimberly A wrote:

So Kimberly - what does Intel at the Corporate IP Level think of this? 
Would these use controls meet their corporate requirements for the 
acquisition of IP under a veil of a license?

This is both a fair and reasonable question to ask here since it is they 
who are underwriting much of your effort here I would assume.

Todd Glassey
>
> 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.  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.  
> 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.
>
> Kim Turner
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *David Rudin (LCA)
> *Sent:* Tuesday, August 13, 2013 10:04 PM
> *To:* Stephan Wenger; [email-masked]
> *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 
> 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:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Stephan Wenger
> *Sent:* Tuesday, August 13, 2013 9:19 AM
> *To:* [email-masked] <mailto:[email-masked]>
> *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).
>
> royalty-free licensing.
> 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.
>

-- 
// Standard "perasonal email" disclaimers apply

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 15 Aug 2013 19:44:28 +0000

Hi Kim,
Long time…
Please see inline.
Stephan

From: <Turner>, Kimberly A <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 15 August, 2013 11:30
To: "David Rudin (LCA)" <[email-masked]<mailto:[email-masked]>>, Stephan Wenger <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of David Rudin (LCA)
Sent: Tuesday, August 13, 2013 10:04 PM
To: Stephan Wenger; [email-masked]<mailto:[email-masked]>
Subject: RE: RFC3979bis section 7 -- hierarchy of preference for licensing

Hi Stephan,

David

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

Hi all,

Stephan

---

From: Ted Hardie <[email-masked]>
Date: Thu, 15 Aug 2013 16:31:15 -0700

On Thu, Aug 15, 2013 at 7:13 AM, Stephan Wenger <[email-masked]> wrote:

>  In particular, right after the sentence I try to improve on, follows:
> "

I don't think it is adequate any more.  The old stuff basically said "We
want to get fair and non-discriminatory, and when we don't get it for a
superior technology, the working group could still choose the superior
technology".   Not quite a binary view of "yes,we got what we want" vs. "no
we didn't", but certainly not a full hierarchy either.

A working group choosing between technology A. (non-assert) and technology
B. (RAND-Z)  isn't really in the same place as one chosing between C
(non-assert) and F (rand-with-royalties).  It's making a very different
trade-off, and I think that should be made clear.  We should say that the
working group (not this hierarchical list) makes the trade-off; it may be
informed by this general list, but if it has even a moderate reason to
prefer B over A, that may be justifiable.

Put a very different way "superior enough" is pretty variable, and the
judge is the working group--let's make that clear.

> Should we change the order of the parts of the section, such that the
> above citation (or something similar) appears prominently at the begin of
> section 7?
>
>
I don't think the ordering is salient, here, personally, as by the time we
get to referring to this document, people better be reading the whole thing.

Ted

>  Stephan
>
>
>
>   From: Ted Hardie <[email-masked]>
> To: Stephan Wenger <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 15 Aug 2013 23:42:27 +0000

Hi Ted,
I see your points, and I concur.  If we were extending the hierarchy by adding non-assert, that sentence I quoted below has to be adjusted and most likely expanded on.  I have no problems in adding word count here as this is IMO one of the most important features of the IETF IPR policy and certainly one that is uncommon in major SDOs.   I should have mentioned this in my original mail.
Stephan

Date: Thursday, 15 August, 2013 16:31

On Thu, Aug 15, 2013 at 7:13 AM, Stephan Wenger <[email-masked]<mailto:[email-masked]>> wrote:

I don't think it is adequate any more.  The old stuff basically said "We want to get fair and non-discriminatory, and when we don't get it for a superior technology, the working group could still choose the superior technology".   Not quite a binary view of "yes,we got what we want" vs. "no we didn't", but certainly not a full hierarchy either.

A working group choosing between technology A. (non-assert) and technology B. (RAND-Z)  isn't really in the same place as one chosing between C (non-assert) and F (rand-with-royalties).  It's making a very different trade-off, and I think that should be made clear.  We should say that the working group (not this hierarchical list) makes the trade-off; it may be informed by this general list, but if it has even a moderate reason to prefer B over A, that may be justifiable.

Put a very different way "superior enough" is pretty variable, and the judge is the working group--let's make that clear.

I don't think the ordering is salient, here, personally, as by the time we get to referring to this document, people better be reading the whole thing.

Ted

Stephan

---

From: "David Rudin (LCA)" <[email-masked]>
Date: Fri, 16 Aug 2013 21:21:21 +0000

Thanks Stephan,

I've included my responses inline.

Best,

David

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

Hi David,
Please see inline.
Stephan

Hi Stephan,

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.

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.

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.

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

Hi all,

Stephan

---

From: Thomas Narten <[email-masked]>
Date: Mon, 19 Aug 2013 08:18:33 -0400

I wasn't able to attend the Berlin session. Can you please remind us
of what problem the suggested text is intended to fix? I.e., what is
broken that needs fixing?

If the intent is to just to make clear that Non-assert is more
friendly to open source, and thus a preferance over simple RF, that is
one thing, and I think is closer to where the IETF is today than the
current RFC text.

On the other hand, I'm less sure that spelling out a heirarchy is
something we should (or need to) do. For one thing, it's not a
straight hierarchy.  IPR disclosures tend to have pesky reciprocity
clauses, which mean that something like a specific RAND license may
well be viewed as better (by some folks) than something "above it" in
the heirarchy. It all depends on the specific clauses, which have to
be evaluated on a case-by-case basis and vary quite widely today.

Thomas