Re: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property

Stephen,

First some level-setting. You write below, "Pete's employer has a fairly 
strong position on that matter". That may well be. But let's be crystal 
clear that I am speaking for myself. Now, I have no illusions (nor 
should anyone else have any illusions) that I am not influenced by my 
employer's positions on any number of issues, but neither in technical 
nor policy discussions do I bring things to the table that I don't 
personally think are the correct thing to do for the IETF. I have 
disagreements with my employer from time to time on any number of 
topics, and I choose whether to disagree publicly or remain silent on 
those issues. In any case, I think whether or not my "employer has a 
fairly strong position on that matter" is absolutely irrelevant to the 
discussion and I'd insist that it not be a topic of conversation.
That said, on the issues themselves [trimming a bit as I go]:

On 29 Apr 2016, at 21:23, Stephan Wenger wrote:

> > > > > OLD
> > > > >      must ensure that such
> > > > >      commitments are binding on any subsequent transferee of the
> > > > >      relevant IPR.
> > > > > NEW
> > > > >      must ensure that such commitments are binding on a transferee
> > > > > of
> > > > >      the relevant IPR, and that such transferee will use 
> > > > > reasonable
> > > > >      efforts to ensure that such commitments are binding on a
> > > > >      subsequent transferee of the relevant IPR, and so on.
> > > > > END
On my original proposal above: I want to be clear that the language 
above says that for the first transfer from me to someone else, I 
absolutely must ensure that the commitments are binding on the 
transferee. The "use reasonable efforts to ensure" bit comes in at the 
second transfer: *I* must ensure that the second guy will use reasonable 
efforts to ensure that the commitments are binding on the next guy, and 
so-on.
> > > I would be fine if the NEW part would be reworded as follows:
> > > NEW
> > >       must ensure that such commitments are binding on a transferee 
> > > of
> > >       the relevant IPR, and also binding on any subsequent 
> > > transferees
> > > of the relevant IPR.
> > > END
> > This seems to require that if my IPR is transferred 20 times over 20
> > years, I am on the hook in perpetuity to absolutely make sure that 
> > the
> > next person down the line sticks to the agreement. I'm certainly 
> > willing
> > to make *reasonable* efforts to do so, and it will be up to a court 
> > to
> > determine if my efforts were reasonable, but I certainly don't want 
> > to
> > be forced to completely indemnify to 21st person down the line. "Use
> > reasonable efforts to ensure" seems reasonable. Otherwise, it's not
> > clear to me what I'm signing up to.
> My view is that certainty for the implementer that licensing 
> commitments made should trump freedom of business for patents.  I want 
> that a licensing commitment travels with the patent, just as a license 
> travels with the patent (the latter as a matter of law, almost 
> everywhere in the world and under almost all circumstances short of 
> bankruptcy).
Again, I'm fine with assuring that the license commitment travels with 
the patent on the first hop, and making sure that the next guy makes 
reasonable efforts to do the same. I just don't want to use 
extraordinary measures to enforce, under every jurisdiction worldwide, 
all transfers for the rest of time.
> If you are not willing to stand behind your commitment once made, and 
> enforce it yourself if violated by some guy downstream, then don’t 
> sell your patent.  Or, sell your patent but make sufficient allowances 
> to deal with the consequences of a sale to a misbehaving entity 
> downstream.
> Example: Assume A makes a non-assert covenant, and further assume that 
> an implementation infringes on the
> patent in question (meaning an implementer needs a license or a 
> reliance on a non-assert covenant).  Me, relying on this covenant, 
> implement the technology and never violate conditions in the 
> covenant--for example, I never sue A and thereby violate a reciprocity 
> condition of the covenant.  A later assigns to B, B assigns to troll C
And insert here, "and A has ensured that B will use reasonable efforts 
to ensure that C will honor the covenant"
> C sues me over a patent violation.  B and C may well not have a 
> disclosure obligation in the IETF.  The lawsuit would come out of the 
> blue to me.  That’s just wrong and exactly what the policy tries to 
> avoid.  If the non-assert would travel with the patent, of course I 
> could still get sued, but such a lawsuit would most likely have a 
> rather swift resolution in my favor.
IANAL, but I would think that with the inserted bit, such a lawsuit 
would equally have a rather swift resolution in your favor.
> With your language, once C sues me, as the very minimum I would have 
> to go through discovery of both assignments (there goes the first 
> million of many).  I may or may not win the lawsuit based on an 
> existing covenant or resulting implied license.  Once done, I can’t 
> even go after A for damages unless I could show A forgot to put some 
> “best effort” language in A's assignment paperwork.  That’s not 
> equitable, because A did profit from the assignment of the patent.
I don't see it. Leaving aside the "I can always get sued" argument, I 
don't see how the difference in language changes that much for you in 
this scenario.
> > > > > - Section 7, paragraph 6:
> > > An IETF consensus has developed that no mandatory-to-implement
> > > security technology can be specified in an IETF specification unless
> > > it has no known IPR claims against it or a royalty-free license is
> > > available to ALL implementers of the specification unless there is a
> > > very good reason to do so.
> > > “
> > Right, the only change between 3979 and the above is the addition of 
> > the
> > word "ALL" (not in all caps in 3979bis).
> >
> > > I agree that the tightened language removes an arguably unclear
> > > loophole that has been present in RFC3979...
> > Wait, what "arguably unclear loophole" do you think was there that
> > adding "all" in the above sentence tightens?
> The loophole is as follows: Arguably, without the ALL, there could be 
> some implementers of mandatory to implement security technologies that 
> are not covered by the RFC3979 language.
No, absolutely not. The current language is crystal clear that all 
implementers of MTI security technologies must get an RF license, or 
that there are no known claims. I want it to be perfectly clear that 
we've made no change in policy in this regard, and adding "all" sounds 
like something was different before. There's not anything different.
> You yourself made that point, by saying that there actually IS a 
> difference between presence and absence of the “ALL".
No, as I said in my earlier message, the difference is *not* as it 
pertains to this paragraph. Again, I think adding "all" makes no 
difference in this paragraph at all, which is why I thought it was 
reasonable to remove. The issue is that adding "all" might imply to some 
folks that the IETF *does* think there's a difference that applies to 
non-RF cases, that somehow the IETF thinks that it's gotten into the 
business of dictating particular licensing levels in cases not related 
to security protocols.
> I got alarmed by your statement.
I'm sorry to have alarmed you. I just want it to be clear that we've 
made no change in this policy regarding security protocols, and also 
that the IETF continues to take no position on other sorts of licenses.
> If you guys really think that the language gives enough wiggle-room 
> that, for example, a library/chip-IP house offering a cipher could 
> charge patent royalties for a mandatory to implement cypher technology 
> even if the final hardware or software product cannot, then I find 
> that alarming.  They shouldn’t be able to do so, because at least my 
> understanding of the IETF consensus here has been that they would 
> never, ever select a cipher as mandatory to implement unless that 
> cipher is free of patent royalties.
(a) Not "you guys"; just me (see top of message). (b) Not interested in 
any wiggle-room in this paragraph. Just assuring that we're not making a 
change in policy.
(And if we haven't, at this point, made enough of a record of the intent 
of the consensus on this point, I don't know how we could.)
> > I know that my lawyer friend was concerned not about security 
> > technology
> > per se, but the issue of licensing levels more generally. I'm pretty
> > sure we only wanted to talk about requiring royalty-free licensing 
> > for
> > security protocols specifically and never intended to require 
> > particular
> > kinds of licensing across the board. Either way, I think that the
> > original text was perfectly clear and had no loopholes.
> Again, the text above is ONLY related to mandatory to implement 
> security technology.  Nothing (but common sense and the law, including 
> antitrust law) prevents you guys to choose whatever language you 
> prefer in your free-form licensing declaration.
In which case sticking with the original text seems just fine.

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478