Intellectual Property Rights Working Group (IPR) Minutes Meeting: IETF 69, Tuesday, July 24, 2007 Location: Red Lacquer room, 1740 - 1950 US-CT Chair: Harald Alvestrand Minutes: Scott Bradner Version: 2 ================================================================== These minutes have been reformatted by HTA to follow ION-agenda-and-minutes, version of 2007-03-16. 1. Agenda bashing Agenda was approved as published: 1740: Welcome, scribe selection, agenda bashing 1750: Outgoing document: Open issues from WG Last Call - Use of MUST, SHOULD to indicate requirements - Code "used in any way desired" - more explicit text about copyleft or patent license issues? - Other issues? Hum on acceptance of the -outgoing document, with fixes as identified. 1820: Incoming document: Issues - Software licenses: How do we ensure that the IETF Trust is in a position to grant the rights desired in -outgoing, and are there cases where that is not true, but publication is desirable? - Other issues? 1850: End of meeting, unless discussion shows that the second hour is needed. 2. Resolved issues Moved issue of copyright in IDs (#1212) to open Moved issue of multiple copyrights in RFCs (#1282) to open Consensus in room that the other issues have been resolved: #1166, 1167, 1168, 1169, 1175, 1199, 1237, 1246, 1337, 1400 Consensus in the room that punted issues were reasonably punted: #1273, 1338, 1339 - all with "details left to the IETF trust". 3. Outgoing document 3.1 Issue #1499 on use of RFC 2119 terms (MUST) Brian Carpenter - brought up the topic but does not feel strongly about it David Black - what does trust think Jorge Contreras - do not know Jonne Soininen - trust does not care Brian Carpenter - I withdraw the issue The chair called consensus anyway, and the consensus in the room was to use lower case instead of RFC 2119 terms 3.1 Issue #1500 - software licensing David Black - report from corporate lawyer that the current text is not clear - David has sent suggested text to list - basically, trust should not add software licensing restrictions not already in the text. Consensus in room to add this text. 3.2 Issue #1282 - should multiple copyrights be permitted? David Black - code often comes with copyright - should preserve Scott Bradner - note that the purpose of the original text was to not permit this type of thing David Black - common way to recognize author Joel Halpren - multiple copyright leads to confusion as to usability Jorge Contreras - have concern in RFCs - need to move to situation where trust is clear about what rights the trust has - also needed if need to enforce - rather than having to get all authors together to enforce rights ?? - some places additional copyright statements might be seen as endorsing moral rights - then in conflict with what the IETF can do with code Stephen ?? - may be way to create legal language to make rights statements in code null & void David Black - any copyright should be only a one line & purpose is so that extracts will include the copyright - and that is a good thing John Klensin - a problem if we move to a model that the trust owns doc w/o also having a clear license back to authors for the published doc Jorge Contreras does not think it's an issue Scott Bradner - using a bare copyright statement to give attribution is a big gun - David Black - maybe have trust come up with a form for attribution John Klensin - bare copyright an issue Joel Halpren - people can put comments code - we do not need to have the trust do this Stephan ?? - issue came up when open source folks contribute code and want to include the open source copyright David Black - write a FAQ to say its ok Consensus call: Is it ok to have copyright statements in code in RFCs? - The consensus was no, by a count of roughly 6:1. We do encourage acknowledgement of authors, also in comments in the code, but not by putting in copyright statements. David Black - text on list was to encouragement of acknowledgements of authors in code 3.3 Issue #1212 - Copyright statements in I-Ds and RFCs Harald Alvestrand - placing copyright statements where we do not have copyright does not make sense (e.g. singe author IDs) - but some IDs that are many authors - but cannot tell difference - Jorge Contreras - any collection will have a copyright owned by authors - want trust to have copyright to be able to enforce copyright - even single author RFC because want to enforce David Black - boilerplate is IETF owned - that presents a barrier to creation of fake RFCs Stephen ?? - if no copyright in ID means that other SDO could steal and modify text - is it so important to not have copyright in IDs? Joel Halpern - agree - need to protect IDs, but collaborations are not collective works under Jorge's description John Klensin - if we believe that IDs are working documents then there is no reason to think that the IETF trust can grant rights to IDs Harald Alvestrand: proposal - do not require copyright in IDs Scott Bradner - if authors put copyright statement in ID then they cant claim that this was done w/o their agreement Brian Carpenter - proposal - maybe require statement in ID that says "if published copyright IETF Trust" Jorge Contreras - maybe "portions copyright IETF Trust" - note to Joel - collaborative work is the same Russ Housley - republished ETSI doc was very beneficial - problem comes up from time - and should be able to be done Harald Alvestrand - consensus call: We do not require "IETF Trust" copyright notices in I-Ds. We do require them in RFCs. Consensus (headcount about 12:1). 3.4 Other issues Henrik Levkowetz - Simon suggested start and end of code markers - are we discussing this? Harald Alvestrand - no 3.5 Consensus call for -outgoing readiness for IESG Harald Alvestrand - is doc ready to go to iesg if above changes made - consensus yes John Klensin - should have WGLC on incoming before closing this doc Harald Alvestrand - agree - will say issues on outgoing doc are in scope when last call on incoming consensus - no known issues, but take it to the list. 4 Incoming rights document 4.1 Software licenses David Black - problem with software licenses when it conflicts with licenses grants specified in -incoming, there will be exceptions and RFC 2026 variance process should be used Jorge Contreras - trust has right to deal with license John Klensin - no, that right was withheld from the trust when IASA was created - don't go there Harald Alvestrand - if software license is incompatible - talk to author for a compatible grant 4.2 Should we include text to tell trust to license back to authors John Klensin - no - it needs to be part of license agreement author has when submitting Joel Halpern - -inbound can just say that the license includes the right for author to make extracts etc - i.e.' imbedded in license author gives trust - look at SPARC addendum - http://www.arl.org/sparc/author/addendum.html The room registered general support for the ideals behind the SPARC addendum, and requested that appropriate language be included in -incoming. Consensus call: should IDs have to include "if published as an RFC the text "copyright IETF Trust will be added" (exact text to be in the instructions maintained by the Trust)? Consensus - yes Consensus call: Should we permit multiple copyright statements for the whole document? Consensus to continue with current practice, which requires IAB approval. 5. Next steps please review documents and comment if you have comments The chair will hold outgoing until -incoming last call is over. The chair will then send the two to IESG together