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@xxxxxxxxxxxxxxxx> 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@xxxxxxxx on behalf of jari.arkko@xxxxxxxxx> 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