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.