Minutes of the IPR WG meeting, San Diego, 67th IETF, Monday, November 7, 2006 Agenda: 15:20 Administrivia --- Agenda bashing, etc. --- 5 min 15:25 Outbound Rights --- What rights the IETF grants others --- 75 min 16:40 Milestones and Goals --- What we're going to do and when, including a replacement for 3978 --- 35 min 17:15 Wrapup, next steps 17:20 End 1: Administrivia --- Agenda bashing, etc. - No agenda bashing - Elwyn Davies to take notes - Scott Bradner (SOB) does jabber 2: Outbound Rights --- What rights the IETF grants others Harald Alvestrand (HA) presents: - Considering draft-ietf-ipr-outbound-rights-01 Chairs believe this represent consensus that group can agree on Asking for issues to be raised against the documents. Big Issues: =-cite all, translate, all change code ? rough consensus? John Klensin (JK): unless we get it right have to retune every few months Joel Halpern (JH): Not including legalese - so clarify what is the problem? JK: Doesn't believe we have lasting stable consensus about what we are looking for.. is it the same as we were looking for a few years ago Issue is stability of specification - we have shown that we can't get it right Expanding rights requires right to do so.. ? back to authors Scott Bradner (SB) (original issue): Change code is a bit terse HA: see draft for specific text Ted Hardie (TH): section 5.5: Attempts to move legal drafting off to somebody else but makes it difficult for legal drafters. Things about copyright are not very clear. Problems in this section are really about inbound rather than outbound--- if inbound has restrictions then may make it difficult to get to what we want on outbound.. Can we punt to inbound side? Maybe say that if inbound is unencumbered then straightforward. For encumbered punt to wg that is putting forward the code JH: View when writing draft that all code must be able to be used according to our rules-- didn't see a way to avoid this because it would involve looking at every individual case. Joel though this was consensus. TH: View that this the consensus but was not the effect of the text as written. Better if Joel put what he just said into a new version of s5.5. Need to get rid of inbound license issues. Ought to be clear that just by looking at (new) rfc can apply ietf rights .. but there might be additional rights. SOB: Agree with TH but need to be clear that it applies to new RFCs and not those that have 'no derivative rights' restriction. BC: Should we remove all material relevant to independent submissions in the draft? Is in the purview of the wg to constrain what should apply to independent submissions? JH: Doc uses IETF contributions very carefully.. claims that this sidesteps the problem Brian Carpenter (BC): Missed this but are we declaring out of scope all discussions of matters relating to independent submissions? JK: If this replaces 3978, need to be consistent about saying something/nothing about independent submissions. WG has to make its mind up about whether it is touching independent submissions. HA: Is this all issues? Extra issue: How do we handle old rfcs? Big issues list, as summarized on slide: Cite all, translate all, change code Concern: Stability of specification? Addressing stability: Need language stating how expanded rights can be granted (process) Copyright issue HA (Consensus call): Take consensus on this doc as a set of rights we would like to grant (12 for, none against, 1 confused) SOB: Need clear definition of what is code HA: How do we deal with concern of stability of specification HA: Possible to move this over to the inbound side JK: Could put text in to give authority to grant more (expanded) rights JH: How would we reach a consensus on what sort of rights we could grant JK: Problems discussed on mailing list include lots of issues with special cases.. tends to take an essentially infinite amount of time to reach a consensus SOB: Remember nobody can grant more rights than we have received HA: No it is supposed to be expanded up to what we received SOB and lawyer have been trying to write an RFC for 3978bis. involves allowing small changes to boilerplate for special cases. SOB: wanted to make clear that IETF Trust are constrained to grant only up to the available inbound rights. HA: The WG does not wish the IETF to ask for copyright transfer (but this is an inbound issue) TH: His belief is that the IETF Trust is the rights manager. Are we trying to figure out who should allowed to give them permission to grant exceptions JH: Somebody needs to be able to allow the trust to make an exception in a particular case. We need to be able either to allow the trust to be able to this of their own bat or decide who can give permission. Suggest trust be able do exceptions but blanket rights need an IETF consensus process Jonne Soininen (JS): Speaking as IETF Trustee - need a clear statement of how the trust should be instructed. Need an 'authority' behind it. Need a process Steve Bellovin: Personal take would be IESG's request JS: personally agrees with it HA: Consensus Call: Suggested text: per slide consensus: - Special cases: IETF Trust (as requested by the IESG or IAB) - Blanket rights: IETF consensus process - Yes: 14, No: 0, Don't know: 0 TH: Agrees but one point: items not approved by IESG? Eg IAB .. should we consider e.g., IAB to grant exceptions for IAB docs BC: IAB could probably grant rights for IRTF as they have authority.. need to look at IRTF doc processing doc.. could be delegated to IRTF steering group BillFenner: Could say special rights from document stream owner JH: Just say IESG or IAB SB: What about RFC editor for independent submissions? Various: This is out of scope. HA: move on to small issues.. is JH ready to write language? JH thinks he is HA: Code vs non-code? Adequate definition? BC: Suggestion: Chunks of code should be explicitly marked. Only way to document this easily SOB: Considers putting in signposts will not hold up over time.. JH has put in a list in draft JH: Considers list to be exemplary.. thinks there should be explicit labeling but doesn't like it. HA: suggested 'some obvious cases': Should avoid signposts but need to have some way to decide. BC: Could do a registry of formats deemed to be code.. alternative to signposts SB: Thinks that first sentence of 5.3 is adequate JK: Agrees with last point. Isn't keen on registry.. could copy all 'code' into a database BC: If you use 'intended' then you have to say who makes the judgment. (3 people in favour of rules, 2 in favour of markers) Stefan Wenger: Why not both in the draft? JK: Do both as appropriate (use rules by default but can mark if no clear) TH: Both case: If somebody didn't put something in that matched the rules and didn't mark it then it isn't code. JH: thinks both s a good thing. Avoids judgment call on borderline cases. Only have to maintain the rules.. can put in code markers (as an author) Concensus to go with both. HA: New issue: How to handle "no derivative works" RFCs SOB: Need to explicitly say that code cannot be extracted from no derivative works, maybe. BC: Puzzled. Technically they could be AD sponsored, not just independent submissions. TH: Treat no derivative works as equivalent to 'no code' throughout. JH: Add note to s4 that because of inbound rights .. we don't get any from "no derivative works" docs so can't make any grants of outbound. HA: this is now an inbound rights issue. HA: Do we mention independent submissions? (silence) assume therefore consensus not to. HA: New (small) issue - Section 5.5 may be too specific for stating for consensus of IETF JH: Allowing people to put in extra notices doesn't reflect IETF desires.. can't punt on this one TH: If a wg has allowed code that would not allow the outbound rights we want.. then the wg should have done exception processing. HA: suggest new words: We wish to make it clear that the user of an IETF document have the rights they expect (what we want to give). Leave out stuff about extra copyrights. BC: can't do this because of 3978.. this isn't just inbound rights so we can't just punt on it What is the minimum we can say to avoid getting into a conundrum later. We probaly need to say that docs should not contain any text that distorts the outbound rights (to code) we wish to grant. SOB: 5.5 is not specific to code. Otherwise good. May need to have some statements in inbound rights because this is a denial of right to put in some statements. JK: maybe s/distorts/defeat or restricts/ JK: Some of this may be handled by putting in text to stop something overriding our intentions Slide text: There have been contexts where the material in an IETF contribution is also available under other license terms. The IETF wishes to be able to include content which is available under such licenses. It is desirable to indicate in the IETF contribution that other licenses are available. However, the IETF does not wish to have IETF Contributions contain additional copyright notices and licenses, as that introduces a number of additional difficulties. Providing the correct legal approach to such indications is left to the IASA, as all legal language is. HA: how to handle old RFCs? BC: has an idea.. put in a statement sent to trust to do the best they can do HA: .. to get equivalent rights to the best extent that they can SOB: 1 Draft needs an explicit effective date 2. Several classes - ancient history up to 2026, middle - need to ask authors, new ones controlled by new doc. Trust needs to negotiate with ISI about ancient history as a best effort. JK: Jon Postel was of the opinion generally that reproducing old docs in toto was not a problem but anything else is a gray area. JS: Trust is trying its best already. Need not say it! BC: Ought to say it anyway although it's a no-op HA: Believes we have covered all issues.. JH instructed to make new version New agenda topic: Milestones and Goals --- What we're going to do and when, including a replacement for 3978 HA: Two sections: philosophy (written by SOB), boilerplate (written by Jorge Contreras) Intention is that IETF ought to be able to approve minor changes consistent with philosophical goals to handle special cases and minor errors. JK: How is minor defined? Would decisions be appealable? SB: If it is not obvious, its not minor.. but this is tricky BC: How do we engineer appeals mechanism? HA: How do we maintain 'no derivative works' RFCs? We permit publication of such docs but doesn't understand what that means! SOB: Original aims: Allows company to publish how a thing works but not build standards etc out of it. The intent was that pieces could be copied JH: "No derivative" works are effectively not really IETF contributions.. so maybe disallow them. SOB: Disagree: Some docs (eg NFS) are background or starting point material. You can't alter that but you could alter it and use it as you will. Not a good idea to stop this. TH: Believes that if somebody came to IETF with some material that they publish as a no derivative works doc but then go on and modify it - this is a good thing. Expects that this will be rare. If something comes along that would eventually break outbound rights then need to start exception process asap. JH: Can't see how it will work? JK: What JH said come close to line between copyright and concepts that the words describe. JK: Note they are external docs.. might be able to get the lawyers to draft something that distinguishes between docs from external sources and documents built within the IETF process. HA: Consensus call: The function of providing publication of outside documents with a NDW clause is useful, and should continue. Yes: 9, No: 1, Don't know: 0 BC: Why did Barry vote no? Barry Leiba: Different view of how IETF should handle IPR and how his company should handle these issues. Not very certain. HA: If you can express it better, please send to mailing list. HA: (More timeline.) - December: Revised -- outbound, WG Last Call - January: Resolve issues, -outbound to IESG - January: 1st draft of 3978bis - March: Discuss 3978bis in Prague - April: WG Last Call on 3978bis - May: Resolve issues, 3978bis to IESG - June: Close WG - No need to meet in Chicago?????? Thank you all for coming, see you in Prague.