Intellectual Property Rights WG (IPR) Minutes Meeting: IETF72, Thursday, 31 July 2008 Location: Rathcoole room, Dublin Chair: Harald Alvestrand Minutes: Mirjam Kuehne Version: 1.2 =========================================================== 1. Agenda bashing Stephan Wenger would like to discuss e-mail list moderation at the end of the meeting. 2. Jorge Contreras: IPR WG - current structure (RFC3978 + 4748) - the diagram shows what the IP flow structure is today - the circles on the top are contributors (emails, submissions, personal discussions in WGs etc.) - the square boxes are licensed rights for IETF standards work The output is the RFC series If someone wants to use a contribution not part of the IETF process, then the IETF trust and the community don't have the rights to use them. There was an example where the IEEE wanted to use IETF standards and use it as their standards. Even if that is agreed and wished by the IETF it is difficult to grant those rights to third parties outside the IETF. There is a new process: incoming and outcoming RFC That new procedure would allow the IETF to grant rights to organizations and entities outside the IETF. Current document: IETF Trust Legal Provisions: "outbound" license terms: - IETF standards terms - Code Extracts - BSD License - Non-IETF Uses Effect: - Pre-Existing documents - Amendments Required Document Boilerplate: - Copyright notice - Derivative works Legal Terms Applicable to all IETF ddocuments Jorge goes through the document and recent changes and comments made to the document (see pointer to document) 1. Background, no changes 2. License to IETF Documents The intro sentence talks about that this document only applies to IETF Documents published after the publication of the RFC. Bill Fenner suggests to use 'approve' instead of 'published' Scott Bradner: why not just 'document'? Why mention 'IETF document'? Jorge: the original was 'publication of the incoming RFC' Harald: thought we had agreed that the Trust sets a date and this would be the effective date on that document. Harald reads text. Jorge: sounds circular. Harald: RFC is published and then the trust sets a date. Bill Fenner: past confusion when new procedures where approved and applied as soon as the document was ready even before the document was published as RFC (that was more a problem when the RFC editor had a longer backlog). Ted Hardie: maybe one could say something like: 5 days after approval. Scott suggests to put a date up in the document Stephan Wenger: 'the publication' in that document and then behind the scenes work... (?) a. Important to note that it mentions 'copyrights'. This is NOT about patents. Patents are not licensed at all. i. 'IETF Contributions' has beeen added Scott suggests to also change that in the caption. ii. 'IETF Contributions' has beeen added Scott Brim: Is translation really part of the standards process? Scott Bradner: yes, has always been part of it from the first time the IETF wrote down anything. Joel Halpern: the way it is worded that you can only translate it as part of the standards process Jorge: translation is also allowed outside the standards process. Scott Bradner: does it really have to be in both (inside and outside the standards process)? Can't it just be said once to cover both? iii. no changes Scott Bradner: derivative works should be explicitly based on I-Ds, not e-mails Harald: would disagree with that. Because huge sections of I-Ds are sometimes copied out of e-mail messages. Jorge: in section 6 it lists explicitly I-Ds. Harald: suggests to add contributions to this section Scott Bradner: but then there is no reason to also say I-Ds Jorge: logically correct, but maybe should be explicit Scott Bradner: it is a missing component, but it has always been missing. Not sure what the right answer is, but it should be recognised that this is missing. Jorge: should a contributor be allowed to say: that something in an email can be used, but not changed? is this important to make explicit? This will go to the list for further disucussion. b. There was some discussion around term 'IETF Standards Process' There was also discussions about archiving documents, incl. I-Ds. The agreement was that yes archiving is legitimate and even required. Scott brought up the issue of mirror sites. Some people do have a problem with that. Some authors have requested that I-Ds are taken down from mirror sites. But mirror sites have always existed - with or without agreement and knowledge of the IETF. Scott: expired I-Ds are removed from the IETF's secretariat web site (they are still on other web sites, including the IETF Tools page). It actually says currently: 'removed from the Internet-Drafts repository' Stephan: the old paper procedures had copies of I-Ds in them, so it is indeed an illusion that I-Ds will completely go away. c. i. Jorge added 'document' after RFCs Scott Bradner: suggests to add 'contributions and RFCs' Ted Hardie: When he read 'incoming', he did not get the fact that if someone produces a code snippet to prove a point in a mail message, would by that grant the right to the IETF. Scott Bradner: good point. Maybe not for text, but for code fragments. Harald: suggests to leave the contributions out, and deal with it later. Joel: what outbound says: was asked to make it 'contributions' (was 'document' before). Scott: doesn't agree with Harald that we can wait. We do have archives of mailing lists today. So, we cannot wait. Jorge changes text to: Contributions and Documents Stephan: ... not sure what he said... something about noting well in an email message that the following code snippet is only included to prove the point etc. Russ: what if you say: I put my code snippet over there (not in that mail)... does that make it different? Ted: are we sure that this reference is not covered? Jorge: reads RFC: in that case it would be 'intended to be included in an I-D or RFC' John Klensin: if what you said is 'look over there' that is part of the contribution, but not the stuff that is actually placed there. Harald: in order to shorten that discussion: Please consider the following case: "There is an article in the Newspaper today that proofs my point." That does not mean the IETF has the rights to that Newspaper. That means inclusion by reference does not work. iii. to copy, publish .... some additions under (y) Scott Bradner: this only refers to RFCs, not I-Ds. Jorge: thought it was only RFCs that should be extracted from the IETF. John Klensin: thinks that this phrase was explicitly intended that way. Maybe the text should be strengthened to say: RFCs, but not other contributions. Scott Bradner: this should go into the next section (d) Harald: is wrong, thinks is in conflict with outbound. The parathesis in iii. can be removed. Scott: agrees with removing the paranthesis. Scott: under (x): just wants to make sure that this doesn't mean that it need to be attributed with each slide or message etc. Jorge: understood. And agrees with Harald's point on the conflict with the outbound documents. John Klensin: if you want to kill the open standards process, the way to do it is to insist that everything is said in the IETF, is open season. Scott Bradner: people do grab stuff from mailing lists and post it to other lists or other standards bodies. Understands John's point but not sure how to address this. John: when has the outbounds document been published by the RFC editor? Russ: not yet published d. what licenses are NOT granted i. Scott Bradner: needs some words smithing to make it clearer. ii. Scott Bradner: assumes that this is going away? Jorge: yes, d.ii. is being removed already covered a lot in the discussion above iii. e. f. Termination Ted: why are we insisting that the IETF can terminate those licenses? If someone has already copied the email entry or I-D in accordance with this license, terminating it seems futile. Scott: let's assume we want to stop someone doing something evil and therefore terminate the license, this should not be applied to the IETF. Suggestst to explicitly refer to 2.c. in that section (not entire 2) Ted: where in outbound did we ask you to do this? Jorge: outbound was not intended to be complete document, this one is much longer and complete now. Ted: if this gives us the rigths to terminate the rights, this will create screaming. This section should be removed. Should be perpetual inbound and perpetual outbound rights. Consensus to remove section f. Scott: we do have a problem: from time to time other standards bodies take I-Ds and publish them as their standards (even though this is unfinished IETF work). This created pain in the past. We usually say: we do not have the right to allow you to do this. You have to go and ask the authors. Jorge: any bright ideas how to solve this? no resolution, let's move on 3. License to Code Components Joel: explicitly said there has to be such a mechanism. We left it to Jorge to figure out how to do this best , but this is not something you can punt. Jorge: made many suggestions, none of them were accepted on the list Joel: let's just pick a label and put it in the document Scott Bradner: why is there a list in this doc rather than pointing to as list somewhere else (a maintenance place). Ray: believes this has been agreed. reads out the agreed text ('code begins' <> 'code ends'). Was in an earlier version of the text. (draft 7/17/08) Harald: this should say: in addition to these things, anything that is between those labels, is considered as code and will be licensed as code. Stephan: Is pseudo code code? No? Then it should be taken out. Bill Fenner: re. Harald's point: concerned to add more boilerplates than necessary. Joel: re. Scott's earlier comment: the outbound document says: 'maintain this list in an easily accessible and maintainable place.' agreed to include a URL in the document pointing to a list. b. Ray: the copyright note needs to be changed to say: ....? Bill: we expect those words to go literally into the copyright note in the file? believes this has to say "This comes from RFCxyz". Scott: thinks this is right. Stephan: is reference to the RFC sufficient? Or should it also applied to I-Ds and other contributions? Harald: yes, true. Should say 'contributions and other documents' Scott: attributions need to be covered elsewhere. Ted: just re-read the outbound document. Doesn't think that can be made true for all contributions. What if someone made a contribution fully noting that this was gpl? Or am I misreading outbound? Joel: intention of the outbound is that this applies to all contributions. Consensus on the gpl subject: no change in text needed 4. Applicability of this Document additional section d. Scott: still not clear enough. If a doc is in a final form, and that happens after the effective date, then it should be effective anyway. Otherwise it can be that an I-D is not subject to this, but the RFC that comes out of that I-D, is? And make it 30 days instead of 10 days. Jorge: yes, that can happen. Needs to be made clearer in the document. Harald: let's continue this discussion on the list. Stephan has suggestions how to fix this. Will post to the list. 6. Scott: we need to be clear about this: what if the boiler plate changes between publication of I-D and RFC etc. 7. Boilerplate e. is new This is related to translation. Definitive version of a document is the one published by the auspices of the IETF. John: when this boilerplate is formatted in fixed line length, how long is it? Harald: the pointer is 7 lines. John: anticipating that there will be situations where the pointer will not be sufficient. Bill: the actual text is 48 lines. John: that is ok then. Bill: re. 6a. Suggests to include 'on the first page' on top of 6 and not in 6a. Has also some minor nits, but can do this on the list. Jorge: The text in 6 needs to be conspicuous. Ted: (not sure what his question was, but Jorge answered): Jorge: every contribution you make is subject to BCP 78 Lucy: point of process: Henrik has some comments on another section of the document. Stefan: what happens once the ipr wg closes down. Suggests to either ban a certain person from the mailing list all together or alternatively appoint moderators for the ipr list or in the worst case close the list. But believes we will need the list even after the wg closes down. John: permanently banning a person from a list, is a very heavy and expensive step. Ignore the person, don't reply. Stefan: not replying is wishful thinking. People will reply eventually. This is not a solution. Volunteers to moderates the list for a year. But he wants to have this problem addressed. Russ thanks everyone who has worked through this problem. There is an appeal underway from that person at the moment. So, we have to deal with it somehow. The chair ended the session expressing the hope (again) that this would be the last meeting of the working group.