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