Draft minutes, IPR WG

Below are the draft minutes taken by Ed Juskevicius. Thanks, Ed!

Corrections are welcome!
Final minutes are due by April 16 at the latest, so please be quick!

                 Harald

IPR WG MEETING MINUTES: March 21, 2006, 13h00 – 15h00 local time

13h00 – 13h10: Introduction and Charter Status Update

Harald welcomed everyone, and made the following introductory remarks:

   1.

      the IPR WG is about intellectual property rights as handled by the
      IETF

   2.

      it is **not** about what goes on outside the IETF

   3.

      it is (in some cases) about making sure the IETF does not get
      entangled in things that are none of the IETF’s business

The agenda was accepted without bashing. Ed Juskevicius was volunteered 
to scribe these minutes.

13h10 – 13h25: “RFC 3978 Update”, presented by Scott Bradner

   4.

      The purpose of this document ((draft-ietf-ipr-rules-update-03)
      came originally out of an IPR WG meeting we had quite a while ago
      where the consensus was “the IETF should ask for additional rights
      from the submitters of contributions to the IETF”. The additional
      rights are for 3^rd parties to make extracts of any kind (e.g. to
      copy pieces of IETF documents and include them in documentation,
      or on a web page)

   5.

      There was not a consensus about whether the IETF should allow 3^rd
      parties to make derivative works

We have had a test case on this. The IETF would like the IEEE to take 
over the development of Ethernet MIBs, but we don’t have the right to 
say (to the IEEE) “just go do that” because we did not get that right 
from the original contributors, so instead what needs to be done is that 
the original contributors have to be asked if it is OK to go and do this.

Also, the IETF Trust was created in December 2005, and has been 
acknowledged in the update document. The update also includes some 
discussion of outbound rights and inbound rights, plus a definition of 
the term “IETF participant” (because it is used in the document). We 
probably should remove the outbound rights from this document, and put 
them into Joel’s document.

The other open issues with the document are:

   6.

      What are we trying to accomplish with the copyright statement?

         1.

            What is it for, and is it needed?

   7.

      Should the document focus only on inbound rights?

         1.

            What is the definition of inbound rights in this context?

   8.

      How do we proceed? Do we do this as a delta to RFC 3978, or do we
      put out a revised RFC 3978? Scott hopes we agree to do the latter.

Discussion:

David Black:

I want to confirm the only piece of this that will be moved into Joel’s 
document is section 5, namely “rights granted by IETF Trust to third 
parties”, and that section 4 (“rights granted by the IETF Trust to make 
the IETF operate”) will stay in this document.

Scott Bradner:

I think that’s an open question. My proposal is to do it that way.

David Black:

I concur with that proposal. Harald, do you want to do something about this?

Harald Alverstrand:

I’ll take that under advisement after this discussion is over.

John Klensin:

These regular revisions to IPR statements have got to stop. It is pretty 
clear that we have two interrelated problems with 3978. The successor to 
3978 has to be ridiculously painfully clear about when it is talking 
about copyright, and when it is talking rights to do with underlying 
intellectual property.

Also, our copyright notice situation, especially for internet drafts 
(I-Ds), is “muddled” (to put it politely). We might need to separate the 
material we want placed into I-Ds and the material we want placed into 
RFCs in a more fundamental way than before. We need to be certain we 
don’t make claims to rights that we do not have. We need to focus here 
(and on the mailing list) on what we are trying to do, versus trying to 
outguess the lawyers.

Jorge Contreras (the IETF’s lawyer):

One problem, which is easy to fix, is that RFC3978 calls for every 
document to have to have 2 copyright notices: a plain copyright notice 
with the year and name of organization (i.e. ISOC or IETF), plus another 
with some explanatory text. There is no real need to have two. All 
standards documents are works of authorship, so adding an explicit 
copyright notice on them is not actually needed. It would be enough to 
just have one copyright notice.

The purpose for putting a copyright notice on a document is to notify 
the world that a certain organization thinks it has rights, and also 
because the having the notice on a document is necessary (in U.S. 
courts) to enforce those rights against certain types of damages.

Copyright can protect many different aspects. In the IETF process, the 
ownership of the text in an I-D is retained by the author. It is not 
assigned to the IETF. It would not be correct for the IETF to say it 
owns all of the text in an RFC or in an I-D.

The aspects which the IETF (or the IETF Trust) does own are:

   9.

      the organizational structure of IETF documents (i.e. RFCs and I-Ds
      are somewhat unique in how they are put together),

  10.

      the boilerplate text on all RFCs, and

  11.

      the RFC numbering series (from RFC0001 to RFC4000 ...)

The naked (simple) copyright notice (that we put on documents today) 
might imply to some readers that the IETF “owns” more that it actually 
does, and that would be inaccurate. This problem is more pronounced with 
I-Ds. Several elements (that the IETF could claim ownership of) are not 
present in I-Ds (e.g. I-Ds do not have an RFC number). An I-D, as 
contributed by an individual person, does not go through the whole IETF 
process. Other than the boilerplate text and the structure of the I-D, 
there are not that many copyrightable features in an I-D. So a good 
question is “What does the copyright notice on an I-D actually mean?”

Simon Josefsson (via Jabber):

Why are additional copyright notices not allowed?

Scott Bradner:

We had a number of specific instances where individuals wanted to put 
their own copyright notice on an RFC. It was felt that would add 
confusion, especially if the individual was one of several authors, or 
the editor of a WG document (where the WG had made significant changes 
to the originally contributed I-D), so we made a requirement that 
someone who wants to put an additional copyright on a document needs to 
seek permission on a case-by-case basis to do that from the IAB, rather 
than automatically having the right to do so. The only cases that I know 
of, where we have allowed other copyright notices, have been where the 
IETF has republished standards from other organizations.

David Black:

If the IETF was the exclusive owner of the boilerplate text and the RFC 
structure, that could be a good way to stop fake I-Ds!

John Klensin:

I think we have got to get over trying to fine tune this stuff over 
theories that have no legal basis. If our purpose in having a copyright 
notice is to protect the boilerplate, then that needs to be clarified. 
Right now, the copyright notices seem to claim ownership for the entire 
document.

David Black:

To violently agree with John, I think the goal is to put what amounts to 
an obvious legal hurdle in front of those who would create fake RFCs. It 
should be clear to someone who intends to create a fake RFC, that doing 
so would be violating a copyright.

Harald Alvestrand:

The required copyright notices should claim something that is legally 
defensible. There are pieces of I-Ds that we require to be there, but 
exactly how to phrase the copyright notices for those pieces is lawyer bait.

Joel Halpern:

We need to be clear on several things. Any copyright statement needs to 
be clear on what it covers, and what the objective is on putting 
copyright notices on RFCs and/or on I-Ds; maybe we don’t need one on 
I-Ds, but we do on WG ones … etc. Let’s be very clear on what we need, 
and then be really crisp on how we will accomplish it.

John Klensin:

In the RFC case, it might be possible that the RFC Editor creates a 
derived work (based on what the authors put in, plus everything we put 
in, plus the editing done by the RFC Editor) where ISOC or the IETF 
Trust would want to copyright the whole thing. But that would violate 
our principle that authors retain ownership of their text in RFCs and I-Ds.

Scott Bradner:

The process by which we create a document is a collective work, and I 
don’t think we can make a decision today on what we need to do. I agree 
with Joel that we need to crisply figure out what we want to do, and 
then do it.

Harald Alvestrand:

The copyright statement issue needs further work, both to clarify what 
we need and how to do it. So that goes to the list.

Stephan Wenger:

Is there a desire to reduce the two copyright statements in documents to 
a single one?

Harald Alvestrand:

Does anyone see a value to having a maximum of one copyright statement 
on documents? (Several people raised hands to indicate “yes”). Once we 
get to designing a new boilerplate around these principles, it seems 
that it should only be going in one place. From our discussion here 
today (from the list), I think there is support for putting all of this 
in a new “3978bis” rather that a “deltas to 3978” document.

Lucy Lynch:

As an IAOC Member and IETF Trustee, I’d like to ask what your timeline 
is for a new document vs. a delta document. The Trust is transferring 
new IPR to the IETF every three months.

Harald Alvestrand:

I don’t believe there is a significant difference.

Sam Hartman:

On the outbound rights question, I think it would be simpler if all of 
the outbound rights were pulled including line 4 (“rights granted by the 
IETF Trust to IETF participants”), but I don’t really feel strongly 
about pulling line 4.

Harald Alvestrand:

OK, we have three different proposals:

  12.

      3978bis is only inbound;

  13.

      3978bis is inbound plus rights granted to IETF participants as
      they are participating in the IETF;

  14.

      3978bis contains inbound rights to participants and rights to
      non-participants

Scott Bradner:

I believe 3978bis should include all rights needed for participants in 
our standards process. I do not believe it should include outbound 
rights to third parties. I think that should be governed by a different 
document that instructs the IETF Trust on what it should do.

Ted Hardie:

I think the implication of that is that we have to grant rights to 
everybody because implementation is a requirement for the standards 
process. Therefore we may have to do outbound rights. There are 
documents we write for which one of the outbound rights required to do 
an implementation is an outbound right to use an extraction a table, or 
something similar like a MIB.

Joel Halpern:

We have to talk about rights granted to implementers in an outbound 
document. We are going to grant some rights to all implementers. Even 
the rights to work on a document here (in the IETF) are technically 
going to be granted to us by the Trust, according to what we ask the 
Trust to do, so we have to the Trustees (who we have put into the middle 
of our process) what we need.

Scott Bradner:

If we have an outbound rights document, it will need to grant the right 
licenses to people who want to implement an RFC. I don’t believe the 
outbound rights document can be an informational document. We will need 
it to be a standards document (i.e. a BCP) for what we need in order to 
implement our standards.

Jorge Contreras:

From RFC2026 and onwards, contributors would grant rights to every IETF 
participant in the IETF process. Now we have the IETF Trust. It is just 
a technicality that we now have an IETF Trust which is interposed 
between contributors to the IETF and participants who we grant rights 
to, as the Trust simply passes everything along to the participants. I 
am not sure it is accurate to call that an outbound license right.

Harald Alvestrand:

Should outbound rights granted to participants in the IETF process be:

- in a 3978bis document?

- in the outbound rights document?

** 3 people raised their hands for 3978bis (including the IETF’s lawyer)

** 5 people favored in the outbound rights document (not including our 
lawyer)

Harald Alvestrand:

*** Let’s take this to the list as *unresolved*.

Now, switching to “outgoing rights” (at 13h47)

Harald Alvestrand:

The outgoing rights are the rights granted to the IETF Trust, and 
administered by the IETF Trust in how they are granted to participants 
and non-participants in the IETF.

Lucy Lynch:

There is now a website which will move to trust.ietf.org, containing all 
documents signed on Dec 15, 2005 and the Trust FAQ. In addition, we are 
making a quarterly transfer now from ISOC to the Trust of RFCs being 
lublished with the old footer text in place, and we are working on 
licensing for language for things like marks (like the one you saw this 
week for IETF@20). Another thing on the website are our operating 
procedures, which confirm we agree to be bound by the RFC/BCP that 
dictates the behaviour of the IAOC.

Joel Halpern:

Simon Josefsson sent some very nice comments which will be incorporated 
into the outgoing rights document. The document is a whole lot of ‘this 
is the situation’ and ‘here are the topics’ but not very much meat under 
many of them right now. The current organization is merely because we 
need some sort of structure to start with.

Harald Alvestrand:

The issues that have been raised against the outgoing rights draft and 
which have made it to the issues tracker are:

#1166: Quotations from RFCs and I-Ds, what should be permitted?

#1168 Should all excerpts from non-code parts of RFCs and I-Ds be permitted?

#1169 Should modified excerpts from non-code be permitted?

#1167 Should there be rules for how excerpts (modified/unmodified) from 
RFCs and I-Ds are labeled?

#1175 How can code be distinguished from non-code?

BCP78, as written now, actually makes the code/non-code distinction. 
There are rights which are granted to the IETF in code that are not 
granted for non-code. The issue is should we continue that distinction 
or not.

Discussion:

Brian Carpenter:

Am I correct in thinking that the way BCP78 is written means people 
agree with outbound rights by submitting things to the IETF? Does the 
word IETF (in BCP78) already include the IETF Trust?

Jorge Contreras:

No. The definition of IETF in RFC 3978 would not include the Trust.

John Klensin:

There is a piece of this process which is not included: our shrink 
wrapped “Note Well” licensing (that comes into play when you walk 
physically or virtually into the door here) may be more important than 
all of the copyright text dance we are doing now

Ted Hardie:

Can I confirm we are talking about 3.3(3) for code/non-code? That 
references section 5 … is this NOT a solved problem?

Harald Alvestrand:

I agree this is not a solved problem

Kurt Zeilenga:

What outgoing rights are you trying to grant which are not inherently 
there via “fair-use”? For example, why do we have to grant a right 
(explicitly) for quotations? What rights are in here that are not 
inherently granted already by fair-use?

David Black:

MIBs are a counter example: the amount of a document you need to extract 
to compile a MIB easily exceeds “fair-use”.

Sam Hartman:

I am here today as an implementer. As an implementer who ships a product 
that incorporates IETF standards and that is used by people with a lot 
of different licenses, my really hard requirements are:

  15.

      I need all the rights I have independent of any claims of fair-use;

  16.

      For any code I use in a product, I need the right to distribute
      that code under a license that is GPL compatible (and licenses
      that are much more liberal than the GPL), because some people who
      use my code (and thus IETF standards) ship GLP’d stuff and they
      can’t ship my code unless it can be distributed under GPL. The
      reason I need more liberal rights is because I have people who
      want to ship things under the BSD license.

  17.

      I’d really like the ability to distribute RFCs as part of my
      documentation, both whole RFCs and extracts.

Jorge Contreras:

Fair-use in the US is pretty limited (e.g. to pure research, education, 
parodies), and it is pretty unlikely you would be able to claim fair-use 
for commercial implementation of something, even it is limited to just a 
small piece of code.

In the license grant from contributors, the license is granted to the 
IETF (which means all of its participants and that does not include the 
Trust) but the license is also granted to ISOC, which once a quarter 
will be transferring all of its rights to the Trust, so the IETF Trust 
will end-up with all of these inbound rights from contributors, through 
the assignment from ISOC.

Joel Halpern:

We need to spell out what we want to grant, in English, so we understand 
it. When we are done, if the lawyers then say “Oh, that piece that you 
have asked for is covered by technique x and that other piece is covered 
by technique y, OK”. I need to know what we are trying to do. Until we 
can agree on what we want, and until we can write that into the outbound 
rights document, we will not get anywhere, and there is significant 
disagreement about what we want.

Kurt Zeilenga:

We have a lot of documents that have been published, we’ll have a 
problem making rights changes retroactive.

Harald Alvestrand:

We will not restrict rights that you currently have. The issue of 
granting more rights than you currently have to the old RFCs is a 
problem that we have to address.

Kurt Zeilenga:

I guess I disagree that we don’t have the rights necessary to pull ASN.1 
out of 2251 and implement LDAP. I think we have the right to do that.

Thomas Narten:

There is disagreement over this. We don’t have agreement.

Harald Alvestrand:

The statements that exist now are **not** clear. This is proved by 
people who have different beliefs about what the current rules say. We 
know the current rules are unclear. We want clear rules.

Brian Carpenter:

There are people whose readings of the GPL say it is incompatible to 
take code out of an RFC and stick it in GPL’d code. There are people who 
disagree with that assertion. Both views are strongly held.

Stephan Wenger:

I have a suggestion. I don’t believe the one-size fits all approach 
designed by this WG will work. I think they are very viable cases where 
we want to make large parts of non-code excerpts from an RFC possible. I 
believe there are cases where the IETF should keep full control over 
every letter in an RFC, and I don’t think the IPR working group can make 
an informed decision here.

I believe that the technical WGs are be in a position to make informed 
decisions, but they probably would not like to do so because it would 
make them worry about legalese. Even so, a solution would be to have 
technical working groups tag which parts of which RFCs can be granted 
outbound rights, and for the rest, you have no rights to take anything 
from it.

Harald: The personal opinion of the Chair is this is an instance of 
passing the buck. I would like to have you specify the specific use-case 
(with draft name and section number) because the abstract can not be 
argued about. Specify at least one case where you think a WG should make 
this specific distinction and tell us why. On the list, please.

Ted Hardie:

Simon Josefsson has sent me a draft for me to sponsor as an individual 
submission where he has put forward a license to the parts of the work 
which are his work, where he grants additional rights beyond those which 
are required that essentially translate into “do ye as ye will”. I think 
that’s a workable solution on a draft-by-draft basis, but I don’t think 
we can pass the buck to say that’s what has to happen on every draft. We 
need to have the minimum understanding of what the outbound rights the 
IETF may always grant are, or we have no ‘mandatory to implement’ here. 
We’ll lose, very quickly, real technical work to amateur lawyering in 
technical WGs, so passing the buck on this is not a good idea.

Scott Bradner:

I fully agree. We have running code on this. We have some RFCs where 
individual authors have granted that kind of “do ye as ye will” rights 
and we know it can actually work.

Harard Alvestrand:

I think we have a claim that is running code and current practice, but 
let me check that this is what we want.

“Author can put into RFCs text that gives more

permissions to stuff in the RFC than the IETF

normally grants, and that’s OK”

Who agrees? 10 people (raised their hands)

Disagrees? ½ of John Klensin

Joel Halpern:

There is a more basic issue. We have before us a set of requests for a 
consistent policy that is arguably more that the policy we have had 
until now, and that will apply to all documents, and we don’t have rough 
consensus on what our consistent policy is yet. We need to spell-out for 
both code fragments and non-code fragments what we want to require as 
the consistent policy for everybody, even if we allow some authors to 
grant more liberal rights (but never fewer rights).

Thomas Narten:

Does an author have the ability to grant more rights in a collective 
work, where it’s unclear where all the text comes from?

Scott Bradner:

If you have multiple authors, how do you ensure that all the authors 
have agreed? Of the (two) particular cases that we have published, it is 
not clear that all of the authors agreed in one case.

Harald Alvestrand:

I want to put this issue into the tracker afterwards, and suggest a 
resolution to the mailing list. Let’s wordsmith that there. I think the 
sense of the room is clear, but the details are not. So let’s take this 
to the list.

John Klensin:

I want to explain the 1/2 in the hopes it will change the sense of the 
room. As soon as you say authors can grant more rights but not restrict, 
somebody is going to have to evaluate every author copyright statement 
to make certain it does not restrict. This is one of the reasons why we 
have not done this before and not permitted it before. Unless you want 
to get into the business of lawyers evaluating every I-D that is posted, 
you have to be very careful about this.

Kurt Zeilenga:

I would add that if an author wants to release his works with additional 
rights, that he has the option of publishing it elsewhere. He could 
publish it separately on his own website if he wants to give more rights 
than he gives to the RFC Editor when he lets them publish it.

David Black:

I want to agree with Kurt that having separate publication is probably 
the cleanest way to do additional rights grant, but I am going to 
disagree with the miasma that John paints. I believe that with the right 
language, carefully written by a lawyer, in the master copyright you can 
guarantee that subsidiary copyrights could not restrict it.

Harald Alvestrand:

So, looking at the list of outgoing rights issues, I don’t know if there 
is anything here that is completely un-controversial. Does anyone want 
to make an assertion that one of the issues is not controversial, and we 
could decide on it now?

Scott Bradner:

Issue #1199 shouldn’t controversial. It is traditional that anyone can 
publish whole RFCs and translations thereof. I don’t see why that should 
be controversial. We have done it since day zero.

Harald Alvestrand:

The actual ticket is wider than the sub-bullet. I think the sub-bullet 
is un-controversial.

Scott Bradner:

Can we agree that we grant the right to reproduce unmodified + 
translations?

Harald Alvestrand:

Yes. That goes into the document.

David Black:

I think we have agreed on the sub-bullet under #1199 but not all of #1199.

I suggest a similar partial attack on #1175 (“how can code be 
distinguished from non-code?”). I would suggest that we list the obvious 
suspects (i.e. MIBs, ASN.1, LDAP, C-headers and other obvious ones) on 
the mailing list in a few days, and then we provide a tagging mechanism 
so that anyone who thinks they have something weird could tag it 
explicitly and say “this is code”.

Harald Alvestrand:

That seems sensible to me. So we list the obvious cases, and we say if 
you want to label something as code, then put “this is code” or 
whatever. That seems possible to settle this one.

Kurt Zeilenga:

I assert that anything that we characterize as a formal language should 
be considered “code”.

Scott Bradner

Coming out of the last IPR BOF that led up to my delta document, 
everyone seemed to agreed that excepts, “as is” and independent of size, 
should be allowed to be republished, as long as their genesis is noted. 
I don’t think anyone objected to that (for issue #1166).

Lucy Lynch:

If you can resolve #1167, then most of these become NO-Ops if there is a 
way to annotate where the excerpt came from and if the excerpt is 
unchanged. Only the derived excerpt would be questionable (modified 
extracts or non-code).

Kurt Zeilenga:

Does an excerpt have attribution, and a quotation does not? What is the 
distinction?

Harald Alvestrand: This is my English.

Scott Bradner: That an artifact.

Harald Alvestrand:

We seem to have consensus that excerpts with labeling should be 
permitted, any size, any time (ie. quotations). We’ll take suggestions 
for how to mark them on the mailing list. Lucy, if you remember the 
right page of the Chicago manual style, please post if that is a 
fair-use of that particular work.

Scott Bradner:

In the draft which I did, which Joel will be free to take text about 
outbound rights from or ignore, there is text saying that excerpts of 
any size from documents are OK, and whole documents and translations are 
OK too. I felt when doing it that it would was good to have both (sets 
of words) to make it absolutely clear what is allowed.

Harald Alvestrand:

We have got one (open issue resolved)! The answer to #1167 (“should 
there be rules?”) is “Yes. More or less, all excerpts should be permitted.”

Just checking: “Should there be rules for how to mark excerpts?”

Thomas Narten:

Who does the marking? I don’t understand the question you are asking.

Harald Alvestrand:

The person who does the quoting.

Brian Carpenter:

Let’s make this a “should” not a “must” (for ways to label excerpts). 
There may be places where you use excerpts where it would be ridiculous 
to use a particular way of labeling those excerpts.

* Brian then read aloud some text from a draft GPL v3 license *

Scott Bradner:

We should say “It must be clear what the origin was”, and not make any 
more rules than that, re: #1167. I don’t think we should say “Here are 
the words you must use” or anything else like that.

Harald Alvestrand:

We have to take the issue of “modified non-code” back to the list. I 
think that is the big open issue where we don't have the basis of a 
suggested resolution for that right now. On the other issues, I’ll try 
to suggest resolutions, and Joel will try to suggest text.

IPR Licensing and Requests for Info from the Secretariat (starting at 14h30)

“3^rd Party Disclosure Verification”

Thomas Narten:

For background, RFC3979 Section 4 (C) states that when a disclosure 
related to IPR has been made, the Secretariat (viz. IETF Executive 
Director) is to contact the IPR holder in order to get clarification on 
the licensing terms, applicability and so forth. The actual wording is 
as follows:

“the IETF Executive Director shall request from

the discloser of such IPR, a written assurance

that upon approval by the IESG for publication

as RFCs of the relevant IETF specification(s),

all persons will be able to obtain the right to

implement, use, distribute and exercise other

rights with respect to Implementing Technology

under one of the licensing options specified in

Section 6.5 below unless such a statement has

already been submitted.”

The issue is that in the case of a 3^rd party disclosure, the 3^rd party 
presumably does not own the IPR and so can not really make any statement 
with respect to its applicability, intent to license, or other things 
along those lines.

Scott Bradner:

For clarity, that was a bug in the editing of the original document. The 
issue on the table is not the words currently in RFC3979, but rather 
whether the Secretariat should indeed go after the person claimed to be 
the intellectual property rights holder. The decision in the previous 
case (when we last reviewed this) was that the Secretariat should not do 
that. The issue we should focus on is whether we should go after the 
apparent rights holder.

Thomas Narten:

OK, in the case of a 3^rd party disclosure, it makes no sense to ask the 
3^rd party discloser because they can not answer the question. It does 
make more sense to ask the IPR holder, because presumably they can speak 
to the IPR at issue. The question I have on the table is to specify that 
the intent is to have the Secretariat ask the IPR holder. From one 
discussion on the list, if we do not do this, then the question is “What 
is the point of having 3^rd party disclosures?”

An example of where this comes up from a couple of years ago was IPR on 
what was then the zeroconf working group’s ‘link-local’ document. There 
is no specific IPR disclosure on the document that was produced by that, 
even though a 3^rd party disclosure was made and is on file with the 
Secretariat. Another example is more recent. A 3^rd party disclosure 
were made for some IPv6 documents in October 2005, and we only received 
the clarifying responses (from the IPR holders) last week. This week, in 
various hallway discussions, it has been observed that CGA technology is 
being discussed or described in a number of new drafts, but no IPR 
disclosures have been made. CGA is another case where 3^rd party 
disclosures could be used to query IPR holder in a regular way.

Discussion:

David Black:

We need to proceed with care here. My counsel says “3^rd party 
disclosures are lawsuits waiting to happen”. We need to restrain our 
enthusiasm for getting the Secretariar involved in 3^rd party 
disclosures. On your listed examples, I have been through something that 
resembles your second example where a 3^rd party disclosure can be a 
useful tool to get the IPR holder to clarify their intentions and I 
would hate to lose that as a tool.

Thomas Narten:

In the case of a 3^rd party disclosure, the Secretariat would send a 
standard query to the IPR holder saying “This has been filed. Do you 
have a reaction?” The IPR holder can then choose to respond, or choose 
not to respond. There would be no evaluation on the part of the 
Secretariat. It would be up to the working group to decide how to 
interpret the response or the lack of response.

Scott Bradner:

The first versions of this RFC had this requirement in there (for the 
IETF Executive Director to send a letter). We discussed this in a 
meeting (in Los Angeles, I think). I don’t remember the details but I 
remember two things about it. One was this was not ‘running code’. The 
IETF Executive Director was not sending such letters to people, and 
therefore because the charter of the IPR working group at the time was 
to reflect running code, pulling that text out of there was OK under the 
charter.

The other was that there were some real concerns (but I don’t remember 
what they were) that this was a counter-productive thing to try and do. 
Trying to elicit information from a purported IPR holder that may not 
even know what the IETF is, would cause more confusion than it is worth. 
It was an explicit decision last time to remove this. It was an editing 
bug that caused the current text to be useless.

Harald Alvestrand:

Please note for the minutes that another bug was that the minutes of 
that meeting did not record the decisions.

Stephan Wenger:

My understanding is the bug is the incorrect use of one word.

Scott Bradner:

There was a piece of common text that says what should be done when a 
disclosure is received. It was decided to remove the third case of what 
should be done, and the pulling out of that text resulted in an editing 
bug.

Joel Halpern:

There are two logically extant alternatives here, and only one of them 
makes sense to me. We could say we will not accept 3^rd party 
disclosures because we don’t know what to do them, or we can say we will 
accept 3^rd party disclosures and we will ask the IPR holder what their 
opinion is of the disclosure. I don't see any sensible middle-ground. 
There is no point in accepting a 3^rd party disclosure and then not 
doing anything with it. I would strongly prefer we accept, but not 
mandate 3^rd party disclosures. I would like to accept 3^rd party 
disclosures, and have the Secretariat ask the question. Unless we hear 
from Jorge that there is a problem with doing this, I can’t see any 
reasons for us not to ask the question.

Pekka Savola:

I disagree. I think there is use to accepting 3^rd party disclosures, 
even if we don’t do anything with them. They can raise awareness of 
potential problems.

Brian Carpenter:

As a direct rebuttal, a 3^rd party disclosure that is unresolved is 
effectively pure FUD, its effect on a WG is to chill discussion on the 
technology, and that is undesirable. I believe very deeply that if we 
receive 3^rd party disclosures, we have to attempt to resolve them. If 
the IPR holder is not willing to make a statement, OK, you may have to 
accept that there is FUD.

Jorge Contreras:

A big problem is around non disclosure agreements between companies. You 
should never be disclosing something you learned through a 
non-disclosure agreement. I think it would be interesting to get 
feedback from David Black’s counsel on what the risks here are perceived 
to me. They may have thought of stuff we haven’t thought of yet.

David Black:

I believe the concern is “liability for heaven only knows what”, for a 
3^rd party disclosure is a venue for making all kinds of interesting 
allegations. “Lawsuit waiting to happen” is perhaps the best quote from 
my lawyer about consequences to the maker of a 3^rd party disclosure. 
What I would like Jorge to follow-up on is “Are there second order 
consequences if the Secretariat tries to follow up?”

Scott Bradner:

To be clear on what Joel said, I raised my recollection of the LA 
meeting because the lawyers in the room at the time thought there were 
issues, so the third option was removed, and a conscious decision was 
made to continue to allow the possibility of 3^rd party disclosures.

Harald Alvestrand:

Does the room agree that if we continue to allow 3^rd party disclosures, 
should we be directing the Secretariat to do something mechanical? There 
is probably an action on Jorge to identify the legal issues with that, 
and an action item on probably the IAD to identify the workload issues 
of maybe doing something (if enacted). If they both say “no problems”, 
then we should just do it.

Scott Bradner:

I urge any of you in corporations with lots of lawyers to just chat 
with, because they were very active and involved at the time. For 
example, IBM was active. If Brian could talk to Chuck, it would be a 
good idea

Harald Alvestrand:

I’ll close that item. We’ll take this to the list. If it’s appropriate 
to fix this, then we will need to issue a short I-D or ask the IAD to 
instruct the Secretariat to “send this”. Let’s make it clear what we want.

Issues raised by Todd Glassey (starting at 14h45)

Harald showed a slide with the list of issues raised by Todd Glassey. 
Jorge, Scott and Harald reviewed the issues this morning and none of 
them appear to require changes to our current documentation.

In the IETF, we try to listen to issues raised, and then address them. 
For example:

#1240: Is legal review of BCP 78 3.3 needed?

- Yes, and it was done before the document got published.

#1241: Does BCP 78 3.3.a(e) give away all rights to the IP involved?

- No. It does not do a thing about patents.

#1242: Do BCPs require different IPR procedures than other RFCs?

- It is the IETF’s business to decide what they mean

by BCP, and it’s the IETF’s business to decide what

procedures it wants, so “No”.

#1243: What are the qualifications of the Trustees of the IETF Trust?

- They are IAOC members.

#1244: How is oversight and respect going to be enforced?

- Not by the IPR working group.

#1245: Does describing a technology require a license from the people 
who originally described it?

- No. If you copy text, you need a right to copy text.

If you don’t copy text, you don't need a right to

copy. A specification, by itself, can not infringe

on a patent.

Harald asked the room if further comments were needed. The consensus was 
“no”. Harald promised to type up the resolutions (to the issues) reached 
with a lawyer, and then post them to the list to close this.

Any Other Business (starting at 15h46)

Harald Alvestrand:

What advice do we want to give to the IETF Trust on IPR issues, apart 
from the copyright issue? Does the IETF Trust need advice from the IPR 
WG? Lucy, do you need advice from us?

Lucy Lynch:

Aside from the issues that have already been talked about, one which is 
a rat’s nest is “what happens with documents that come up through the 
RFC Editor chain, outside of the IETF chain , and if that document is 
approved for publication as an RFC with our boilerplate, but the Trust 
does not choose to accept that document for some reason, what happens?” 
This is corner case and a nasty problem. I don’t have an answer.

Bob Braden:

I am one of the RFC Editors. Can you give me an example of what could 
cause this to happen?

Lucy Lynch:

I don’t know, it’s just a terrible fantasy. I can imagine something that 
is perfectly suitable as in internet document that would meet your 
qualifications that has not been through the IETF process and may in 
fact be in conflict with our process (for example, an independent 
submission related to some other standards process which infringes on 
someone else’s IPR). My only concern here is the technical format of the 
document and the distinction between that and something which is IETF 
Trust IPR. There is a confusion in the issue here.

Bob Braden:

I would have thought the IETF Trust would not have the right to refuse.

Scott Bradner:

I am not sure the IETF Trust has anything to do with independent 
submissions to the RFC Editor at the moment. Those are not IETF 
documents and therefore never had IETF copyright per se other than the 
fact they do have an ISOC copyright on them, so it is a very puzzling 
situation.

Bob Braden:

My understanding has been that all RFCs would be covered uniformly by 
the Trust. I am surprised at this question.

Ted Hardie:

This corner case seems very unlikely because the IESG reviews all 
independent submissions for conflicts with the internet standards. If 
this comes into a more concrete form, then definitely let’s consider 
this as a working group item, but until then, let’s just let this go as 
an unlikely bad fantasy.

Brian Carpenter:

As a Trustee, I have to say this is a fairly difficult question we have 
to resolve. Not because we think ISI is going to do anything bad, but 
just because we have to get legal clarity, particularly for RFCs before 
about 2200. We need to get clarity to avoid any long term legal 
consequences. As an Area Director, I think this is out of scope for the 
IPR WG

Harald Alvestrand:

Are there conditions under which the mere holding of a copyright would 
create a legal liability for the Trust? If it’s not dangerous to hold 
it, we shouldn’t refuse it.

Jorge Contreras:

I can’t think of anything off the top of my head. I suppose we might 
have an issue if someone contributed something which is obscene, but 
then the publisher would have the risk, which wouldn’t be the IETF 
Trust, but ... I haven’t considered this question at all.

Scott Bradner:

The IESG does not review April Fool’s RFCs, and some of them could 
introduce considerable liability because some people actually believe them.

Bob Braden:

I am a little puzzled why the status of pre-copyright RFCs is not a 
subject for this working group. Are they in the IETF Trust? Do you plan 
to put them in the Trust?

Lucy Lynch:

We plan to solicit donations to the Trust, including donations from 
early authors and things like the video assets from the mbone 
broadcasts. We can not say “we unilaterally own them, give them to us”.

Scott Bradner:

There is running code in this space that might be investigated. There is 
a contract that specifically talke about the ISI and ICANN arrangement 
over IANA functions, and IPR in IANA databases. I suggest Jorge look 
into that.

Harald Alvestrand:

If we want to add AOB to the IPR WG, one item would be clarifying the 
IETF’s desires on what to do about issues of copyrights with old RFCs. 
It is the business of the Trust and the lawyer to determine what CAN be 
done, but it would be nice to have an open discussion about what we want 
to be done.

Bob Braden:

I have a practical problem. The RFC Editor gets a fair number of 
copyright questions from people who want to republish some or all parts 
of RFCs. Who should I forward those questions of copyright to now? The 
IETF Trust?

Lucy Lynch:

Let’s talk! That is a good question.

Toni Paila:

Regarding IPR declarations, if a work starts under an IPR declaration on 
certain terms, and work continues and goes on, and then the declaration 
is changed later, is there any guidance the IPR WG can give here?

Scott Bradner:

I think the right answer is before the working group makes a final 
decision, it’s certainly impolite to change but it is hard to see a 
process issue. There could be some interesting issues if RFCs get 
published under one assertion of rights, and then a more restrictive 
assertion of rights is made after the RFC is published. Should we add 
something to our guidance?

Joel Halpern:

This is a swamp that each IPR holder can choose to step into (by 
changing their declarations), or not. We should leave that to them and 
their lawyers.

Jorge Contreras:

I agree, this is a quagmire. The IETF can issue guidance or a rule to 
clarify what the proper way to behave in this regard would be. That 
would be new. There has not been such a rule in the past.

Harald Alvestrand:

One of the things that we could imagine doing would be to provide a 
click-box on the IPR disclosure page saying “There grants are 
irrevocable” or “These grants may be revoked at any time.” I suspect 
this is a rathole

Scott Bradner:

To add other branches to the rathole: Could say that up until the time a 
WG makes a final decision for something to be passed on for publication, 
this would be encouraging people to make changes to rights. That could 
encourage people to wait until the last minute, I don’t think we want to 
do that.

Harald Alvestrand:

With that, I think we have closed the agenda for today. Thank you all! 
See you next time.

Done at 15h00

_______________________________________________
Ipr-wg mailing list
Ipr-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg