Last Modified: 2003-02-14
While the "Tao" of the IETF is still strongly oriented toward unencumbered technology, we can and do make use of technology that has various encumbrances. One of the goals of RFC2026 "The Internet Standards Process -- Revision 3" was to make it easier for the IETF to make use of encumbered technology when it made sense to do so.
The IETF IPR policy, as embedded in RFC 2026 section 10, has proven fairly successful. At the same time, a perceived lack of textual clarity on some issues have made necessary the publication of clarifications such as the "note well" statement issued in every registration package, the I-D boilerplate rules, and a huge number of discussions on specific IPR-related issues.
This working group is chartered with updating and clarifying section 10 of BCP 9, RFC 2026, which deals with intellectual property rights, including, but not necessarily limited to, patent rights and copyrights.
This working group will provide three documents:
o A BCP document, updating RFC 2026, which states the IETF IPR policy on rights relevant to the document publication process, such as copyright issues and trademark issues.
o A BCP document, updating RFC 2026, which states the IETF IPR policy on rights relevant to the use of IETF-standardized technology, such as patent-related claims
o An Informational document, which describes useful rules of thumb for working group chairs and working group members when working on IPR issues, as well as describing specific cases of IPR issues that have been successfully worked out in the IETF process, and providing references to specific examples of licensing statements and copyright provisions that have proved useful or worrisome. In other words, we plan to document the running code of our process.
The working group will attempt to work in three phases:
1. Document existing IPR practice in the IETF
2. Identify issues with current IPR practice that need to be addressed
3. Modify the documents produced in step 1 to reflect the outcome of the discussion of items identified in step 2.
If there consensus of the working group for a different IPR policy than the one described in RFC 2026, the working group will seek to amend its charter to make it clear that it is changing the status quo.
The working group will have a design team to assist with document drafting and review. As always, design team drafts have no special status, and are subject to amendment, ratification, and/or replacement by the working group.
|JUL 02||1st draft of updated IPR BCP document on documents - documenting existing practice|
|JUL 02||1st draft of updated IPR BCP document on technology - documenting existing practice|
|JUL 02||1st draft of IPR guidance document|
|AUG 02||2nd draft of updated IPR BCP document on documents|
|AUG 02||List of issues that need to be discussed while revising the documents|
|AUG 02||2nd draft of updated IPR BCP document on technology|
|SEP 02||2nd draft of IPR guidance document|
|SEP 02||IPR BCP document on documents sent to IETF Last Call|
|DEC 02||IPR BCP document on technology sent to IETF Last Call|
|JAN 03||IPR guidance document submitted to IESG for publication|
|JAN 03||Conclude WG.|
IPR ------ Steve Bellovin go over status of 3 docs a possible template for disclosure forms open mike to discuss rechartering at end of which, hum to see sense of room. Scott Bradner on updated documents. not significantly different (at least in text) as previous ID's. reflect comments received after IDs, so what's on screen wdiff submission rights/copyright document added text to clarify that these docs replace sec 10 of 2026 "go consult your own lawyer" made less chatty, more professional "internet standards process" changed to "ietf standards process" (consistency). 2026 says "internet", but "IETF" more clear "each named co-contributor" - everyone, not just stuckee added to boilerplate: not only copyright stuff, but patent stuff adhered to when submitting. that's the most substantive change. Q: does this mean that you have to disclose before submitting ID? A: See the other doc. says "as soon as practical afterwords. used to be deadlock. internet-drafts or internet drafts: style tons of nits fixed. Q (Valerie See): "reasonably known" to "personably and reasonably known" reworded for clarity, consistency, and into lawyerspeak keywords reasonably & personably known: if scott's is informational, then standards doc for q: valerie - like to see this guidance. clarifications for people ot understand. hate to lose from stds track doc q: harald: fine thing to have this defn, including example, in patents. odd for copyrights doc, though. [NOTE so can fix] wrapping error, id. that's it. modulo putting description back in for reasonably & personally nown. very strong sense of room (hum) that agreed doc is ready to go. - ---- IPR document. more changes. things reworded for clarity. however, not much new. changes from comments on mailing list. "legal advice" text turned more professional. any ref to int prop rights of 3rd parties, and responsibilities of submitters relative to 3rd party rights was removed. if I submit something, and has cisco ipr, and I don't know, I can't make any claims about it. even if I do know it's cisco IPR. "IP in IETF techology" wording on requirements is biggest open problem. what do we have to do to show that multiple impl exercising licenses as long as impl thought licensing req'd. (regardless of licensor) 2026 is ambiguous. 2 places. 1 - iesg will just look at multiple impl. if exist, then license must be ok. 2 - impl must have asserted that they have done whatever licensing feel is ncessary. never been tested. only one with IPR claims to draft standard. that was contested. impl. thought didn't need to do license; ipr claimant felt did need to do license, and sent in formal objection. q: do the people that claim they are doing licenses have to publish them? 2026 just said had to affirm. 2 parties collude, conspire to license under favorable terms but will not give to others. specifically thought about in 2026: balancing of risks. didn't want to get IETF into defining word fair or nondescriminatory. so mechanism chosen is multiple implementations. if so, someone must have impl & decided ok. but specificially doesn't deal with cross-licensing agreements; or co b is subsid of co a. at time, gain from not having to be involved in judging fair to finesse. good q if q colin james: still difficult to finesse. even with lots of work, doesn't stop lawsuits later q david black: possible to approach by id most egregious cases and say "don't count". e.g.: company & subsid doesn't count. john klensin suggested. think reasonable, but want some text. subsid, cross licencing the worst. q ted ts'o, ibm: as much as IETF doesn't want to define fair, I assume would less like validity. so having a claim form a basis for objection, then way to easy to manip std or running code to show that's the case [dos attack] q huitema: ... if egrigous cases, will show up in last call. so will be discussion that we can flag. if informed in public discussion then reasonable action taken. assumptions that fair can be challenged in last call from 2026. so relying on community to show if sham. emphasis that if impl doens't think ipr and ipr claimant does, then between impl & ipr holder not IESG. when IP statement appears in RFC, 50% of time rfc-editor stuck it in. this says RFC editor always sticks it in. don't bloat internet-drafts with verbage that is unnnecessary boilerplate always look in IPR directory, so rfc-editor doesn't have to have any knowledge. one other thing: didn't limit to stds-track docs per-se. must go into all stds track documents. if heard of claim, then rfc can stick into experimental or informational doc. not unusual for experimental to move to stds track. so don't limit disclosure to stds track. misleading for those doing experiements, acceptance in marketplace. question of how to make disclosure. firstname.lastname@example.org - historical. this says, go look on line to see how to do it now. could be email, form, form+email, ... added one add'l defin... comments obviously intended to not be contributions are not contributions. was in other docs, incl. note well. q: when say verbal, use oral. [AGREE] definition of contributors (since used in doc) will put explanation back in as harald pointed out. new defn for COVERs. q joe zbarth?: on contributors. thought was trying to reduce names on front of docuement. do they appear elsewehre? how relate to previous policy. add'l names is a new thing, from other stds document, indicating add'l support. not clear that name implied authorship/contribution. is requirement, in other docuement, that all major ocntributors must be known. this talks about named contributors....doesn't differentiate from front page, and acknowledgement section or contributors section. (overflow names in contributors section these days) christian : authors have to sign off before rfc publish. others do not. so there is a difference. don't know importance. yes, but as part of difference, large # of authors. pushed back. wg & authors told to reduce to X. Q, followup: common case for ack section, this work inspired by so-and-so, read book & paper. that's a very loose notion of contributed. welcome wording. q black: new defn of "covers" looks like it applies to "essential" claims vs "relevant" claims. is that your intention? george the lawyer: yes. we can clarify; the word covers a bit. when we say that something ; claim of patent would be infringed by this thing. that's essential: something that must be licensed. broader is harder. q bob win?: concerned about 'making' word. two senses. 1 creative act, 2. act of submitting. if everything that's expressed within forums covered here... what if co-authors are not parties to submission. is making submitting or is making authoring. if making is submitting, thne use that word. [scott brim note that]: changing q: concerned about proposal relevant to essential. from mailing list discussion & others... notion of essential, absolutely mandatory... is so loose. trying to judge essential from trying to work around... almost everything isn't that essential. can find way around. don't have to disclose if you can find a way around. goal should be disclosure of knowledge. this restricts what someone might aaron falk, rfc editor: process clarification. rfc editor adding ipr stmt to non-std rfcs'..;. intent to include individual sumissions? if claim in directory, then yes. notificatoin will come form IESG. brian carpenter: i think the relevant language leads us into territory where eveyrthing becomes ambuiguous again. essential claims & crankshafts: is well understood process to see if something reads on a patent or not - well understood in legal community. i have no idea what relevant means in this context. no idea if patents of which I am aware should be disclosed under relevance clause. don't thik this computes robert bart?: really addressing 6.6, covered used in awkward way. Whether someone is going to claim later that license is req'd.... that's the issue. work backwards from that & define in those terms. when get to 6.6 and use... relevant and essential are not issue. what's req'd is should say something early not late. in rambus could hide becuase at the time statement should have been made, claims didnot read on std as defined. if later on will tell people need license, disclose early. harald: i am not able to parse that sentence (cover vs covered) think word missing. other thing: we intend require disclosure on anything that covers any part of essential. sob says scott brim brought up whether disclosure needed for MAY functions, feel they do. q (grey thin): regarding relevant comment: enhancement vs necessary? is there a requirement that need to think of every way of implementing, which makes disclosure difficult. [[other side of same argument]] yep. this piece needs more work. 3rd party submissions vs. secretary? think so, but not issue. q: to follow up on discussion from earlier... 3 or 4 places where reference IPR disclosure. intent to focus on patent and application claims, or broad as in IPR definition? [[i was confused by response, but seemed to be patent & applications, not broader]] use indirect pointer or hard-code names here. q robert?: 6.2.2 if include "oral disclosure" then submit IPR statement... not sure that's what we want. suggest maybe "no later than" concept. intent that before incorporate suggestion from mike, wg knows if there is any IPR on it. q valerie: notion of call for IPR in last call? been removed, later. ted ts'o: how disclosure must be made... if active wg, then in addition to get to secretariate (or wherever) WG mailing list should be cc'd. is suggestion to do so. someone wanted it removed, haven't done so. q: when patent app is denied to inform IETF. "final rejection or abandoned" in text. q: worried about timing assumption. prior to pub of std/spec, that info should be provided to IETF. if denied, then patent holder isn't going to challenge, can we limit denial period to prior publication. don't think so. reason to include at all: so wg that decided to ignore encumbered technology can revisit. doc being published as RFCs are not end game. they get revised. q, followup: i agree with rationale. is valid. request is reasonable. but implementation of it may be difficult down road. agree, particularly if startup made claim. not sure how to address, send suggestion to list. joe zibarth: if read words, looks like negative disclosure. new disclosure when patent dentied. is it new disc, or withdrawl? talking about withdrawl. if have wording, send in. joe, followup: has words about encouraging disclosure. that's for 3rd parties. can't be required, might know under NDA. q robert bart: final rejection shouldn't be in there at all. is routine step in US. [used to be patent atty] is not ok to say "license everything with RAND" is ok to say will free license averything. approval: license as RFClk q: on 6.5, openly "RAND": is there something specified by "openly"? intent was to take all out. 6.6... robert: right now, as on paper, didn't work at all because cover defined in terms of claims. "and a license under any claims a patent or patent app would cover" parsing problem, incorporation by reference. what want to say there: disclosure is reqd when the person making the disclosure believes that a license may be reqd to practice standard. resend text to list? have to consider subjective intent. hate to do that, but rambus requires it. q valerie: why did the call come out? that's a change in process. these docs are to clarify existing process. not a violation of existing, but definitely not part of existing. ... 8-ish: need to have RAND or use in stds documeent [sorry, I don't understand] but no objections from floor. I'll ask for a this mostly ready modulo advancement stuff, are there new topics need to cover? steve: really want to get this document concluded. can't keep bringing up stuff, can wordsmith forever. have a feeling that's what we're doing. would like one more change. when get steady state, stop and don't reopen at next opportunity. will be new doc next week. but that means that new text to Scott B this week! - -=-=- IPR Guidelines for WG, scott brim. draft-ietf-ipr-wg-guidelines-02.txst since so many changes, almost a large rewrite: no diff on screen. shouldn't take long, not many issues. this is derivative. this depends on Bradner drafts. lots of clarifications, additions. but very few new ideas added to draft. 1. for first time put in explicitly an ordered list of licensing term preferences. 2. new section on guidance on 3rd party disclosures. lots of editorial stuff. this has been a success in mailing list use. one thing got dropped -- case studies from long ago not just recent. not sure how useful. as always, have to align with sob drafts. sob: there is an RFC, variants for original IPR case that caused 2026 revisions ppp negotiations for compression. is an RFC, will send pointer. not sure if new issues... if there are, go to mike: joe z: in section 4.5, ssh. this is primarily a trademark issue, then still working through, then lessions. but lessions are IPR not trademark. am I wrong in thinking trademark is IPR issue? joe: use of trademark is usually permission with obligations. not concluded so how get lession. is person with name on doc the person going to get sued for using trademark? **take it to mail. - -=-=--=- valerie see: on list suggested that might make things simpler for people use a disclosure template or a piece of boilerplate a little discussion about if required or not: I think not. even if optional, it might help guide... make it simpler for disclosers to provide what's neeeded and for receivers to understand. think it would be very helpful to provide as an option. if don't like it, don't have to use. can use email. but in interests of simplicity, and disclosure of right info, would like to see us do that. other comments? bob wyman: one thing that concerns me is 3rd party disclosure. innocent that tries to warn people about problem. I was recently flamed for warning WG about a patent issued a few weeks ago. Can find some way for person to innocently come forward without hiring a set of atty's. has to be made simpler for 3rd parties. can understand complexity for those claiming rights. sob: bob sent email, got flamed awful... well outside bounds of polietness, didn't understand what's going on. part of what we need to do is clarify situation, so people on receiving end don't believe there is somethng wrong with sending that info. am embarrassed bhy ietf for what he got. i got up to say that optional form is a good idea. but, NOT for 3rd party claimants. emphasize optional. smb: speaking personally, two templates, one for submtters one for 3rd party. my patent atty was confused when I wanted to do 3rd party disclosure for stuff I had. black: context: for 3rd party disclosure, actually filing is not first step. 1. taking up to wg chairs first would be good to sort wheat from chaff robert: want to know opposition to form and why not make it mandatory? ITU has such a thing (as does xxx). we could get a better web site where people can look up info to see what people have disclosed. IEEE has readable matrix. free-form text and lack of indexing of IETF is hard to wade through. would rather have mandatory form w/free form comments sob: 1. I have put suggestions in for reformatting IPR page. when secretary gets resources will do so. here is crapola. a form for submitters can be made more mandatory than form for claimants. want relatively low impact for disclosure by claimants. not wed either way... but difference from submitter than one that is claiming. [topic now] black: concerned about mandatory: guidelines, what we want to see to mandated certain language... lots of opportunity for lawyers. chuck adams (many of q's avove): IEEE has form, but optional. ITU has form as well. if don't complete form, don't recognize disclosure. valerie: we're eng. doesn't make sense to do something mandatory without road-test. will probably revise as we go. want to make it easier. joe z: was comfortable until said road-testing. thought optional was optional, say 'road-test' think mandatory. - --=-= at any other business w/in current charter part. no one stands up. - -=-=-=- steve: OK, at free-for-all. once completed (we're within shouting distance), discuss if consensus to recharter to CHANGE the IETF IPR policy which broadly speaking has been RAND. "RAND permitted" - sob. scott brim: that's one way of phrasing it. 6.7 out, because not current... not changing... there are a lot of increments we should do. bob wyman: before one can determine if change, determine need for change. recharter for requirements statement. forum for talking about problems... lots here. sob: answering other scott. opening constitutional convention to tweak for things for IPR last call... opening a swamp. before really need to do, refrain from doing so. don't think our running code has shown a problem. I fail to see impetus for dramatic changes. small tweaks -- wait a while before doing. brian carpenter: agree with scott the 2nd said. I haven't seen evidence of problems... only problems with implementing existing policy. correct thing to do - get docs in place - run code and see if got rid of lack of clarity. We should close or go on hiatus until we see there is a problem. smb: if re-charter 1st step would be writing a good charter. not only fear consitutional convention & swamp. challenge is writing charter so not open season on everything. joe z: don't understand existing problems. support completion of docs, and understand with ongoing basis if there is a problem before charter. q: 6 months ago... thought needed recharter. slowly come to the opinion that clarifying things a great deal. good enough for org to function. no longer convinced rechartering is necessary. go on hiatus, see how things go, and reconvene if get into problems. smb: hiatus, disband, would be up to harald as ad. anything else: from volume on mailing list suprised. most vocal ones not here. per 2418, any consensus here has to be verified on mailing list. sob: 2418: that also says one takes into account feeling in room when interpreting consensus on mailing list. strong support in room for not rechartering, relatively strong but isolated support on mailing list, shouldn't take priority. problems kerithi kompella: been not following mailing list. do think there are problem, not sure IETF that should solve them. should at least be a discussion. would like to consider rechartering. room: state a problem the problem is: (how put it so someone far away doesn't strangle me) have stds, proposed stds wehere people have IPR. can we move to a system where we have a patent pool idea, or something else... clearer to implement than trying to understand RAND. should we go in that direction. is a problem for vendors. think there is a problem. patent pool like others do, sholdn't dismiss out of hand. otoh, should finish what we've done first. sob: patent pool has come up a number of times. on email, private discussion. not an irrational thing to think about, but relative to IETF? no particular reason for companies coming together to form pool w/o ietf involvment. hard to see how ietf would operate such a thing (mechanically, process wise). even if good idea, not sure affects IETF. joe z: is a wg that is addressing problem issues right now. what I though I heard was a proposal how to handle IPR. if really a problem, address it in problem working group, not in IPR. don't agree that patent pool has aything to do conceptually with our documents. realy a way to gen revenue for IPR in a document. smb: not certain relevant to this group. clear that patent pool, and other ideas on mailing list (binding contract on submitting) would require major change to structure to IETF (formal membership, etc), that would be a problem-statement thing if identified as area. this group is not going to change IETF into patent-sharing membership org. kreeti, followup: to have a few people go off and have patent pool among themselves, doesn't map into IETF. where IETF might get involved: if you want to submit a stds track document (or whatever) you have to license on REASNOABLE and ZERO terms instead of RAND. harald, no hats: the doc as currently clarified permit a wg to write a std where all the IPR is known is royalty free and documented in ways that people can find. if community, the Internet community (Inot just IETF): if of mind that is what is needed... rules permit this (doesn't reqiure). if comty wants, community can do. sob; patent pool is fine for people inside pool. those standing outside have a problem. w/o something lkike formal membership... then we've got a problem. the little guys are scrod. [boston past pluperfect] brian carpenter: whether or not pool is a fine idea is a good discusison... but it's what industry associations do. but that's not us, not even close. not even out of scope for WG, but for IETF. alan low: what the problems are... looking at mailing group list, see two problems. 1. third party claimants that come in after the fact (and don't participate). not sure an answer here 2. people who participate and contribute to standard. there have some measure of control. that's the whole point of clarifications. but problem: RAND doesn't have a meaning in legal, techincal, or any sense. it's a way for the companies that will be IPR claiments later to get past issue and have std move on without having to give up anything. in practice, a vendor company has no meaning. it is the IPR claimant that can demand a certain amount of money... usually % of revenue. not sure anyone here would thingk 1, 2, 5% reasonable as royalty to impl std. don't want to loose site of fact that what reasonable is... and what we think of, in practice has completely different or no meaning. what happens is that must pay IPR claimant wants, usu % of revenue. possible solution: when IPR claimants make disclosures be more specific. RAND is too vague, ambigous. if more concrete, then WG can really take into account. sob: I don't disagree with what prev speaker said... but I do. there's something very different between: tech, adopt it, and tell us what charge for it. I have a real problem with 2nd party... you submit ID with IPR in it, that forces my hand. I have to tell you how give up those rights. that's extortion. people whose ipr has been entered, even if they didn't enter it... is extortion and we shouln't be invoved. george the lawyer: point of clarification... RAND is not new, and in lawyers view is standard and known. Courts and people that look at decisoins do know how mean. in US, damages of patent claim usu % of problems. in any particular case, is in eye of beholder... but are measures and tests that are used to figure it out. gone to most well understood. other than zero. q from chair: what kind of lawyer are you? I am THE lawyer. (laughs). I advise the IETF on legal issues, try to present IETF perspecitve. spencer dawkins: tell us what plan would be for licensing... not sure what that means with financial retrenchment and mergers & aquisitions... not sure can take much comfort in a statement at one point in process. can't count on it for much. black: have been instances where IETF has pressed for and gotten disclosure of specific licensing terms for specific patents... but case by case based on patent procedure & importance. best left that way rather than all disclose up front. q (allan low): rand is old term. xxx participated in panel before FTC as to what RAND is. the consensus among panel was that it had no meaning. one speaker: dick holloman, pointed out that companies would get what they can get, and tha'ts reasonable. every license will be unique. if people are fine with RAND, that's the IETF's perrogative. but don't want people to leave with believeing that there is any certainty about what RAND means. When talking about % of royalties, it's 10s and 100m $... if that ambiguity is OK, that's fine, but don't delude ourselves. also don't believe can't consider different things based on strucutre. everyone has MPLS, ... patents. if have 20 companies, at 1% each, talking 50% of revenue. not profit, revenue. multiple patents, multiple claimants, so is a big problem. sob: all of that is true, don't believe relevant. nothing we can do. claim that comes in after the fact, or comes in after process. this is the real world. the whole point of IETF process it to let them think about problem. doing something like forcing royalty free doesn't deal with most of claims. if forced royalty free, expect orgs won't participate just so they can claim IPR at later date. trying to find the doc, variance, to get PPP compression done. done because old process req'd licensing terms to be provided. motorola (3rd partie) claimed IPR in IETF document. refused to provide terms. this caused a deadlock in process. (claims can also be fallacious) don't want to hand dos opps to people that might use them. black: from personal knowledge, RAND not as ill defined as previous speaker wants to belive. claimant happy to license, but would not agree to RAND. q: 3-4 mos ago before atlanta... pub thing about philosophy. we're here because want to work with people. people that aren't here - individually, want free - if we insist to make things royalty free, people here will be restricted. penalty: diliberations slower, and may have to redress things. give us wiggle room. big advantage, let's not get rid of it completely. "is this particular horse on life support yet". - -=-=- OK. 1. do you wish this group to recharter to cdhange the IETF's IPR policy hum for (some) hom anti (more) fairly clear consensus against rechartering. anyone disagree? harald: will verified on mailing list, will lead to some debate. if consensus is reached against rechartering... the IETF will not consider proposals to create or reactivate IPR wg before people with compelling arg to do so. those should be different than what prevented so far. 1. specific cases where we had a problem. likely result, before vienna, have an opportunity to thank chairs and community and declare wg closed.