Intellectual Property Rights (IPR) BOF Friday 19 July 2002 IETF 54, Yokohama Chairs: Steve Bellovin and Rob Austein Scribe: Spencer Dawkins Summary (by Rob Austein): Goals of BOF were to: (a) invite general discussion of a set of proposed updates and clarifications to section 10 of RFC 2026, based on experience gained and advice received since RFC 2026 was written; (b) invite general discussion on whether a companion informational document detailing rules of thumb for WGs when handling IPR issues, showing examples of ways in which challenging licensing and copyright issues have been dealt with in the past, and generally documenting the state of the "running code" that the IETF uses to handle IPR issues; and (c) attempt to determine whether the IETF should form a WG to work on the documents described in (a) and (b). Please see IPR WG charter (just approved as these minutes go to press) for a more detailed discussion of the problem space. Most of the BOF was spent on discussing two drafts intended to be a first step towards goal (a) above: a "rights in submission" document addressing copyright and similar issues, and a "rights in technology" document addressing patents and similar issues. The BOF appeared to achive rough consensus that items (a) and (b) do indeed need to be done, and that a WG (c) should be formed to do them. The proposed charter previously discussed on the mailing list passed the BOF without comment (whether because it was a good, because everyone with something to say had already said it, or because the BOF was held on the Friday morning of an IETF week, deponent sayeth not). Detailed minutes follow, with many thanks to the BOF scribe (Spencer Dawkins). Apologies in advance for the "Alice said, Bob said" style, as well as to anyone mis-quoted, mis-identified, mis-spelled, etcetera; given the eye-glazing nature of the subject matter, Spencer did a better job of capturing the details than we had any right to expect. Chairs have made minor editorial changes to Spencer's minutes to fix spelling, punctuation, and similar issues and to resolve ambiguous names where (believed to be) known; please blame the chairs for any errors, not Spencer. ================================================================ AGENDA (as posted to the mailing list) Lead-in: agenda-bashing: 5 proposed charter 15 2026 clarification: trademark 10 copyright 15 patent 30 Revised IPR policy? 45 Refocus on 2026 clarifications 30 ================================================================ DETAILED MINUTES (AS RECORDED BY SPENCER DAWKINS): AGENDA BASH No changes made to agenda. We need to clarify RFC 2026 - separate copyright and patent text, add trademarks, add "note well". This is needed, no matter what else we do. WG MAY re-charter to produce a revised policy, but not for sure at this time. The mailing list is ipr-wg@ietf.org (usual subscription mechanism). ---------------------------------------------------------------- PROPOSED CHARTER There was very little reaction to proposed charter - BOF appeared to accept the proposed "clarify first" procedure. ---------------------------------------------------------------- DISCUSSION OF CURRENT INTERNET-DRAFTS (Scott Bradner) Proposed updates to RFC 2026 section 10 split into two I-Ds - copyright/trademark and patent I-Ds. This is design team output, so it's not sacred - comment or write your own proposal. Goal is to make submission rights explicit - including "rights to use trademarks". This was sidestepped in 2026. Scott Bradner showed section-by-section comparison slides, which will be available as part of report. First document discussed was draft-bradner-submission-rights-00.txt. Robert Elz: This is a big improvement - we're now addressing both government IP and public-domain IP. It is possible now to publish an I-D without granting the right to create derivative works. Christian Huitema: Twiddled rights sections have been a major issue - what can the working groups do/not do with twiddled rights sections? Scott Bradner: Standards-track documents must grant the right to create derivative works. Robert Elz: But a document isn't a standard-track document until it becomes an RFC? Scott Bradner: It's a fundamental question - do we let the working groups to decide what to do with these documents, or tell them what to do? Most area directors tell WGs not to work on documents they can't change, but this isn't written down. Bill Sommerfeld: It would help if it's written down somewhere that WG chairs can decline to accept documents that don't grant the right to create derivative works. John Kleinsen: There are a couple of corner cases here. One is "you don't get the rights unless you publish the document as a standard". We could either prohibit, this, or we should prohibit it unless an AD thinks it's the right thing to do. David Black: Should this happen when we publish the WG 00 draft? Dan Rosescu: What about reviewing IEEE MIBs at the IEEE's request? Scott Bradner: This is explicitly allowed by the current text. Dave Crocker: The requirement that rights be handed over to the IETF is straightforward - the question is "when". Handing the rights over too early is unfair to the author, too late is unfair to us. This needs to allow negotiation. Jorge Contreras (IETF lawyer): The rights granted to the IETF are needed immediately when a document is accepted, because the IETF "publishes" it as an Internet-Draft. Section 2.3.A.C (which discusses trademarks) is new. Steven Dreverage: How do we know the contributor can grant these rights? Scott Bradner: There is text requiring this, but if a third-party is submitting someone else's text, this isn't covered. Jorge Contreras (IETF lawyer): If the contributor doesn't have the rights they grant, not much we can do, anyway. Eric Nordmark: "Known to the contributor"? Scott Bradner: Good question - take it to the list. Bill Sommerfeld: Lack of clarity about whether other implementers can use a trademark to refer to a protocol. Jorge Contreras (IETF lawyer): Complicated because IETF doesn't sell products itself. If someone who DOES sell products uses the trademark, the owner of the trademark will have the right to collect fees for it. This is more applicable to patents. Amiel?: Given the size of the community - we aren't lawyers - what does 2.3.a.A mean? Scott Bradner: This is only about publishing documents. Robert Elz: Can we stop publishers from selling collections of RFCs? Scott Bradner: No, that's one of our oldest traditions - ISI sold stuff during the ARPANET days. David Perkins: Can the lawyer put together something we can show OUR lawyers to show what's involved when we author a document? Scott Bradner: One suggestion was to have submission Charlie Kaufman: But we represent ourselves as individuals? Jorge Contreras: This is from the company's IP policy... David Perkins: Can we say "the organization that sponsors the author"? Scott Bradner: Take that question to the mailing list... We're now saying "to the best of your knowledge" instead of assuming omniscience... 2.4.D is new. Rowan May: What was the motivation? Jorge Contreras (IETF lawyer): This has come up before, and we haven't had any way to address it in the past. Rowan May: Is there liability to the IETF if we don't include it? Jorge Contreras: If the IETF continues to republish defamatory remarks, yes... Christian Huitema: We need to think twice. This doesn't cover math errors, for instance? What country's law applies? Jorge Contreras (IETF lawyer): Laws are different - this is a minimum addressing illegal acts. "Intentionally untrue" doesn't mean "wrong". Robert Elz: what about writing something that is untrue in order to debunk it? Rowan May: Do we have to look at each posting and each Internet Draft to monitor this? Scott Bradner: It's all about when we're notified. Jorge Contreras: This helps the IETF, because it puts the onus back on the libelling contributor. 2.4.E is also new (tell us that it's a trademark). 3.1 has two major items - "portions are copyrighted" and "authors retain rights". The disclaimer has the same treatment of contributors as the IETF. Robert Elz: You can't disclaim all warranties in some jurisdictions. Jorge Contreras: True in at least some cases (consumer protection). We're talking about standards that don't catch on fire, not implementations that do. Herb Rateen(?): Authors of RFCs are granted more rights than contributors to these collaborative outputs. Scott Bradner: "Contributor" is defined in the document - whether running spell-check gives you rights is a good topic for the list. Section 3.2 is slightly modified from RFC 2026 boilerplate. Discussion moved on to draft-bradner-ipr-technology-00.txt. We don't pass judgement on the validity of IPR claims. WGs have discretion to use or not use encumbered technologies. Dave Crocker: The ITU requirement is similar. David Black: Working group decisions are subject to further review (IESG, etc.) Need guidelines for these as well. Scott Bradner: There are still some clarifications for various scenarios, based on who notices the IPR and when they notice it - the owners may not even participate in the IETF. Some people have enthusiastic claims - and may not be made in good faith and may be efforts to steer the working group. TJ Lefton: "All participants are required to disclose knowledge of IPR when they notice it". Scott Bradner: This is patents and patent applications - and an employer may not allow disclosure patent applications. If you're in the situation, you don't have to disclose - but you can't contribute on the mailing list or at the microphone. Steve Treveridge: If a company has a policy granting licensing, etc. do I have to disclose this? Scott Bradner: On the list. Harald Alvestrand: The IETF has a long decision process - can we say "the IETF can decide"? Scott Bradner: Good idea. Andy Samolen (?): What about disclosure that don't affect the work of a working group? Scott Bradner: Many people are asking for clarifications about what to disclose and when. Andy Samolen: What about broad IPR claims and patents ("anything that uses touch tones on a menu system")? Scott Bradner: Any IPR that must be licensed, should be disclosed. Let's talk on the list. Scott Brim: Fishing expeditions are moot when a working group adopts a document. And we don't have to worry about bad-faith claims. Scott Bradner: talk on the list. David Allen: In the US, you have a year to pursue IPR - what about POSSIBLE LATER IPR claims? Scott Bradner: A good thing to talk about. Jim Rankle: "Any"? Scott Bradner: this is the concept, not the text. James Woodyatt: Concerned about "all participants"/"all IPR" - not just what I filed myself. Section 2.2.1 adds a note about boilerplate. One of the biggest problems in RFC 2026 is conflicts about whether it applies to all documents or just standard-track documents. Now all documents are covered. John Kleinsen: What constitutes an IETF document? I can work with you offline. Scott Bradner: This is a good point - a document may be submitted to RFC Editor directly. Tom Taylor: "Openly specified terms" - has it been there all along? Scott Bradner: We need to address this. Aaron Falk: What/who is the IETF executive director? Scott Bradner: Today, it's Steve Coya... "Reasonably and personally known" is explicitly defined in section 7. You don't have to do patent searches, but you can't be stupid. James Woodyatt: We are famous for compartmentalization - what's "reasonable"? Scott Bradner: Good question - the term comes from case law. Jorge Contreras (IETF lawyer): Can't have too many rules here - too much variation. But companies can't keep you in the dark. If you're being deposed, we're not in control of the determination anyway. John Taz: There are lots of interesting cases about "reasonable" - the author of the patent may not know what the lawyers actually claimed in the patent application! Jim Rankle: "Make a contribution" isn't "submit a document or participate in discussion". It's not only submitting Internet-Drafts. Jim Rankle: My exit interview prohibits my disclosure. Scott Bradner: That's a previous employer - not covered by the document anyway. ---------------------------------------------------------------- PROPOSED UPDATE: USAGE RIGHTS FOR PARSABLE CONTENT IN IETF DOCUMENTS (David Perkins) This is usually needed for SNMP MIB definitions. Parsable content might be changed (porting, bug fixes, etc.). RFC 2026 doesn't seem to allow this modification and redistribution. Proposal is a checklist of things that, if you do them, you can use this content, even with modifications. Scott Bradner: I did include text in the revised documents that attempts to address some of these things. "Bug fixes" may not be "extensions", for instance. ---------------------------------------------------------------- DISCUSSION: FREE-FOR-ALL ON IPR CHANGES David Black: "Blanket disclosure" - what if someone backs out in the middle of the process? This was a third-party problem. Randy Bush: What are our goals here? If the IETF's goal is to facilitate widespread deployment and interoperation, what are the minimal things we can do to support this? One thing is to be more specific about things like licensing terms. Robert Elz: The "IETF" doesn't make decisions quickly - not a reasonable way to make decisions about whether a working group should work on a document, etc. Harald Alvestrand: Not my intent to keep the working group from making these decisions - they're just not the only ones who need to be involved. Bill Sommerfeld: Standard list of questions for someone coming in with a document for a working group? Steve Trowbridge: We need to be clear about what a "blanket submission" covers, especially for third-party submissions of someone else's IPR. Andy (W3C advisory committee): Successful approaches rely on a "one-China" approach - when we're open, uninvolved third parties have to be engaged (otherwise non-participants have more rights than participants). William Dixon: What about contributions to requirements discussions? Scott Bradner: How do we know when a discussion even starts - we spend a lot of time just talking out loud. We may not be able to do anything about this. Jorge Contreras (IETF lawyer): At least in the US, you have to claim who the inventor is, so you can't just scrape ideas for patents. William Dixon: We don't have rights until patents are filed. Rob Austein: We are thinking about claims to rights, too. Melissa: "We may or may not have patents in this area'... Jorge Contreras (IETF) Non-specific disclosure wouldn't comply under our proposed policy. John Tabs: We may want explicit disclosure, but determining scope is hard. Andy Zamole: Per-posting disclosures? Where's the safe harbor? Scott Brim: Drafts change all the time, this is hard. Steve Treveridge: We need a way to move forward without constant disclosures. Blanket licensing statements help. Elizabeth: Does "may or may not" violate current policy? Jorge Contreras (IETF lawyer): The only time this ever gets judged is when someone tries to enforce rights against an implementer. Elizabeth: What about work that bridges IETF and ANSI? John Tabs: An intellectual may put a company at risk by not complying, but how strong is the linkage? Jorge Contreras (IETF lawyer): At the FCC in the US, you are assumed to be representing your company. John: but this case law involved companies that actually joined/signed something. Randy Bush: What about cryptographic signing of illegal/defamatory material? Jorge Contreras (IETF lawyer): There may be laws out there that may be overturned, but they are still laws... We need to be able to prove that we're TRYING to be compliant. Carsten Bormann: From ROHC: Sometimes we're standardizing technology that is required to be unencumbered because we're deploying it all over the Internet. David Black: When claims arise that someone else's IPR is involved in a standard, the working group is on its own in unscrambling these claims. Randy Bush: We're not lawyers - let's wait for court orders before we pull material. Scott Bradner: Talk to the lawyers. Robert Elz: It doesn't make sense to require unencumbered technology for our standards - we can't even hold meetings without encumbered technology (like "Ethernet"). Steve Hanna: All of these documents refer to "reasonable and non-discriminatory", and that's in the eye of the beholder. Guidance to working groups? Scott Bradner: Documents do say we prefer technologies with no known IPR, and this was left out of 2026 on purpose. We got seriously rat-holed when we discussed this in 2026, and based it on the standards process itself... If we get enough interoperable implementations to advance on the standards track, the technology must be meeting minimum criteria for licence-ability. William Dixon: Are you saying you don't want a recommendation of the licensing terms? Scott Bradner: we haven't gotten consensus on preferring unencumbered mandatory-to-implement technologies. ---------------------------------------------------------------- DISCUSSION ON WHETHER TO CHARTER A WORKING GROUP Do we need to become a working group? We need the documents whether we form a working group or not. Randy Bush: We need a mailing list, more than we need a working group. Rob Austein: The main distinction is whether we need face-to-face meetings or not. Melinda Shore: What are the advantages to having technologists discuss law? But if we're going to do it, transparency would be a good thing. Harald Alvestrand: Having a chartered working group makes it more obvious what's going on. Ted Hardie: These things do two things - tell how people participate in standards, and tell corporations how to interact with standards. James Woodyatt: Discussing law isn't the same thing as practicing law. Fred Baker: A lot of RFC 2026 was armchair-lawyering - getting input from corporate lawyers would be helpful Andy: What about companies participating in the IETF? Scott Brim: People act as individuals when they bring in contributions. [Chairs conduct one last set of hums for the road] Chairs: We appear to have consensus both that this work needs to be done and that we should form a WG in which to do it.