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:
-	the IPR WG is about intellectual property rights as handled by the IETF
-	it is *not* about what goes on outside the IETF
-	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

-	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 3rd 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) 
-	There was not a consensus about whether the IETF should allow 3rd 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:
-	What are we trying to accomplish with the copyright statement?
o	What is it for, and is it needed?
-	Should the document focus only on inbound rights?
o	What is the definition of inbound rights in this context?
-	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:
-	the organizational structure of IETF documents (i.e. RFCs and I-Ds are somewhat unique in how they are put together),
-	the boilerplate text on all RFCs, and
-	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:
1)	3978bis is only inbound;
2)	3978bis is inbound plus rights granted to IETF participants as they are participating in the IETF;
3)	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:
1)	I need all the rights I have independent of any claims of fair-use;
2)	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.
3)	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?  1/2 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)

"3rd 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 3rd party disclosure, the 3rd 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 3rd party disclosure, it makes no sense to ask the 3rd 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 3rd 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 3rd party disclosure was made and is on file with the Secretariat. Another example is more recent. A 3rd 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 3rd 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 "3rd party disclosures are lawsuits waiting to happen". We need to restrain our enthusiasm for getting the Secretariar involved in 3rd party disclosures. On your listed examples, I have been through something that resembles your second example where a 3rd 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 3rd 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 3rd party disclosures because we don't know what to do them, or we can say we will accept 3rd 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 3rd party disclosure and then not doing anything with it. I would strongly prefer we accept, but not mandate 3rd party disclosures. I would like to accept 3rd 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 3rd 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 3rd 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 3rd 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 3rd 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 3rd 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 3rd party disclosures.

Harald Alvestrand:
Does the room agree that if we continue to allow 3rd 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