Pre8Prob BOF – IETF Rights in Contributions before RFC5378 IETF 74 Tuesday, March 24, 2009, 13:00 – 15:00 Co-Chairs: Ed Juskevicius and Scott Bradner Sponsor: Russ Housley (General Area Director) SUMMARY of BOF OUTCOMES: ------------------------ After discussing a proposal by Brian Carpenter and Harald Alvestrand for a long term solution to the pre-5378 problem, there BOF achieved IETF concensus that: - Authors of new contributions SHOULD raise a flag when all of the text in their contribution did not come from them (where "them" means the specific listed authors of the contribution); this also cover the case where an author has changed jobs or employers and is not able to change (e.g. update) the rights granted to the IETF on previously contributed (pre-5378) text. - More discussion is needed on Brian and Harald's proposed solution to the pre-5378 bug; many people felt the proposal would create new work for authors and they questioned if the need was strong enough to justify it. Jorge Contreras confirmed that authors can use new legend text (for all new contributions affected by the pre-5378 bug) until an alternative solution is identified by the community. This legend text is specified in the most recent update of the "Trust Legal Procedures" (TLP) policy document available from the IETF Trust website at http://trustee.ietf.org/ There may (or may not) be more discussion on this after IETF74, on the IPR WG mailing list. DETAILED SUMMARY OF BOF: ------------------------ BOF Agenda: ----------- Agenda Bashing – 5 minutes BOF Scope and Goals – 10 minutes Problem Statement – 40 minutes Proposed Solution – 45 minutes Next Steps – 10 minutes Any other business – 10 minutes Adjourn BOF Scope: ---------- Charter: Not a WG forming BOF Russ Housley asked that the scope of this BOF be limited to the 'pre-5378' bug. Russ wanted the BOF to focus on as much discussion and thinking as possible on how to best resolve the bug. The bug concerns the inclusion of text from older pre-5378 RFCs in new work submitted to the IETF after November 10, 2008 (i.e. the date that RFC5378 was published). An example of the bug can be described as follows: - an author wants to include pre-5378 content in a new submission or contribution to the IETF, but - the author is not able to assert that every author of the included pre-5378 content has agreed (or would agree) to license the earlier material for use outside of the IETF Standards Process, and - the initial "boilerplate" text developed by the IETF Trustees in response to RFC5378 had no provisions for dealing with this pre-5378 problem. The IETF Discussion list archive (from October 2008 to March 2009) contains a number of messages about the bug and possible fixes. It also has pointers to a temporary work-around to the bug developed by the IETF Trustees during January 2009, and then adopted on February 15, 2009. Ed Juskevicius mentioned the IETF Trustees had recently published a very good new FAQ document which is related to the pre-5378 problem. The document is: IETF Trust Copyright Policy and Trust Legal Provisions FAQ – March 22, 2009 http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf Ed then reviewed the goals of the BOF as follows: BOF Goals: ---------- 1. Explore the scope of the "pre-5378 content in new contributions" problem identified by Sam Hartman during Q&A at the IETF 73 Administrative Plenary in November 2008 2) Understand the impact of not fixing the problem 3) Discuss the solution for a permanent fix proposed in: draft-carpenter-5378-old-text-01 4) Seek rough consensus on next steps and/or ways to move forward Problem Statement: ------------------ To begin the discussion, Ed invited Sam Hartman to introduce the problem. Sam: Hi, I'm Sam Hartman. I'd like to discuss what happens When you open a can of worms, and discover that things are a little more complicated than expected. One of the things you ask yourself is "Did we really need to get into this mess, or were we perfectly happy before?" I wanted to discuss some of the things the IPR WG was trying to accomplish and why we want to try to find a solution to this (pre-5378 problem), rather than just going back to the ways the things were done before RFC5378. The IPR WG wanted to normalize incoming rights that contributors give to the IETF Trust, so we have a lot more flexibility in the future (for example, if we want to give people permission to do things with our standards that enhance the IETF's mission, we can do so). Under the old policy, we could develop standards with our standards but that was it. If we thought it made sense to move a technology from here to the IEEE [it was hard]. That happened once. Another problem, speaking as an implementer, is that I want to be able to implement IETF standards. Sometimes that means taking C or Perl code from RFCs or MIBs, ASN.1 modules, ABNF and/or various other code elements. The point of having that code in RFCs is to be able to use it in the implementation of our standards. But implementers also need the ability to change code quickly if, for example, a security bug is discovered. If I find problems, then I need certain rights (quickly) to (have the flexibility to) meet my obligations in making or shipping a product. The IETF did not have the needed rights under our old process (before RFC5378) to give to me in cases like this. So What went wrong? I just moved jobs and my old work was owned by my previous employeer. I wanted to know what I had to do to make the assertions required by the new copyright policy [per RFC5378]. This was easy for new work, but what about all my old drafts owned by my previous employer? The IETF Trust still had all of the rights that they had before 5378, but that was now just a subset of the new rights that are needed, and I [working for my new employer] could not give the additional new rights to the Trust if I tried to progress any of my old work. So I needed to know what to do about this. I [went to the microphone during the Plenary in IETF73 and] asked about this. The answer I got was: "Hmm, that's interesting, we'll get back to you." So here we are. Ed then invited Jorge Contreras (the IETF Counsel) to provide a summary of a termporary work-around to the pre-5378 problem which the IETF Trustees put in place for the community on February 15, 2009. Jorge: Together with Scott Bradner, I am one of the people who helped put 5378 together, so hopefully together we'll help fix it. Jorge summarized the evolution of the IETF's Copyright Policy as follows: - Before 1992 there was either no copyright policy, or maybe a document that Jon Postel had - In March 1992, RFC1310 was published containing sections on IPR and Patents - In March 1994, RFC1602 updated the policy to address a case that came up - RFC2026 (published in October 1996) was the major overhaul of the IETF patent policy, and that stayed in place for the next nine years - RFC 3667 came out in early 2005, and was obsoleted a year later by RFC3978 RFC3978 was an attempt to rationalize some of the things in RFC2026 that weren't very clear. That did not last very long because bugs were identified in it, so RFC5378 was created for a number of reasons. One was to recognize the IETF Trust. The Trust was created for the purpose of holding all of the IPR that the IETF has. This does *not* mean patents, but rather copyrights, trademarks, domain names, all of the records of IETF meetings, blue sheets, the rights in IETF documents and the RFC series. The ownership of these things was unclear before the Trust was created. Now, we have a more orderly way to license out rights to people outside of the IETF process (e.g. other SDOs, text book publishers, people writing manuals outside the IETF who need to reproduce some parts of RFCs). This 'outbound' license exists in a document maintained by the IETF Trust called the Trust Legal Provisions policy (TLP). Contributors give rights to the IETF Trust through RFC5378, and rights go back out of the IETF Trust through the TLP. What else did RFC5378 do? It clarified the rights in many cases that were always assumed to exist (e.g. permitting unrestricted distribution of RFCs). On the open source front and the code front, the old license to code components was not approved by the open source community so we switched to a BSD license which anybody can use and which is recognized by the community. We got rid of most of the boilerplate text required on IETF documents. There were lots of complaints about the complex boilerplate text that sat at the back of RFCs. That boilerplate text has been moved to the TLP document, so what we have now is a pointer (in IETF documents) to the TLP. RFC5378 also created the right for the IETF Trust to grant derivative works rights outside of the IETF standards process, and that is what created the pre- 5378 bug. The previous policy (per RFC3978) only allowed deriviative works of contributions to be made in order to further the IETF standards process. There were no rights to grant deriviatives outside of the IETF standards process. The bug we created in RFC5378 and the first version of the TLP was that we were requiring authors to give more rights to the IETF Trust than they (in some cases) could give. The IETF Trust published a workaround to the bug in an update to the TLP on February 15, 2009. Previously, the TLP had two different sets of legend text that could limit the right to make deriviative works. Now we have a third legend that authors can use to identify contributions with content for which full RFC5378 rights may not have been granted (to the Trust). If this new legend appears on a document, the Trust can not authorize somebody to make deriviative works of that document outside the IETF standards process. Question from Jonathan Claridge: I am wondering if some of the works of protocol verifiction or test vendors would fall under this and if people would have to ask for the right to build their test software because they used statements from protocol standards in documentation of their protocol suites. Scott Bradner: This issue of using an extract from a RFC in a piece of documentation was brought up recently. The older documents in theory don't have that right but in practice no one has argued about it to date. Jorge: This problem may be fixed by RFC5378 once we get over the bug. Harald Alvestrand: Jorge, in your opinion, for pre-5378 documents, can I use the code in those documents or not, outside of the IETF process? Jorge: Yes. RFC2026 is pretty liberal, and 3978 does have a special code license albeit not exactly in the right format to allow porting the code into open source programs. Harald: So do you regard the derivatives of code as something that the Trust grants and this is from 2026, but clarified? Jorge: Yes. Sam: In 3978, do I get the right to modify code I extract from an RFc in my product if I do so in a manner that is incompatible with the standard? Jorge: Yes. Section 3.3.a (E) on page 6 of RFC3978 was intended as a free-use license. It says you can: "extract, copy, publish, display, distribute, modify and incorporate into other works, for any purpose (and not limited to use within the IETF Standards Process) any executable code or code fragments that are included in any IETF Document ..." with a stipulation that some additional notices from Section 5 of 3978 are included. Stephan Wenger: Didn't Simon Josefsson mention the restrictions in Section 5 are the trouble? Brian Carpenter: Section 5 says that certain notices have to be included and we believe that was a problem that some open source licenses didn't like. We believe this may have been GPL-incompatible, because (they) don't like having to include notices that they did not write. Jorge: The real issue we are dealing with today (with the bug in 5378) is a text issue, not a code issue. IETF does treat code and text differently. Proposed Solution: ------------------ The next portion of the BOF consisted of a presentation by Brian Carpenter, on proposed solution to the pre-5378 bug as described in the following I-D: "Including text under former copyright conditions", Brian Carpenter, Harald Alvestrand, March 2009 Brian: This may be my "abestsos-suit moment of the week" so don't be shy when we get to the microphone. By the way, nothing seems to be permanent, so let's call this a proposed 'long-term' solution instead of a 'permanent' one. The assumptions that I'm making are that the solution is only addressing the fact that RFC5378 is not retroactive, because we overlooked the need for that in the IPR WG. There is no change in anything that we are proposing about re- use of RFCs. Those traditional assumptions may not be very well documented but the intention is not to change them. The pre-5378 issue arises when earlier contributors have not agreed to the new conditions of RFC5378. A typical case is where the original authors of an earlier RFC are no longer active in the IETF or you can't find them to get their permission to use their work in your new work. The aim of the proposed solution is to keep things as simple as possible, especially for authors. The solution is structured as a draft BCP that would update RFC5378, so that we wouldn't have to touch the text in 5378 itself. Harald and I believe that the simplest thing to do, when necessary, is to be able to say "Here Be Dragons!" A 'Dragon' is a piece of text included in a new contribution without the previous author's permission to put it under the new rules of RFC5378. It does not matter why you have not gotten permission (e.g. because you can't find the original authors, or they don't reply to your e-mails, or because they died). To illustrate the proposed solution, let's say Alice is writing a draft. If her text includes pre-5378 material written by Bob before (the publication of RFC5378 on) November 10, 2008, then Alice needs to do some things. The first is to list Bob's contributions in her draft. Olaf Kolkman: Does Alice need to indicate which text in her new contribution is from Bob's earlier work? In much detail? Brian: That is an interesting question. In some cases, Bob may have written Chapter 3 of the document, and it would be easy to say that. In other cases it could be absolutely non-trivial (e.g. because Bob wrote every second sentence in the whole document). Scott: Under the current rules, Alice just needs to list Bob as a contributor without saying which of the text was his. Under this new proposal, that may be more valuable. Brian: My opinion is Alice should make a reasonable effort to provide details. Andy Malis: What if you are updating an RFC to move it along the standards process, and you can't figure out who the author of some of the text was? Brian: I have a slide on that later on. Alex Mayrhofer: Is it good enough if someone's name is on an attendee list of an IETF meeting after November 10th, 2008? Brian: To my mind, the answer is "No". The person may not have attended the right working group, or he may have worked for a different employer at the time. Brian: Getting back to the proposed solution, if Alice does have some of Bob's text in her contribution, then she must do some things. One is to list it in the Acknowledgements. Next, Alice should look for Bob's name in a register (which we would need to create) of people who have given permission to re-use their work under the new rules of RFC5378. If Bob's name, or the old RFC that Alice took text from is in the register, then she would be OK and could continue. If that condition is not met, then Alice should write to Bob to ask if he agrees to the current IETF rules. If he agrees in a reasonable time, then Alice would be OK. If Bob does not agree (or if he does not reply in a reasonable amount of time), then Alice would need to say "Here Be a Dragon." Tim Shepard: What if Bob changed employers after writing his earlier work? In a sense, he would cease to be Bob, and instead become Bob-prime. Brian: That could easily end-up in another case where "Here Be a Dragon" would apply. That would not be a disaster. It would just mean an extra paragraph of text in your draft. Sean Turner: I have a question about the register. Who is responsible to input Bob's reply to Alice (if he does respond) into the register? Should Alice do that, or do you think Bob will? Brian: If Bob has not participated in the IETF in many years, it is unlikely he would do it. Sean: I am writing two 'bis' documents now that have roughly 12 editors from 50 different companies. It's going to be impossible if I have to input [on behalf of all those people into a Register]. Jorge: The Register would not just be for RFCs. Some RFCs are in the public domain. The most problematic cases would be Internet-Drafts. Brian: We need to keep in mind that anything I say at a microphone during a WG meeting, if it winds up in a draft, would also constitute a contribution. That is why we need to think about what is reasonable. The idea is to make the register compulsory, but as common-sense reasonable as possible. The IESG would have to satisfy itself that the process proposed in our draft has been executed, before publication of RFCs. Barry Leiba: Are all of these (last four) points "AND" conditions? Brian: Yes. Olaf: My question is how much would this new process gate the speed at which we can do our work? Brian: I will cover that when I get to my final slide. Brian: Assuming we adopt this solution, I have proposed some FAQs. For example, what if we don't know the original source of some text? Should the submitter be required to identify where the text was copied from? What is a reasonable effort? I believe that sending an e-mail to a contact address that you have is a reasonable effort. Anything beyond that would be entirely voluntary. I did this for another draft, and I got replies from the authors in a few days. Who should make a reasonable effort? Anyone in the team. It doesn't have to be the actual document editor. How to document permissions that are received? Just forward the e-mail to the register (which may need some technology to make this smooth and easy for everyone). That's the end of my presentation. Let's now get into some discussion. I have a couple of questions to start. The first is "Is it OK to ignore things of uncertain or unknown original, or should we automatically red flag those? I think it could work either way, although we might need some best practice for it. My second question is "Is it reasonable to require this much reasonable effort?", or should we say it is a SHOULD or a MAY rather than a MUST. Discussion: ----------- John Klensin: I think your second question is the key issue here. I have been the editor of a large number of documents in the IETF and I have had a great deal of difficulty tracking "who said what" at which time. When the issues are contentious enough, it is an immense amount of work to track that. This (proposed solution) is potentially a great deal of work, spread across many documents from which no one will ever care to extract text. We are also in a situation where in these difficult economic times it may be hard to get people to take responsibility for editing major documents. Adding any burden to that job which is not strictly necessary will make it harder to find editors. I have yet to hear an argument that we have a strong and compelling need to do this. I would be OK if you turned this (proposed solution) into a MAY for the people who want to try contacting previous authors about their pre-5378 work. I think anything stronger than MAY would be a mistake for the IETF. Thomas Narten: I agree entirely with what John said. Is it OK to simply ignore contributions of unknown origin? I do not want to be in the position to have this burden. I would not be comfortable asserting this in a legal sense. I am also worried with the IESG being tasked to make sure that I (as a document author) took adequate steps to do this. If you are going to do this, leave it as a MAY or a SHOULD. Brian: Would you be OK with requiring the (Dragon) disclaimer being mentioned in a document's last call? Thomas: I think it's overkill. The original reason for doing this was to allow derivative rights to transfer documents to other standards bodies. That has happened so infrequently that I don't know that the cost of this is worth the gain. If there are other cases where we'd need this, I would welcome seeing a more concrete set of examples of where we need this. Brian: I think there are lots of cases where bits of RFCs appear in text books and product manuals. Scott: Until the latest go-around [publication of RFC5378] there never was an explicit permission for people to take text from an RFc to put on a help page, as an example. Thomas: My third (and last) question is "Don't we have this exact problem for documents in hold in AUTH 48?" If so, why are we only talking about I-Ds? Why are we not talking about solving that problem as well? Sam Hartman: I think I disagree with John and Thomas. I think we need a transition. As Foo approaches infinity, we need more and more of a transition to the new rules. For example, we could have MAY for the first year, and SHOULD for the next few, and then MUST after that. Ultimately I want there to be incentives for people having to go through a process to get the rights they need [to grant rights to the IETF Trust under RFC5378]. I think the IPR WG and the community had a concensus to do this, and we should support it. I am also here to disagree with Brian, because I think his proposal would make things harder for authors. For example, an author may believe something is a joint work under copyright law and therefore he or she does not need to ask anyone for permission to grant all of the rights the IETF needs in 5378. You should not make me do extra work to warrant things that I may already be willing to warrant to the IETF Trust. I think the proposed solution should be phrased so that the register would help answer if there are rights I need from Bob (in the register) versus just "Is Bob's name in the register?" Under U.S. law, you only need the permission of one of the authors of a joint work, not all of them. Pete Resnick: I just opened RFC5322, which was the follow-on to RFC2822. My work process when I worked on both of those documents was that when people made good comments on the mailing list, I pasted them into the drafts. At the end of the process, I got all of the names of everyone who ever contributed anything (all 148 of them) and I pasted them all into the Acknoledgements section. There is no value for "reasonable" where I am going to go and tell you any of those people have given any permission whatsoever to do anything. For any derivative work of 2822 or 5322, I will instantly put in the "I don't know" text. It may be that RFC5322 is a joint work, but here is the problem. I don't think that editors should be responsible for making any of these legal decisions. These are decisions that the IETF Trust should assume, because the Trust wants to grant rights to someone else. If the Trust wants to go ask all 148 people who contributed to my documents, I would be fine with that. I would like the procedure to be simple. Anytime that you are using content from before 5378 and when you don't know that all of the permissions needed by 5378 have been granted, then apply the "I don't know" clause on the new contribtution. If the Trust needs to grant rights, let the Trust do the work to get those rights. Stephan Wenger: I have four points. We should not forget we had good and valid reasons for creating RFC5378. So if we accept Pete's suggestion to put the Trust's new "I don't know text" on every new document, that would undo 5378. I don't think that is the right way forward. second, I have worked on a draft with 10 named co-authors and I know them and the companies they work for, so my risk tolerance may be different from the one that Pete suggested, so this should go into the solution. Third, there is an alternative that an editor with 148 previous contributors could take. If you 'clean-room' rewrite the document, you avoid the problem. I think I will skip my fourth point in the interests of time. Larry Rosen: I am very concerned about the proposal for a couple of important reasons. This perpetuates an illusion that the IETF Trust somehow doesn't already have all the rights it needs in order to do its work and to allow other people to do its work. The notion that there is language in this proposal that indicates that other people own copyrights that restricts the IETF Trust from doing things is, I think, an utter illusion. I am not anxious to see that illusion perpetuated. My second concern is about the strange and bizarre distinction between text and code, which has no basis in copyright law and which has no basis in the actual practicalities of writing and documenting software and which imposes an unnecessary imposition (on authors). Code is not more important than text, and text is not more important that code. I am not willing to support this proposal if it perpetuates that illusion. Third, there have been questions about whether this affects the open source community. I think in many ways it does not. Tim Polk: I would like to disagree with Sam. I am one of the authors of RFC2459 and 3280 and 5280. RFC5280 is 151 pages long. Those documents took a decade to put together and there were dozens of legitimate contributors. There is no way that I or any of the other authors is going to track everyone down. It is impractical. Instead of a slow transition to 5378, I suggest we have a glacial transition. Brian: For all documents? Tim: For anything that isn't a -00 draft started after November 10, 2008, yes. We know the new Note Well is a superset of the old one. Brian: That sounds like you are arguing for the MAY option. Tim: Yes, but only if the author is really motivated. I think anyone else is going to look at this proposal and immediately leap to the (Here Be Dragons) red flag. Harald: When I contributed a few lines to Brian's document (of the proposed solution discussed in this BOF), and therefore got listed as a co-author, I never imagined that someone would need to put into a document all of the 100 individual sentence contributors that helped create the document. My personal opinion is that whenever I cut and paste a sentence into a new context, I am creating a derived work so I own it. The rule I imagined was to document the shortest path to what is under the new rules from what was under the old rules and leave it at that. Keep it simple, have SHOULD, not MUST. Ray Pelletier: I am an IETF Trustee, and I think we ought to shift the burden from the authors to the Trust to identify where licenses are required. We have 5,000 RFCs now and 11,000 people identified as authors of those documents. We have access to an attorney, so let the Trust figure out which ones are joint works and which are collective works. With respect to having an on-line registry, I think the only entries in the registry should be the cases where we agree to transfer a document to a third party. We should not be in the business of soliciting 11,000 authors for rights that we may only give outside of the IETF in 1 in 5,000 cases. Brian: Would you change your mind if it turned out there were many cases of people using material from RFCs? For example, thousands of instances? Scott: In that case, I think the Trust should come back to the IETF community and say "Help". Bob Hinden: "Bob" would like to speak now, having been quoted a lot in this BOF. I think we may be specifying a lot of work for something that seems like a small boundary condition. If we do anything at all, I think the default should be OFF for the vast majority of authors, and we should only do this for documents we know are intended for some external use. Sam Hartman: I disagree with Pete and Ray. I absolutely can not be near a concensus that involves moving the responsibility from authors to the Trust because the Trust is going to be inherently risk-averse. I think the authors and the editors will be in a more appropriate position to make reasonable risk trade-offs, and working group chairs are in a position to find editors who will make reasonable risk trade-offs to allow documents to move forward. I also can't be near a concensus that includes not making a transition. I believe 5378 was a good idea, and we should move there. So (having) no transition or a glacial transition is not good. Russ Housley: Speaking as a Trustee here (vs. IETF Chair or Sponsoring AD), there seems to be a misperception that the Trust wants to do something on its own accord here, as opposed to an instrument of the community. It is important to understand that this is not the case. The Trust is only trying to implement what the community has asked it to do. Thomas: I want to respond to Sam. Speaking personally as a particant who happens to have an employer with a large and long legal history, it may not matter how risk-averse I am, if my employer is more risk-averse than I am. I do not have the option of deciding to take some risks; it will be decided for me. That is the risk to the IETF. Some employers may ask "Why does the IETF have such rules?" Stephan Wenger: Thomas, our rules put you on the spot to warrant that you are granting rights to the IETF Trust, so the risk is yours and only yours. Thomas: I think I would need to consult with my legal people as to whether they think they would be put at risk by my legal actions. Scott: I think many legal people would agree with Thomas that you are acting at least at some level as an agent of the company when you contribute to the IETF. Next Steps: ----------- Scott Bradner: We've had plenty of discussion today, but concensus is not something that I stumbled across. We have many options on the table: One is to support (Brian and Harald's) proposal as written (i.e. MUST). Another option is to support the proposal if modified to be SHOULD or MAY. (Note, under RFC2119, you need to have a very good reason not to do something if it is a SHOULD, versus MAY). Another suggestion was we don't need to do anything because the Trust already has the rights it needs. Olaf Kolkman: If the wording is going to be SHOULD, then somebody will have to check the reasons why it wasn't done. Who will do that? Will that be the WG chairs, or the IESG, or the Trustees, or who? Scott: It can't be the WG Chairs, because not all documents come from working groups. And we haven't talked about the collateral damage of this to the RFC Editor and the independant stream documents yet. Dave Crocker: We have a long history of doing useful work in the IETF. We need to make changes that don't break that fact. My reading of the proposal as it has been put forward is that it does break that fact. We need to make sure that any modifications take us back to being able to do useful work. Lisa Dusseault: The options are not mutually exclusive. I vote for MAY plus the Trust "can", if it ever chooses, go hunt down these permissions. Scott: I would modify the second one slightly, so that if the IETF Trust is directed by the IETF to do something, then it should do it. Scott: The last option I heard was "Let the Trust do it when the need arises." Jorge: That would imply that we just keep the work-around that the Trustees introduced (in the February 15, 2009 update to the TLP). The new legend text in the TLP allows people to put up the flag of "Here Be Dragons" and so it could stay in place for good. Scott: That is certainly possible. Another possibility is to assume we don't have the information necessary until it checked. So if the occasion arises where the IETF wants to IETF Trust to provide rights to a third party, then the IETF Trust would have to check. Marshall Eubanks: I just had a practical question about the Trust. Let's say the IEEE came to us and said they wanted to put one of our documents into their work. Would that actually impact us? Would we have to research it, even if we had risk-taking people in the IETF who said "OK"? Jorge: Yes. The IETF Trust would probably have to do an analysis as there could be many cases. Ray: The Trust itself would not make a decision to do something (e.g. hand a document off to the IEEE). The Trust is not in this "risk-averse" business. Scott: The Trust would be directed to do so, by some entity like the IESG. Harald: What if we separated this discussion into two pieces? Do we think that authors should be required to identify if they think there is a problem with pre-5378 content in their contributions, and if yes, then tell us where it came from? If the editor does not flag that there might be a problem, then the IETF Trust will have no idea it needs to do something, and if the editor does not say where the content was taken from, then the Trust will have no chance of figuring out what it is supposed to do. As someone who is likely to be quoting or taking pieces of post-5378 documents, I would definitely want to make the assertion that there is no problem in my doing this is the documents have no flags or warnings about pre-5378 content in them. Scott: OK, let's do that as a specific question. Harald has asked if we have concensus on making it so that authors MUST flag when they think there might be a problem with the source of some of the text in their contributions. A show of hands indicated we achieved concensus that authors MUST identify when they believe they might have a problem with the some of text in their contribution. Scott: Now, a second question: What is the sense of the room on the need for authors to identify the source of material in their contributions? Is it incumbent on authors to identify the source of material beyond normal attribution? Thomas: I am nervous about this question because it depends on what degree you have to identify and to how much detail. Scott: We have run out of time, and we have not reached concensus, so we'll need to continue this on the mailing list. Final comment: -------------- The IPR-WG mailing list will be used for follow-on discussion on this. The BOF adjourned at 15:00 PDT.