Last Modified: 2005-02-04
| Done | 1st draft of updated IPR BCP document on documents - documenting existing practice | |
| Done | 1st draft of updated IPR BCP document on technology - documenting existing practice | |
| Done | 1st draft of IPR guidance document | |
| Done | 2nd draft of updated IPR BCP document on documents | |
| Done | List of issues that need to be discussed while revising the documents | |
| Done | 2nd draft of updated IPR BCP document on technology | |
| Done | 2nd draft of IPR guidance document | |
| Done | IPR BCP document on documents sent to IETF Last Call | |
| Done | IPR BCP document on technology sent to IETF Last Call | |
| Done | IPR guidance document submitted to IESG for publication | |
| Oct 04 | Conclude WG. |
| RFC | Status | Title |
|---|---|---|
| RFC3667 | BCP | IETF Rights in Contributions |
| RFC3668 | BCP | Intellectual Property Rights in IETF Technology |
| RFC3669 | I | Guidelines for Working Groups on Intellectual Property Issues |
| RFC3905 | I | A Template for IETF Patent Disclosures and Licensing Declarations |
| RFC3978 | BCP | IETF Rights in Contributions |
|
IPR
IETF-62 Steve Bellovin cannot be here. Scott Brim chaired this meeting. Changes to agenda. The charter discussion was put off to the end, after the issues that might require rechartering. draft-ietf-ipr-trademarks-00.txt (Bradner) ------------------------------------------ For people who work for owners of trademarks, etc. Not targeted at third parties. Proposals: optionally can add them, but leave out the statement "xxx is a trademark of yyy". Not required (not sales literature). Reasons to allow: Some authors do want to make it clear and claim a particular mark. Can be useful if mark generally unknown. Reason for no attribution is explained in RFC 3668, Section 11. We don't want the reader to think IETF takes a position on a claim Reasons not to allow: Legally, may not be required, therefore, why bother? Mixed message, not sure who it belongs to. Questionable legal status of ASCII (parentheses, TM, parentheses). Harald Alvestrand: "their own" is incorrect -- SOB will fix. You or your employer etc. Jorge Contreras: They are not required in IETF documents. You can use other people's trademarks. This is not sales literature. Using trademarked names without (tm) would not be an infringement. It is required if you own the trademark and you want to enforce a trademark. Chris Lonvick presents SSH case: TM not disclosed, but notice was given in the WG and is noted in an RFC. Bill Sommerfeld: the WG wants to give the TM owner credit. Jeff Altman suggests changing "their" claim to "a" claim. (Agreed.) Scott Brim: what if someone puts "TM" in a draft and never discloses? Scott Bradner: that's okay. Jeff Altman: What if a document gets a new editor, and the new editor owns a trademark that was originally mentioned in the doc? Scott Bradner says this isn't a MUST. New editor is not required to add (TM). Jeff: if you allow (tm) etc in an RFC, it means some person, not specified, has some rights. Then 20 years from now I will wonder who that might be and have difficulty finding out. Jeff: leave out the issue of who is author/editor. Just say that TMs may be noted. Harald Alvestrand and Bill Sommerfeld: "can file" implies a modification to RFC 3668 (3979) on disclosure rules for IPR ("must"). Harald suggests requiring no disclosure, and saying if attribution does not require disclosure. Bill Sommerfeld: 3667 3.4e says all contributors must designate all personally known trademarks. Bradner: that was a mistake. Harald: this policy makes a link between an individual and the individual's company that holds intellectual property. Thinks it's a small hole but it is in the bottom of the ship. Bradner: there are already holes. Harald: thinks should not require disclosure of trademarks at all, and allow inclusion of sentence in drafts. Lots of support for anyone putting trademarks in drafts, and give attribution. 3667's inclusion of third party inclusion of TM/SM/R was an accident. Intent was to say that you can file a disclosure for a trademark. Brian Carpenter: It says "contributor" has to disclose TM etc ... but in 3979 we defined "contribution" to be anything, including someone speaking at mike. That needs to be fixed. Yes. Jeff Altman: no text goes into the wg document without the consensus of the group. If a particular contributor inserts text, and the group did not agree, then the text would not go into document Ron Kopiter?: the text you have refers to a specific definition for contributor. I know that IBM pays my salary and that IBM is a trademark, does that mean I have to put TM all over the document. This text does not tell me what to do. Scott Bradner: there is specific text that says you don't have to use (TM) and (SM). 3667: when reproducing RFCs will specifically preserve TM and SM Is this a no op, 3667 is enough? Most want to do something. No one wants to limit it to just marks you own. He will revise 3667 (3978) based on guidance. Should we include attribution statement? Almost all against it. Take it to the list. draft-bradner-rfc-extracts-00.txt #1: copying (Scott Bradner) ------------------------------------------------------------- Already can with rfc-ed documents. Not allowing it for IETF docs in 3978 was an oversight. Will add to the document -- propose Section 3.3e but there should be discussion of exactly where to add it. Permission to extract was put in wrong section, given to IETF, not individual. Stefan Wenger: is "without modification" clear enough? What about fonts? Translation is okay. There are well described boundaries in copyright. Act -- needs to be clarified. Spelling changes are not allowed. Chuck Adams clarification: doesn't IETF get an irrevocable license anyway? A: for limited purposes only. General agreement that this is okay. John Klensin: we are creating a bad impression by constantly revising these RFCs. Let's get it really right this time, no more mistakes. Scott Bradner will provide revised text to the list. draft-bradner-rfc-extracts-00.txt #2: modification (Scott Bradner) ------------------------------------------------------------------ Pro: Parallelism with open source. Respond to technology rapid evolution. Better response to bugs. Con: confuses the market, ruins chances of interoperability. Outsiders and individuals given same level of authority as the IETF. It pushes the resolution of differences out to the end users and forces them to resolve them. The point of a standards group is to get together and think things out carefully and reach agreement, so that doesn't have to happen. Pre RFC 2026, extracting and modifying RFCs was permitted but nothing in the RFCs specifically stated that this was OK Klensin thinks you should permit it, but only with extreme limitations. Must include a pointer to authoritative document, all references to IETF and ISOC removed, etc. Bradner sees where this would work with open source community but what about other SDOs? Yaakov Stein: ITU does this already. Ted Lemon against it. We have ways for people to make changes to standards. If the processes are difficult, fix them. Copyright is not the issue for the open source community. Jeff Musselman: "open source"? Software is not standards. It's ok to tweak implementations -- code -- but not standards. Copying is good, modifying is not. Jorge: clarifies that author retains rights. Stephen Swingler?: In favor. It takes two years to get anything through the IETF. 3GPP needs to fix problems earlier. What they do now is refer to the RFC but publis a lot of "directives" on what to modify to make it work. Bradner suggests they could publish the "directives" as an informational RFC. Lefkowicz agrees with Klensin. Harald: agrees that we want to prevent what is stupid, but thinks we should split the problem into two parts. - Authors grant ISOC the right to permit modified works under whatever the IETF might want to do. - Then the IETF figures out the conditions under which modifications might be allowed. These two don't have to be done together. Braden: does this apply to STDs only? Bradner: No, a "standard" is something that people use as a standard. Act: change where it refers to "standards" in text. Klensin: this is a slippery slope, we might as well leap to where we're going. Suggests that if a document is on standards track, the IETF owns it completely. All rights relinquished. Alternatively, the IETF says nothing about modification, and if someone wants to do something weird, they need to speak with the author who owns the rights. Avri Doria: what about WG drafts? Klensin resists (but I don't remember what that means). Ted Lemon disagrees. He doesn't think we can create a situation in which there are no arguments, and this is too much of a step. Brian Carpenter agrees with SOB but wants to be sure our protocols are extensible and that we collaborate with other SDOs. He likes the position of "we own it and will negotiate". Should IETF get full rights to modify (all docs)? Almost all agree, only one opposed Most SDOs take all rights, author can't even republish. Altman suggests transfer of rights contingent on publication. (okay) John Klensin: other SDOs have irrevocable transfer of copyright. ANSI, ISO, IEEE etc. Copyright, not copyright license. (Chuck Adams disagrees, thinks it's a license.) Klensin: any contribution is treated as work-for-hire and never belongs to the contributor. Also once published copyright is like a journal. Someone: organizations die ... be sure that whatever rights we take, what happens to them when we die is explicit. New draft on desires for licensing terms? (open discussion) ----------------------------------------------------------- SOB: Steve Bellovin's goal was to come up with a doc that could be discussed among open source folks -- if terms looked like this, we're happy. Informational. Doesn't think we can reach that. Harald: wants to take care of FAQ-style questions like "is no license a license agreement?". Also, IETF has no opinion, thus must be informational. Jeff Musselman: Open Sofware consensus is a "nonsensical" concept. Just put together something that describes the issues. Brian Carpenter: disagrees with Harald. This would be a change of direction, with IETF getting involved in licensing terms. Can't reach consensus anyway. Willing to have "things to think about". Target is mainly disclosers but others should be interested. Jorge: can't dictate licensing. Wants ideas developed in IETF. Steve Mills: IPR attorneys don't want advice. Chuck Adams: So propose to generate "things to think about for royalty free", do it in the IETF process but only create informational. Hong Len: danger of looking like IETF guidance. Klensin: thinks it's wonderful, but don't touch it. Musselman: discussion on IPR mailing list? Lemon: same. People think IETF has position. Erik Nordmark: don't think we need change in the IETF policy. Even if we encourage documents, we can explain some of the considerations and licensing terms. It is not a policy decision, it is for information. Jorge Contreras: I have spoken to many lawyers. I think it is a risky proposition to put forth an IETF document with licensing options. I think maybe an outside group could submit a text to the IETF for informational purposes. Steve Mills: think it would be a useful document but truthfully an experienced IP attorney does not need this document. Maybe some IETF participants would feel more comfortable. Bradner: even if the result is informational, this is dangerous because it looks authoritative. No strong policy. Chuck Adams: if you were to look to develop guidelines for licensing, one other aspect that gets tied to it, then you have to think about what is the exception process. Do you throw it out? Do you have an exception route? Once you develop guidelines, you have to have a way out. Scott Brim: Not IETF guidelines. IETF informational guidelines. Hung Ling: agree with Jorge, not to have IETF get involved. I understand Steve is asking outside attorney to develop guidelines for open source. What are the implications for IETF? Scott: I don't know that Steve thought that through. He had asked for an outside attorney to do something, the attorney agreed, didn't get it done. His idea was that the attorney would send in an internet-draft. Would not be a work done by wg. Hung: don't want it done in the IETF process John Klensin: I think it is a good idea, but I think we need to articulate that it is not IETF. John Hassel: if discussion occurs on email reflector, and published as IETF document. We do not want this to be a product of the IETF. We can encourage the outside lawyer. DO NOT USE IETF PROCESS. Scott Bradner: even it a doc comes through RFC, it is IETF document. I am leary about doing that. No clear consensus in the room. Discuss it on the mailing list. Rechartering discussion Brian Carpenter: finish the milestones first. Close the working group, then can reopen. -> Bellovin. Pekka Savola: the "desires" draft would not require a new charter. Bradner: more rights does require a new charter. |