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

[tsg <[e-mail]>]

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:*[e-mail] [mailto:[e-mail]] *On 
> Behalf Of *David Rudin (LCA)
> *Sent:* Tuesday, August 13, 2013 10:04 PM
> *To:* Stephan Wenger; [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
>
>
>
> _______________________________________________
> Ipr-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipr-wg


-- 
// Standard "perasonal email" disclaimers apply