Hi Pete.
I concur that there was no WG. Sorry for implying that there was one. I
should have written BOF consensus or something like that.
As for the substance, please see inline.
Stephan
On 4/29/16, 12:58, "Pete Resnick" <presnick(_at_)qti(_dot_)qualcomm(_dot_)com>
wrote:
On 25 Apr 2016, at 16:31, Stephan Wenger wrote:
On 4/25/16, 13:15, "ietf on behalf of Jari Arkko"
<ietf-bounces(_at_)ietf(_dot_)org on behalf of
jari(_dot_)arkko(_at_)piuha(_dot_)net> wrote:
- Section 5.5(C): Two things:
[...]
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
The object of the "subsequent" wasn't clear, so this just spells it
out. Wordy, but more precise.
Right
I’m not sure I agree that the object of “subsequent wasn’t clear
from context. However, I don’t mind to see that fixed if others
feel so. However, the fix as proposed sets a very low standard
(reasonable efforts) for ensuring that subsequent transferees are
bound. That a substantial change from the WG consensus, and IMO in the
wrong direction.
Let's be clear that there was no "WG consensus" on this, since there was
no WG. But let's assume that the consensus of the BoF was for something
strong.
I disagree that "use reasonable efforts to ensure" is such a low
standard, and the stronger language you propose concerns me:
What we want to achieve is that if A assigns a patent to B, B and all
further transferees (B to C, C to D, etc. etc.) are similarly bound.
We want to make sure if any of these entities doesn’t feel bound for
whatever reason, the patent is held unenforcible by a well-informed
court. It’s clear that this is much more onerous to the
rightholder, and may well lower the value of the IPR.
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.
For the information of the broader community here: the subject of licensing
commitments traveling with patents is currently a hot topic in several IPR
working groups of a number of SDOs. Pete’s employer has a fairly strong
position on that matter, and so have I (and a bunch of other folks). I
wouldn’t call this a proxy discussion here--the IETF’s policy is too important
for that--but I’m not surprised that it comes up prominently now. However, I
do believe that the IETF’s patent policy practice has two unique features, lack
of RAND licensing requirement based on membership or participation and the
common use of non-assert covenants, that make a clean solution here even more
important than in, say, the ITU.
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).
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, 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.
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.
- Section 7, paragraph 6:
This is IMO a much less critical point then the one above, and in fact I was
mainly asking a question (of an IETF security consensus as of 2005) rather than
pushing a point. Still, as you are arguing substance rather than provide
historic context, please see below for my own arguments.
The only change in this paragraph from 3979 was to add the word
"all" in the second-to-last sentence. My lawyer friends tell me that
this little change is opening a can of worms, having to do with
licensing to makers of parts instead of implementers of the whole
specification. I don't think we meant to change the meaning from the
3979 meaning, and I certainly don't think that we meant to change
some implication about whether folks in general needed to license to
people that make parts where they wouldn't have before. Was there
something unclear about that sentence that needed the word "all"
added to it? We aren't making a substantive change, are we? Can we
just strike it? It seemed pretty clear to me before.
Agree
I’m not sure here.
For context, the paragraph is in section 7 of RFC3979bis (which used
to be the second paragraph of section 8 of RFC3979). The sentence in
question describes an purported IETF consensus established in
pre-RFC3979 times, as follows (the critical and new “ALL” is
capitalized):
“
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, and which Pete’s
lawyer-friends probably would like to preserve. However, generally
speaking, removing loopholes like this is a Good Thing, unless the
consensus at the time was such that there ought to be a loophole. I
did not follow the consensus process in sufficient detail to have an
opinion, but perhaps security and IPR conscious folks in the IETF
remember?
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. You yourself made that point, by saying that
there actually IS a difference between presence and absence of the “ALL". I
got alarmed by your statement. 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.
Calling it a "loophole"
implies that somehow the IETF intention was to disallow something that
the current text allows. What is that something that you think we ought
to be removing?
See above.
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.
Stephan
So, why are we adding "all"? What loophole are we trying to close? If
there is none, let's strike "all" and use the original text.
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478