Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
At Mon, 12 Jan 2009 19:27:02 -0500, Ed Juskevicius wrote: Eric, Thank You for your comments and for your suggestions (below) I like your proposal for how to clarify and improve the wording of the draft legend text. Thanks. Can you advise as to when the community can expect to see a revised legend proposal from the trust that incorporates the community feedback you're receiving? Best, -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
Eric, Thank you for the careful reading and constructive suggestions. This document contains material from IETF Documents or IETF Contributions published before November 10, 2008 and, to the Contributor?s knowledge, the person(s) controlling the copyright in such material have not granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC and to translate it into languages other than English. The first problem here is the phrase and, to the Contributor's knowledge, the person(s) controlling the copyright in such material have not granted the IETF Trust the right As I read this, I am directly affirming my belief that there are copyright holders who have not granted these rights. This is all fine if I know exactly who the original copyright holders are and that they have not given permission, but the more likely case is that I don't know one way or the other, and am simply unwilling to affirm the converse. However, I am equally unwilling to affirm my knowledge and belief that the persons controlling the copyright have not made grants. I simply don't know. This text should be rewritten as: This document contains material from IETF Documents or IETF Contributions published before November 10, 2008. Some material may be subject to copyright claims for which the holders have not granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. With a little bit of wordsmithing, I think that rephrasing this sentence is fine. In addition, the final sentence Without obtaining... seems overly strong. It's phrased as if it were a condition imposed by the contributor, i.e., I the contributor doesn't license you to use this document unless you obtain adequate permission from the original copyright holders (with the contributor to be the judge of adequate, perhaps). But that's not what's in play here. Rather, it's that I the contributor can't give me license to material I don't control. So, this sentence serves as advice, not a license restriction Actually, this is not correct. The sentence *is* intended as a license restriction, not merely advice. Remember: all of this language is being included pursuant to the authority granted to the Trust under Section 5.3.c of RFC 5378, which allows a Contributor to limit the Trust's right to grant derivative works (and thus avoid non-compliance with the warranty contained in Section 5.6.c). Thus, I'm happy to discuss re-wording the sentence to make it clearer, but changing its meaning in this way would not allow the Trust to address this issue within the parameters of RFC 5378. and should be rewritten accordingly. Perhaps: Modification or creation of derivative works outside of the scope of RFC 4978 may require obtaining a license from the person(s) controlling the copyright on the relevant sections of the document. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
So what I hear (and for the benefit of others, let me note that you and I have ha a fairly detailed discussion privately that I think I am summarizing the result of) is that you want a short term solution and a long term solution. The short term solution would be adequately solved by using the 3978 options for most documents, and for documents with code, the 5378 option or a letter-or-whatever sent in parallel that was equivalent. In the long term, you would be fine with a rule that supported all existing 3978 options plus some number (one?) that said this contains code, and Am I correct? If so, the present dilemma can be resolved by - the IESG rescinding its acceptance of 5378, reinstating 3978 as the rule of the day - the IESG directing the Trust to accept legal communications (letters, PGP-signed emails, whatever) that convey the sense of the 5378 license for code-bearing documents as a temporary workaround - in the long term, the development of a 5378-bis that * accepts 3978 options as is for non-code documents and the right option for documents containing code, * treats movement of documents to other SDOs as a special case to be handled by the parties to the transaction including the trust and relevant authors etc. Close? On Jan 9, 2009, at 3:52 PM, Joel M. Halpern wrote: My own take has been that the code reuse problem is the dominant problem. Document transfer outside the IETF is sufficiently rare that I would agree with Fred that not solving that is fine. This also means that from my personal perspective, a solution that says (loosely based on a suggestion from someone else in a side conversation) that 1) If you can, you grant 5378 rights 2) If you can't, you grant the old rights, as long as there is no code in the document 3) If there is code, get the rights to the code so people can actually use the code in the RFC to implement the RFC. (MIBs are already covered, but we have lots of other kinds of code.) would seem a workable path. Yes, point 3 may hold up some work. But one could reasonably argue that such work needs to be held up so that folks can use the code we are giving them. And I fully agree that we should leave all legal wordsmithing to the trust and the lawyers. They have to do it anyway. Yours, Joel John C Klensin wrote: --On Saturday, January 10, 2009 11:07 +1300 Brian E Carpenter brian.e.carpen...@gmail.com wrote: Thanks John, I believe that is an excellent summary of the viable options. My draft implicitly adds (2.5) Post-5378 documents that incorporate pre-5378 materials whose original contributors have duly agreed are posted according to 5378 rules, with no exceptions. To my mind the main open issue is whether we want to require authors to try for (2.5) before proceeding to (2). I am all in favor of authors trying for 2.5 if they have the time and inclination although, mostly, I'd rather have them spend time on technical work (Marshall's suggestion last month that the Trust itself should take responsibility for rounding up old rights has some appeal here). What I'm opposed to is requiring authors of documents that might have had a very long history to take responsibility for claiming that they have identified all of the original contributors. My problem with 2.5, stated somewhat more aggressively than is probably desirable, is that it requires the submitter of a 2.5 document to stand up and say I have identified all of those who might claim to have rights in this document, will take responsibility for getting that identification right, and obtained their consent. There is a possible 2.5bis, which would be something like I've made a good-faith, reasonable-effort, attempt to identify everyone and have the agreements from everyone whom that process identified, but I make absolutely no warranty that I've identified everyone or that other claims won't come up; if they do, it is the user's problem, not mine. Whether that is enough different in practice from my (2) to be worth the complexity... I don't know. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
Eric, Thank You for your comments and for your suggestions (below) I like your proposal for how to clarify and improve the wording of the draft legend text. Best Regards, Ed J. -Original Message- From: trustees-boun...@ietf.org [mailto:trustees-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: January 12, 2009 6:17 PM To: Russ Housley Cc: trust...@ietf.org; ietf@ietf.org Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem Ed, I'd like to thank the Trustees for working to resolve this situation. Unfortunately, after reviewing the new text, I don't think it's really adequate. To recap, the the old text required the contributor to affirm (and consequently to verify) that adequate permissions had been obtained to publish legacy (pre-5378) material under the 5378 rules. This was impractical both because of the difficulty of obtaining such permissions and the difficulty of tracing every portion of the document. This new text, reproduced below, solves the first problem, but not the second: This document contains material from IETF Documents or IETF Contributions published before November 10, 2008 and, to the Contributor?s knowledge, the person(s) controlling the copyright in such material have not granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC and to translate it into languages other than English. The first problem here is the phrase and, to the Contributor's knowledge, the person(s) controlling the copyright in such material have not granted the IETF Trust the right As I read this, I am directly affirming my belief that there are copyright holders who have not granted these rights. This is all fine if I know exactly who the original copyright holders are and that they have not given permission, but the more likely case is that I don't know one way or the other, and am simply unwilling to affirm the converse. However, I am equally unwilling to affirm my knowledge and belief that the persons controlling the copyright have not made grants. I simply don't know. This text should be rewritten as: This document contains material from IETF Documents or IETF Contributions published before November 10, 2008. Some material may be subject to copyright claims for which the holders have not granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. In addition, the final sentence Without obtaining... seems overly strong. It's phrased as if it were a condition imposed by the contributor, i.e., I the contributor doesn't license you to use this document unless you obtain adequate permission from the original copyright holders (with the contributor to be the judge of adequate, perhaps). But that's not what's in play here. Rather, it's that I the contributor can't give me license to material I don't control. So, this sentence serves as advice, not a license restriction and should be rewritten accordingly. Perhaps: Modification or creation of derivative works outside of the scope of RFC 4978 may require obtaining a license from the person(s) controlling the copyright on the relevant sections of the document. Best, -Ekr ___ Trustees mailing list trust...@ietf.org https://www.ietf.org/mailman/listinfo/trustees ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
Theodore Tso ty...@mit.edu writes: On Sat, Jan 10, 2009 at 02:37:50PM +0100, Simon Josefsson wrote: We do have precedent for include code that has explicit open source licensing rights. For example, the MD5 implementation in RFC 1321 has an explicit BSD-style license. Sure, but under the post-RFC 2026 rules that would not be allowed since the rules do not permit additional copyright notices to be present in documents. There has been exceptions and mistakes, so there are post-RFC 2026 documents with other licensing information in them, but the IESG/IAB has also rejected including free software code in RFCs. Allowing BSD-like code to be included in RFCs would be great step forward. It is not allowed under the RFC 5378 license either, at least not generally when the code was not written by the document author. This should clearly be fixed in RFC 5378-bis, in my opinion. If the goal is to allow code to be allowed in Open Source Software, then requiring a maximally compatible OSS license for code makes sense. No, the problem of using an appropriate license has already been taken care of (the trust uses the BSD license for code-like portions). One of the remaining problems is, as described above, that the IETF license does not permit authors to take BSD licensed code and use them as illustration in RFCs because RFC 5378 does not permit additional copyright notices to be present in RFCs. A more realistic approach may be to think about how text in RFCs are used. Text often end up in free software projects as comments. This is useful and helps get the RFC implemented correctly in a more maintainable fashion. The goals of the IETF is furthered by this, I argue, so it is disappointing RFC 5378 does not solve the problem. At least in the linux kernel, quoting a 2-3 sentences of an RFC in comments is common practice, even before RFC 5378. It is also been done with great frequency in documentation, magazine articles and journals, and so on. Fair use takes care of this problem, and there I don't think even the most insanely paranoid and unreasonable corporate lawyer would think that 2-3 sentences quoted in manuals, code, etc., would be unreasonable. Certainly this is something where we have over two decades historical practice, and if anyone thinks an IETF contributor or company would be suicidially idiotic enough from a Public Relations point of view to try to sue someone for using 2-3 sentences when this would be pretty clearly fair use, and the reputations of said IETF contributor or company would be pilloried in the press, I would gently suggest that whoever is worried about is greatly disconneted from reality, if they were to think about the risks involved. I would agree with you for the 2-3 sentences scenario, but that's missing my point. I would fully disagree when it comes to 2-3 paragraphs, 2-3 pages, or entire I-D's. I believe the latter is the reality with several free software projects, including the Linux kernel. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
Let's be quite clear here. Your stated requirement for doing this was that authors had to be able to take and modify any text from anywhere in an RFC. The Working Group concluded that while that was reasonable relative to code (and we tried to give the open source community that ability relative to code), that such a wide grant was not reasonable relative to the text content of RFC. (Among other concerns, such changes would include modification of normative text and text carefully worked out by working groups to get the meanings right. If the WG got it wrong, the IETF is the place to fix it, not comments in code somewhere.) Also, it should be understood that this issue is largely orthogonal to the topic under discussion. The working group could have included what Simon asked for in 5377. The rough consensus of the WG was not to do so. A more narrow 5378 would make it harder to make such a grant, but since the working group didn't choose to do so (and personally, I think doing so would undermine much of our work) the issues seems to have no bearing on whould we rescind 5378? or is there a better transition strategy to get 5378 to apply to the bulk of our work? or how do we get 5378 rights in code, without holding up all the other documents? Yours, Joel Simon Josefsson wrote: One of the remaining problems is, as described above, that the IETF license does not permit authors to take BSD licensed code and use them as illustration in RFCs because RFC 5378 does not permit additional copyright notices to be present in RFCs. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
--On Sunday, January 11, 2009 10:28 -0500 Joel M. Halpern j...@joelhalpern.com wrote: Also, it should be understood that this issue is largely orthogonal to the topic under discussion. The working group could have included what Simon asked for in 5377. The rough consensus of the WG was not to do so. A more narrow 5378 would make it harder to make such a grant, but since the working group didn't choose to do so (and personally, I think doing so would undermine much of our work) the issues seems to have no bearing on whould we rescind 5378? or is there a better transition strategy to get 5378 to apply to the bulk of our work? or how do we get 5378 rights in code, without holding up all the other documents? One addition to Joel's remarks. Even if, as part of the medium to long-term solution to the 5378 problem, we were to return to the basic model of 2026, i.e., any rights for non-IETF use have to be worked out directly with authors, 5377 would need only a conceptually fairly minor amendment requiring that authors grant those rights at the time of document submission, rather than recommending that the Trust doing so on a licensing basis. I don't see any reason to believe that pulling out that core change in 5378 is necessary to solve the problem of what to do about old documents/ Contributions, but, even if we did... So, please, let's focus on that old document transition problem and what is necessary to make it go away efficiently, safely, and with great confidence, rather than trying to move from 5378 has a problem to this is an excuse to rehash every decision taken by the WG. Just my opinion, but... john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
On Sun, Jan 11, 2009 at 04:09:54PM +0100, Simon Josefsson wrote: I would agree with you for the 2-3 sentences scenario, but that's missing my point. I would fully disagree when it comes to 2-3 paragraphs, 2-3 pages, or entire I-D's. I believe the latter is the reality with several free software projects, including the Linux kernel. 2-3 paragraphs would probably still be fair use. I'm not aware of any place in the Linux kernel where there was more than a few paragraphs quoted from RFC's. There were a few projects that included full verbatim copies of RFC's for reference/documentation purposes, although most of those have been removed due to the fact that previous RFC permission statements were not compliant with the Open Source Definition, and so distributions such as Debian required that such full copies of the RFC had to be stripped from the source packaging. That was never the case with the Linux Kernel, however. Some Debian Free Software Fanatics are having a field day with firmware binary blobs, but not with any I-D's or RFC's as far as I am aware. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
Lawrence Rosen wrote: John Leslie wrote: I may not be the one to explain, but I _don't_ think that's what the proposal calls for. I think it calls for inclusion of the boilerplate I listed above, which simply disclaims knowledge of _whether_ all the rights of 5378 are granted (and thus derivative works outside the IETF Standards Process are not authorized by the IETF Trust). I want derivative works outside the IETF Standards Process to be authorized by the IETF Trust and see no legal reason, at least in US law, why the IETF Trust can't authorize that without even mentioning the co-authors of those RFCs. The concern expressed in this thread is whether derivative works are authorized by the co-authors of those earlier RFCs. We need no statement (admission of guilt or otherwise) about that. Users of IETF RFCs should be comfortable that at least the IETF Trust authorizes such derivative works. Which there are serious concerns about whether the Trust ever owned that IP. I.e. that the transfer of the IP to the Trust is permanently flawed by the derivatively requirement's that all derivative works be licensed under the same rights requirements' are the originals are. Certainly the term open industry standard must mean that an RFC is a cooperative expressive and technical work by individuals and companies interested in a common result. But the RFC is not an open license to use the IP for any and all purposes, i.e. that beyond publishing written copies of those IP's that the content can be used to create other IP's like Software Systems which implement that standard. We should accept the notion that IETF, and now the IETF Trust, as a public interest corporation that manages the expressive creative activities through which these joint works are written, is the joint owner of copyright in every RFC. No we shouldn't Counsel. The Trust DOES NOT OWN ANYTHING that was licensed under RFC2026 unless a separate contract was executed by those authors authorizes that change in the original licensing. The problem is that *** ANY *** derivative work which is done under a later filing but also includes component's or technology from one of those earlier filings those new filings must also track that earlier licensing. As such, a license from the IETF Trust is all we need to create derivative works, without even asking the co-authors of those old (or new) documents. I disagree. Does anyone here believe that the IETF Trust doesn't own a joint copyright interest in every RFC it publishes and can thus authorize derivative works of those RFCs? [1] yes. /Larry [1] I intentionally avoid the argument, made in my previous emails here, that we don't even need the permission of the IETF Trust to copy and modify--when necessary for functional purposes--any industry standard specification. That's a bigger argument based on 17 USC 102(b), not one based on the Copyright Act definition of joint work: A 'joint work' is a work prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole. 17 USC 101. Lawrence Rosen Rosenlaw Einschlag, a technology law firm (www.rosenlaw.com) 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243 Skype: LawrenceRosen -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John Leslie Sent: Friday, January 09, 2009 10:15 AM To: dcroc...@bbiw.net Cc: IETF Discussion Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem Dave CROCKER d...@dcrocker.net wrote: A number of the comments, so far, appear to hinge on a rather basic cost/benefit model that is clearly quite different from what the proposal is based. I suspect that difference comes from a different sense of the problem, per John Klensin's posting. Agreed. My reference to legality is based on a view of the proposal which sees it as having individual submitters essentially say I am required to get permission and I have not gotten it. That's an admission of guilt... I don't read it that way. Refer to: http://trustee.ietf.org/docs/Draft-Update-to-IETF-Trust-Legal-Provisions- 1-06-09.pdf ] ] 6. c. iii. ] ... This document contains material from IETF Documents or IETF ] Contributions published before November 10, 2008 and, to the ] Contributor's knowledge, the person(s) controlling the copyright ] in such material have not granted the IETF Trust the right to allow ] modifications of such material outside the IETF Standards Process. ] Without obtaining an adequate license from the person(s) controlling ] the copyright, this document may not be modified outside the IETF ] Standards Process, and derivative works of it may not be created ] outside the IETF Standards Process, except to format it
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
Joel M. Halpern j...@joelhalpern.com writes: Let's be quite clear here. Your stated requirement for doing this was that authors had to be able to take and modify any text from anywhere in an RFC. No, that's a different issue. Being able (as RFC author) to include code not written by IETF contributors is different from being able to modify text in an RFC (as RFC reader). The Working Group concluded that while that was reasonable relative to code (and we tried to give the open source community that ability relative to code), that such a wide grant was not reasonable relative to the text content of RFC. Alas. (Among other concerns, such changes would include modification of normative text and text carefully worked out by working groups to get the meanings right. If the WG got it wrong, the IETF is the place to fix it, not comments in code somewhere.) I obviously disagree. Users of free software need the ability to fix the source code and modify the documentation that goes along with it. The issue should of course be brought up within the IETF too, but it does not serve the IETF's goal of running a smooth Internet to make it harder for people to fix software that runs the Internet. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
Theodore Tso ty...@mit.edu writes: On Sun, Jan 11, 2009 at 04:09:54PM +0100, Simon Josefsson wrote: I would agree with you for the 2-3 sentences scenario, but that's missing my point. I would fully disagree when it comes to 2-3 paragraphs, 2-3 pages, or entire I-D's. I believe the latter is the reality with several free software projects, including the Linux kernel. 2-3 paragraphs would probably still be fair use. I'm not aware of any place in the Linux kernel where there was more than a few paragraphs quoted from RFC's. There were a few projects that included full verbatim copies of RFC's for reference/documentation purposes, although most of those have been removed due to the fact that previous RFC permission statements were not compliant with the Open Source Definition, and so distributions such as Debian required that such full copies of the RFC had to be stripped from the source packaging. As far as I can tell, current RFC permission statements are not compliant with the Open Source Definition either. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
On Fri, Jan 09, 2009 at 02:16:43PM -0800, Lawrence Rosen wrote: That's why I challenged Ted Hardie directly. Please don't take it personally or as flaming, but anyone who wants to assert a private ownership right in any copyright in any IETF RFC ought to do so now or forever hold your peace. Otherwise, I think it best that the IETF Trust exercise its rights under its joint copyright to do whatever is deemed appropriate and in the public interest, as determined by the IETF Trustees and its legal counsel, and not ask permission. /Larry are you talking about -all- IETF related documents (IDs, postings, april 1st RFCs, etc...) or RFCs that are standards? (discounting BCPs, Informational RFCs, etc) for a period of time, text like this appeared in at least a dozen documents: This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. there were even a few documents that had explicit copyright statements that excluded ISOC IETF from doing anything with the document, other than the right to publish for the period of performance for an ID, e.g. no longer than six months. one reaction to that was the promulgation of the Note Well legal advice and the path that lead us to this point. So for some IETF work product, there are/were people who assert a private ownership right in the materials they generated. I think that the IETF Trust should be very careful in using/reusing that material, esp w/o asking permission. There, I've spoken up ... reserving my right to speak now and later on this topic. (not going to forever hold my peace). --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
Joel M. Halpern j...@joelhalpern.com writes: My own take has been that the code reuse problem is the dominant problem. My interpretation has been that the problem has been (and remain) that the license on IETF documents is incompatible with free software licensing, which is counter-productive for the IETF. Document transfer outside the IETF is sufficiently rare that I would agree with Fred that not solving that is fine. I agree too. Theodore Tso ty...@mit.edu writes: This also means that from my personal perspective, a solution that says (loosely based on a suggestion from someone else in a side conversation) that 1) If you can, you grant 5378 rights 2) If you can't, you grant the old rights, as long as there is no code in the document 3) If there is code, get the rights to the code so people can actually use the code in the RFC to implement the RFC. (MIBs are already covered, but we have lots of other kinds of code.) We do have precedent for include code that has explicit open source licensing rights. For example, the MD5 implementation in RFC 1321 has an explicit BSD-style license. Sure, but under the post-RFC 2026 rules that would not be allowed since the rules do not permit additional copyright notices to be present in documents. There has been exceptions and mistakes, so there are post-RFC 2026 documents with other licensing information in them, but the IESG/IAB has also rejected including free software code in RFCs. Allowing BSD-like code to be included in RFCs would be great step forward. It is not allowed under the RFC 5378 license either, at least not generally when the code was not written by the document author. How much code is there, really? Looking at the last 10 published RFC's for material (text or code) that potentially may end up in free software implementations, I find: 5391 sample test-vectors 5393 no 5394 pseudo-code 5395 data table with messages 5396 no 5397 no 5398 no 5401 code, pseudo-code 5405 no 5407 pseudo-code This is a small sample, and you could discuss each interpretation, but still I believe this shows that this is a common enough problem to worry about. RFC 5378 improves the situation in some specific cases but does not solve the general problem, and understanding whether the specific case rules apply or not is complex. I suppose pseudo-code might be a gray area tht will depend on how paranoid of a lawyer you are dealing with. One who uses the argument that copyright can not protect ideas, just the expression of the idea, will probably say that it's OK. One who tries to draw a parallel to translations as derived works might be more concerned. A more realistic approach may be to think about how text in RFCs are used. Text often end up in free software projects as comments. This is useful and helps get the RFC implemented correctly in a more maintainable fashion. The goals of the IETF is furthered by this, I argue, so it is disappointing RFC 5378 does not solve the problem. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
On Sat, Jan 10, 2009 at 02:37:50PM +0100, Simon Josefsson wrote: We do have precedent for include code that has explicit open source licensing rights. For example, the MD5 implementation in RFC 1321 has an explicit BSD-style license. Sure, but under the post-RFC 2026 rules that would not be allowed since the rules do not permit additional copyright notices to be present in documents. There has been exceptions and mistakes, so there are post-RFC 2026 documents with other licensing information in them, but the IESG/IAB has also rejected including free software code in RFCs. Allowing BSD-like code to be included in RFCs would be great step forward. It is not allowed under the RFC 5378 license either, at least not generally when the code was not written by the document author. This should clearly be fixed in RFC 5378-bis, in my opinion. If the goal is to allow code to be allowed in Open Source Software, then requiring a maximally compatible OSS license for code makes sense. But requiring for random protocol text, especially if this is going to make reuse of older RFC's text, seems to not be a great cost/benefit tradeoff. A more realistic approach may be to think about how text in RFCs are used. Text often end up in free software projects as comments. This is useful and helps get the RFC implemented correctly in a more maintainable fashion. The goals of the IETF is furthered by this, I argue, so it is disappointing RFC 5378 does not solve the problem. At least in the linux kernel, quoting a 2-3 sentences of an RFC in comments is common practice, even before RFC 5378. It is also been done with great frequency in documentation, magazine articles and journals, and so on. Fair use takes care of this problem, and there I don't think even the most insanely paranoid and unreasonable corporate lawyer would think that 2-3 sentences quoted in manuals, code, etc., would be unreasonable. Certainly this is something where we have over two decades historical practice, and if anyone thinks an IETF contributor or company would be suicidially idiotic enough from a Public Relations point of view to try to sue someone for using 2-3 sentences when this would be pretty clearly fair use, and the reputations of said IETF contributor or company would be pilloried in the press, I would gently suggest that whoever is worried about is greatly disconneted from reality, if they were to think about the risks involved. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
Bill Manning wrote: This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. - and - So for some IETF work product, there are/were people who assert a private ownership right in the materials they generated. I think that the IETF Trust should be very careful in using/reusing that material, esp w/o asking permission. This is consistent with what I've been saying, namely that IETF RFCs are joint works of authorship. 1. The fact that IETF never previously granted the right to produce derivative works can easily be corrected by one of the joint copyright owners, in this case the IETF Trust, now granting that license. As I understand it, this is what Simon and others have been arguing for all along for the IETF out-license. 2. The IETF Trust owns a joint copyright. That also means that we can't object if the other joint copyright owners assert their own private ownership rights in the materials they generated. Who's stopping them? None of the joint owners needs to ask permission of IETF or any others to do anything they want with those jointly-owned IETF RFCs. There, I've spoken up ... reserving my right to speak now and later on this topic. (not going to forever hold my peace). Please excuse my poetic turn of phrase. As others have privately pointed out to me, it is unlikely that anyone on here will respond to my plea to declare their private claims any more than anyone does even at the worst of weddings. That is another reason why the IETF Trust asking permission to do what we wish with our own industry standards is such a futile exercise. Hardly anyone has the courage or incentive to say No and publicly declare their private ownership of our common standards. That is why we have to take the risk to do what we need to do and simply dare anyone on here to sue IETF when we allow certain kinds of derivative works. For the lawyers on here, I'm hoping that silence now, particularly by the major IETF contributors on this list, will be interpreted as laches or waiver if one of them later claims an exclusive copyright interest in any IETF RFC. /Larry -Original Message- From: Bill Manning [mailto:bmann...@isi.edu] Sent: Saturday, January 10, 2009 3:16 AM To: Lawrence Rosen Cc: 'IETF Discussion' Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem On Fri, Jan 09, 2009 at 02:16:43PM -0800, Lawrence Rosen wrote: That's why I challenged Ted Hardie directly. Please don't take it personally or as flaming, but anyone who wants to assert a private ownership right in any copyright in any IETF RFC ought to do so now or forever hold your peace. Otherwise, I think it best that the IETF Trust exercise its rights under its joint copyright to do whatever is deemed appropriate and in the public interest, as determined by the IETF Trustees and its legal counsel, and not ask permission. /Larry are you talking about -all- IETF related documents (IDs, postings, april 1st RFCs, etc...) or RFCs that are standards? (discounting BCPs, Informational RFCs, etc) for a period of time, text like this appeared in at least a dozen documents: This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. there were even a few documents that had explicit copyright statements that excluded ISOC IETF from doing anything with the document, other than the right to publish for the period of performance for an ID, e.g. no longer than six months. one reaction to that was the promulgation of the Note Well legal advice and the path that lead us to this point. So for some IETF work product, there are/were people who assert a private ownership right in the materials they generated. I think that the IETF Trust should be very careful in using/reusing that material, esp w/o asking permission. There, I've spoken up ... reserving my right to speak now and later on this topic. (not going to forever hold my peace). --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
+1 It seems to me that we are spending a great deal of energy on non-problems (including the one Ted discusses below) and too little time on real issues... like how to encourage people to do real work around here (where requiring authors try to figure out who might have contributed parts of a document that a predecessor to one they are working on and get them to sign off is not encouragement). john --On Saturday, January 10, 2009 14:10 -0500 Theodore Tso ty...@mit.edu wrote: At least in the linux kernel, quoting a 2-3 sentences of an RFC in comments is common practice, even before RFC 5378. It is also been done with great frequency in documentation, magazine articles and journals, and so on. Fair use takes care of this problem, and there I don't think even the most insanely paranoid and unreasonable corporate lawyer would think that 2-3 sentences quoted in manuals, code, etc., would be unreasonable. Certainly this is something where we have over two decades historical practice, and if anyone thinks an IETF contributor or company would be suicidially idiotic enough from a Public Relations point of view to try to sue someone for using 2-3 sentences when this would be pretty clearly fair use, and the reputations of said IETF contributor or company would be pilloried in the press, I would gently suggest that whoever is worried about is greatly disconneted from reality, if they were to think about the risks involved. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
Ted, On 2009-01-11 08:10, Theodore Tso wrote: ... If the goal is to allow code to be allowed in Open Source Software, then requiring a maximally compatible OSS license for code makes sense. But requiring for random protocol text, especially if this is going to make reuse of older RFC's text, seems to not be a great cost/benefit tradeoff. As a point of information, this was raised as an issue in the IPR WG because of cases where it makes more sense to recycle text extracts from RFCs in product documentation than to paraphrase the RFC. The consensus was to cover it in 5378. The only glitch is that we forgot to insert a transition rule for old stuff. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
--On Saturday, January 10, 2009 11:17 -0800 Lawrence Rosen lro...@rosenlaw.com wrote: ... For the lawyers on here, I'm hoping that silence now, particularly by the major IETF contributors on this list, will be interpreted as laches or waiver if one of them later claims an exclusive copyright interest in any IETF RFC. Larry, Please don't ask me to waive anything, explicitly or implicitly, without identifying who you are representing in this matter and related ones... or making a clear enough statement that you are working strictly pro bono and in your perception of the public interest to create COI or other problems should you later choose to represent some particular interest in the area. Failure to do either while pressing IETF participants to disclose what we might or might not do in the future, or waive the right to do anything by not making such a disclosure, borders on the sort of activity that has given your profession a reputation for being ethically challenged in many lay quarters (from Shakespeare's recommendation about how to dispose of the problem forward and probably much earlier). I trust that even the most creative of lawyers cannot interpret my comments above, or Bill's similar ones, as silence. While I cannot speak for anyone else, and would not try, I don't believe you can either (at least without identifying them as parties with whom you have a client-attorney relationship). Just my opinion. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
On Sat, Jan 10, 2009 at 11:17:47AM -0800, Lawrence Rosen wrote: Bill Manning wrote: This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. - and - So for some IETF work product, there are/were people who assert a private ownership right in the materials they generated. I think that the IETF Trust should be very careful in using/reusing that material, esp w/o asking permission. This is consistent with what I've been saying, namely that IETF RFCs are joint works of authorship. er... thats -NOT- what I was trying to point out. The IETF was given permission to publish an authors work but was not allowed to impune joint authorship. The IETF did not create the work - it provided a publication vehicle. 1. The fact that IETF never previously granted the right to produce derivative works can easily be corrected by one of the joint copyright owners, in this case the IETF Trust, now granting that license. As I understand it, this is what Simon and others have been arguing for all along for the IETF out-license. going forward, perhaps. retro-active, not so sure. 2. The IETF Trust owns a joint copyright. That also means that we can't object if the other joint copyright owners assert their own private ownership rights in the materials they generated. Who's stopping them? None of the joint owners needs to ask permission of IETF or any others to do anything they want with those jointly-owned IETF RFCs. I think the basis of the argument revolves around the assertion of joint ownership. ... and there are concerns with all forms of communications over IETF sanctioned/sponsored channels - e.g. the Note Well - not just the RFC series. There, I've spoken up ... reserving my right to speak now and later on this topic. (not going to forever hold my peace). Please excuse my poetic turn of phrase. As others have privately pointed out to me, it is unlikely that anyone on here will respond to my plea to declare their private claims any more than anyone does even at the worst of weddings. That is another reason why the IETF Trust asking permission to do what we wish with our own industry standards is such a futile exercise. Hardly anyone has the courage or incentive to say No and publicly declare their private ownership of our common standards. That is why we have to take the risk to do what we need to do and simply dare anyone on here to sue IETF when we allow certain kinds of derivative works. thats ok... i'm not really anyone so i am sorry for taking your statements at face value. For the lawyers on here, I'm hoping that silence now, particularly by the major IETF contributors on this list, will be interpreted as laches or waiver if one of them later claims an exclusive copyright interest in any IETF RFC. sorry - not waiving those rights to you or anyone else. --bill /Larry -Original Message- From: Bill Manning [mailto:bmann...@isi.edu] Sent: Saturday, January 10, 2009 3:16 AM To: Lawrence Rosen Cc: 'IETF Discussion' Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem On Fri, Jan 09, 2009 at 02:16:43PM -0800, Lawrence Rosen wrote: That's why I challenged Ted Hardie directly. Please don't take it personally or as flaming, but anyone who wants to assert a private ownership right in any copyright in any IETF RFC ought to do so now or forever hold your peace. Otherwise, I think it best that the IETF Trust exercise its rights under its joint copyright to do whatever is deemed appropriate and in the public interest, as determined by the IETF Trustees and its legal counsel, and not ask permission. /Larry are you talking about -all- IETF related documents (IDs, postings, april 1st RFCs, etc...) or RFCs that are standards? (discounting BCPs, Informational RFCs, etc) for a period of time, text like this appeared in at least a dozen documents: This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. there were even a few documents that had explicit copyright statements that excluded ISOC IETF from doing anything with the document, other than the right to publish for the period of performance for an ID, e.g. no longer than six months. one reaction to that was the promulgation of the Note Well legal advice and the path that lead us to this point. So for some IETF work product, there are/were people who assert a private ownership right in the materials they generated. I think that the IETF Trust
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
At 13:13 09/01/09, Brian E Carpenter wrote: On 2009-01-09 13:59, Stephen Farrell wrote: +1 to fred's proposal, let the exceptions be just that and don't bother most I-D authors, Stephen. On 8 Jan 2009, at 22:49, Fred Baker f...@cisco.com wrote: You asked me to make this comment publicly, so here it is. From my perspective, the best approach involves keeping the general case simple. The documents that have been transferred outside the IETF in the past five years is a single digit number, a tenth of a percent of all RFCs if not a smaller fraction. If that was the main problem, I would agree. But it isn't; it's the ability to allow appropriate use of extracts, including code extracts, in 3rd party documents. First, my gut feeling would be that use of ABNF and similar stuff in actual implementations might simply be considered fair use, or it may just be possible to consider implementations as part of the IETF standards process (which they very much are). The situation may be somewhat different for longer/longish pieces of code, a typical example of which might be Appendix A of http://www.ietf.org/rfc/rfc2192.txt. But the code is essentially there to serve as an example, as an additional guarantee that there is a common, shared understanding of the specification, not as a drop-in implementation. Also, such code in many instances is already covered under a more appropriate licence anyway. That potentially concerns every RFC, Given the above (some of which might be a bit out on a limb, or not), I'm still not convinced the potential issue is that big. and automatically concerns every RFC that is a new version of an older one. It isn't hard to fix in my opinion (well, I just posted a draft with the proposed fix) and I don't see that it *requires* any tool fixes. Optionally, the tools could provide a macro that expands to the disclaimer text, but cut-and-paste would work equally well. I have read your draft. I have one suggestion for modification. The text says: the person(s) controlling the copyright in such material have not granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. I think it might be more appropriate to change the person(s) to some person(s). Overall, I think currently the aspect most overlooked in the general discussion, but most relevant for somebody who would actually like to move on with publications (I'm both a WG chair with some drafts that have completed WG Last Call, but which are now in RFC 5378 limbo, and an author of some individual IDs that I'd like to update and move forward) is: WHO exactly are we supposed to get permissions from. The situation of a deceased author is a tought one, but it's an obvious one. But I haven't seen any clear answer to whether permission from all the authors/editors (the people listed in the front of the document) is sufficient, whether we have to ask everybody above a certain percentage of email contributions in the WG, everybody who's mentioned in the Acks section, or what. It's a significant nuissance for everybody to go around and beg people (maybe including for their former employer) to confirm something they probably couldn't care less, even if they otherwise think the IETF does great stuff and everything. So it would really be good to know who exactly has to be bothered, and who not. Regards,Martin. #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:due...@it.aoyama.ac.jp ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
On Jan 9, 2009, at 5:42 AM, Martin Duerst wrote: At 13:13 09/01/09, Brian E Carpenter wrote: On 2009-01-09 13:59, Stephen Farrell wrote: +1 to fred's proposal, let the exceptions be just that and don't bother most I-D authors, Stephen. On 8 Jan 2009, at 22:49, Fred Baker f...@cisco.com wrote: You asked me to make this comment publicly, so here it is. From my perspective, the best approach involves keeping the general case simple. The documents that have been transferred outside the IETF in the past five years is a single digit number, a tenth of a percent of all RFCs if not a smaller fraction. If that was the main problem, I would agree. But it isn't; it's the ability to allow appropriate use of extracts, including code extracts, in 3rd party documents. First, my gut feeling would be that use of ABNF and similar stuff in actual implementations might simply be considered fair use, or it may just be possible to consider implementations as part of the IETF standards process (which they very much are). The situation may be somewhat different for longer/longish pieces of code, a typical example of which might be Appendix A of http://www.ietf.org/rfc/rfc2192.txt. But the code is essentially there to serve as an example, as an additional guarantee that there is a common, shared understanding of the specification, not as a drop-in implementation. Also, such code in many instances is already covered under a more appropriate licence anyway. That potentially concerns every RFC, Given the above (some of which might be a bit out on a limb, or not), I'm still not convinced the potential issue is that big. and automatically concerns every RFC that is a new version of an older one. It isn't hard to fix in my opinion (well, I just posted a draft with the proposed fix) and I don't see that it *requires* any tool fixes. Optionally, the tools could provide a macro that expands to the disclaimer text, but cut-and-paste would work equally well. I have read your draft. I have one suggestion for modification. The text says: the person(s) controlling the copyright in such material have not granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. I think it might be more appropriate to change the person(s) to some person(s). That is really the Trust's text, from http://trustee.ietf.org/docs/Draft-Update-to-IETF-Trust-Legal-Provisions-1-06-09.pdf And, it is from the DRAFT legal provisions, not the current legal provisions. At any rate, I think it needs to be persons or entities as some copyrights are controlled by corporations, universities or maybe even governments. Regards Marshall Overall, I think currently the aspect most overlooked in the general discussion, but most relevant for somebody who would actually like to move on with publications (I'm both a WG chair with some drafts that have completed WG Last Call, but which are now in RFC 5378 limbo, and an author of some individual IDs that I'd like to update and move forward) is: WHO exactly are we supposed to get permissions from. The situation of a deceased author is a tought one, but it's an obvious one. But I haven't seen any clear answer to whether permission from all the authors/editors (the people listed in the front of the document) is sufficient, whether we have to ask everybody above a certain percentage of email contributions in the WG, everybody who's mentioned in the Acks section, or what. It's a significant nuissance for everybody to go around and beg people (maybe including for their former employer) to confirm something they probably couldn't care less, even if they otherwise think the IETF does great stuff and everything. So it would really be good to know who exactly has to be bothered, and who not. Regards,Martin. #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:due...@it.aoyama.ac.jp ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
Martin Duerst due...@it.aoyama.ac.jp writes: WHO exactly are we supposed to get permissions from. The situation of a deceased author is a tought one, but it's an obvious one. But I haven't seen any clear answer to whether permission from all the authors/editors (the people listed in the front of the document) is sufficient, whether we have to ask everybody above a certain percentage of email contributions in the WG, everybody who's mentioned in the Acks section, or what. It's a significant nuissance for everybody to go around and beg people (maybe including for their former employer) to confirm something they probably couldn't care less, even if they otherwise think the IETF does great stuff and everything. So it would really be good to know who exactly has to be bothered, and who not. IANAL, but if you are expecting anyone (like the IETF) to give a clear final, legally defensible answer to who do you need permission from, you won't get it. That is the nature of legal questions and is what makes this entire discussion so difficult. And why what is an accptable risk for you may not be an acceptable risk for me or someone else. To answer the question, you have to look at who bears the risk if they make an assertion (i.e, by claiming that all contributers have signed off) that someone later challenges. And what the potential consequences would be. How likely is such a challenge? (the answer is almost always it depends). What is the likelyhood of a challenge having merit? (answer is it depends). What is the cost (time/money/aggrevation) of having to deal with such a situation? (it depends -- see the pattern?) While you (personally) may think the risk is negligble and silly, does your employer (who also probably bears some risk) share your opinion (it depends). Etc. And, it is all made that much worse by having to go through the same excercise for each document. Having done the analysis on 10 documents, doesn't help you much when it comes to the next document. Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
On Jan 9, 2009, at 10:16 AM, Thomas Narten wrote: Martin Duerst due...@it.aoyama.ac.jp writes: WHO exactly are we supposed to get permissions from. The situation of a deceased author is a tought one, but it's an obvious one. But I haven't seen any clear answer to whether permission from all the authors/editors (the people listed in the front of the document) is sufficient, whether we have to ask everybody above a certain percentage of email contributions in the WG, everybody who's mentioned in the Acks section, or what. It's a significant nuissance for everybody to go around and beg people (maybe including for their former employer) to confirm something they probably couldn't care less, even if they otherwise think the IETF does great stuff and everything. So it would really be good to know who exactly has to be bothered, and who not. IANAL, but if you are expecting anyone (like the IETF) to give a clear final, legally defensible answer to who do you need permission from, you won't get it. That is the nature of legal questions and is what makes this entire discussion so difficult. And why what is an accptable risk for you may not be an acceptable risk for me or someone else. My personal feeling is that is it is reasonable to ask authors to give their permission, and to obtain their company's permission, if need be, but that it is not reasonable to ask _authors_ to obtain permissions from third parties. Regards Marshall To answer the question, you have to look at who bears the risk if they make an assertion (i.e, by claiming that all contributers have signed off) that someone later challenges. And what the potential consequences would be. How likely is such a challenge? (the answer is almost always it depends). What is the likelyhood of a challenge having merit? (answer is it depends). What is the cost (time/money/aggrevation) of having to deal with such a situation? (it depends -- see the pattern?) While you (personally) may think the risk is negligble and silly, does your employer (who also probably bears some risk) share your opinion (it depends). Etc. And, it is all made that much worse by having to go through the same excercise for each document. Having done the analysis on 10 documents, doesn't help you much when it comes to the next document. Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
--On Friday, January 09, 2009 10:16 -0500 Thomas Narten nar...@us.ibm.com wrote: Martin Duerst due...@it.aoyama.ac.jp writes: WHO exactly are we supposed to get permissions from. The situation of a deceased author is a tought one, but it's an obvious one. But I haven't seen any clear answer to whether permission from all the authors/editors (the people listed in ... IANAL, but if you are expecting anyone (like the IETF) to give a clear final, legally defensible answer to who do you need permission from, you won't get it. That is the nature of legal questions and is what makes this entire discussion so difficult. And why what is an accptable risk for you may not be an acceptable risk for me or someone else. To answer the question, you have to look at who bears the risk if they make an assertion (i.e, by claiming that all contributers have signed off) that someone later challenges. And what the potential consequences would be. I think this is the crux of the issue. Let's consider three possible assertions (deliberately trying to avoid expressing them in lawyer-speak): (1) I give the Trust any rights that I or my company have and can give, but make absolutely no assertions about anyone else's rights. (2) I give the Trust any rights that I or my company have and can give, and have verified that everyone listed on the front page (or in some other list), with the following exceptions, have signed off on this. But I make absolutely no assertions about either the rights of anyone not listed, nor about anyone whom I had to identify as an exception. (3) I transfer all rights in the document to the Trust and guarantee the Trust that I've gotten the ok to do so from everyone who might be able to assert a claim of rights to the content, whether they are explicitly listed or not and whether the claim is bogus or not. Implicitly, if the Trust acts on the assumption that they have all the rights and someone complains or litigates, that is my problem to defend against and not the Trust's. Unless I am hugely confident, either * That I wrote every word of the text myself, paraphrasing contributions or suggestions from others, or * that no one will pop out of the woodwork, I believe that making assertion (3) is basically insane unless one is convinced that no one will _ever_ litigate any of this. If the Trust and IPR WG believed the latter, we wouldn't need any of this stuff, so forget that. The 2026/ 3739/ 4879 requirement is not insane because it only requires me to make assertions based on what I can be reasonably expected to know (and the transfer is less general, lowering the odds of protests somewhat). That doesn't eliminate the risk, but, IMO, brings it into manageable proportions. (1) is easy. (2) is a lot harder, but still plausible. But either of those do the one thing that (3) does not and that the current state of things seem intended to avoid: With (1) or (2), the Trust cannot write licenses that assert that they actually control all of the relevant rights (at least without a lot of expensive insurance). Consequently, with either of those options, the risk that someone unidentified might show up and assert a claim falls on either the Trust or the user of the material, not the author/editor of the document. That is the common characteristic of my I-D, Brian's recent I-D, and at least part of some of the repeal 5378 suggestions: the Trust doesn't get to assume that they have clear and unambiguous title to documents and permission to license them further on whatever terms they determine (and that, if the assumption is wrong, it is the author's problem). It is also, IMO, the fundamental problem with 5378/5377 and with almost any attempt to patch them. They are designed to protect the Trust against granting rights it doesn't have by making the submitter assume all of the obligations and risks of guaranteeing the Trust that it does have certain rights. That is just not how we ought to be designing things if we want people to make contributions to the IETF that build on the work of others. YMMD john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
John Leslie wrote: I may not be the one to explain, but I _don't_ think that's what the proposal calls for. I think it calls for inclusion of the boilerplate I listed above, which simply disclaims knowledge of _whether_ all the rights of 5378 are granted (and thus derivative works outside the IETF Standards Process are not authorized by the IETF Trust). I want derivative works outside the IETF Standards Process to be authorized by the IETF Trust and see no legal reason, at least in US law, why the IETF Trust can't authorize that without even mentioning the co-authors of those RFCs. The concern expressed in this thread is whether derivative works are authorized by the co-authors of those earlier RFCs. We need no statement (admission of guilt or otherwise) about that. Users of IETF RFCs should be comfortable that at least the IETF Trust authorizes such derivative works. Certainly the term open industry standard must mean that an RFC is a cooperative expressive and technical work by individuals and companies interested in a common result. We should accept the notion that IETF, and now the IETF Trust, as a public interest corporation that manages the expressive creative activities through which these joint works are written, is the joint owner of copyright in every RFC. As such, a license from the IETF Trust is all we need to create derivative works, without even asking the co-authors of those old (or new) documents. Does anyone here believe that the IETF Trust doesn't own a joint copyright interest in every RFC it publishes and can thus authorize derivative works of those RFCs? [1] /Larry [1] I intentionally avoid the argument, made in my previous emails here, that we don't even need the permission of the IETF Trust to copy and modify--when necessary for functional purposes--any industry standard specification. That's a bigger argument based on 17 USC 102(b), not one based on the Copyright Act definition of joint work: A 'joint work' is a work prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole. 17 USC 101. Lawrence Rosen Rosenlaw Einschlag, a technology law firm (www.rosenlaw.com) 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243 Skype: LawrenceRosen -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John Leslie Sent: Friday, January 09, 2009 10:15 AM To: dcroc...@bbiw.net Cc: IETF Discussion Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem Dave CROCKER d...@dcrocker.net wrote: A number of the comments, so far, appear to hinge on a rather basic cost/benefit model that is clearly quite different from what the proposal is based. I suspect that difference comes from a different sense of the problem, per John Klensin's posting. Agreed. My reference to legality is based on a view of the proposal which sees it as having individual submitters essentially say I am required to get permission and I have not gotten it. That's an admission of guilt... I don't read it that way. Refer to: http://trustee.ietf.org/docs/Draft-Update-to-IETF-Trust-Legal-Provisions- 1-06-09.pdf ] ] 6. c. iii. ] ... This document contains material from IETF Documents or IETF ] Contributions published before November 10, 2008 and, to the ] Contributor's knowledge, the person(s) controlling the copyright ] in such material have not granted the IETF Trust the right to allow ] modifications of such material outside the IETF Standards Process. ] Without obtaining an adequate license from the person(s) controlling ] the copyright, this document may not be modified outside the IETF ] Standards Process, and derivative works of it may not be created ] outside the IETF Standards Process, except to format it for ] publication as an RFC and to translate it into languages other than ] English. If you believe there is an admission of guilt there, please send text. (But understand, lawyers have to sign off on any changes.) And if you don't think that's what the proposal calls for, please explain, because I don't think my interpretation is all that creative. I may not be the one to explain, but I _don't_ think that's what the proposal calls for. I think it calls for inclusion of the boilerplate I listed above, which simply disclaims knowledge of _whether_ all the rights of 5378 are granted (and thus derivative works outside the IETF Standards Process are not authorized by the IETF Trust). This situation has halted the progression of some Internet-Drafts and interrupted the publication of some RFCs. This means that we have a crisis which is stopping productive work, yet the crisis appears to be caused by a faulty new requirement, rather than by the situation
RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
At 11:09 AM -0800 1/9/09, Lawrence Rosen wrote: We should accept the notion that IETF, and now the IETF Trust, as a public interest corporation that manages the expressive creative activities through which these joint works are written, is the joint owner of copyright in every RFC. As such, a license from the IETF Trust is all we need to create derivative works, without even asking the co-authors of those old (or new) documents. Does anyone here believe that the IETF Trust doesn't own a joint copyright interest in every RFC it publishes and can thus authorize derivative works of those RFCs? [1] Are you willing to personally indemnify the individuals who are later sued by those who don't hold this view or are you willing to pay for the appropriate insurance cover? Take a look for a moment at RFC 2822. It is a successor to a document that does not contain an ISOC copyright (because ISOC came into being approximately 10 years later). It does have an ISOC copyright but RFC 2822 also has a very extensive list of contributors: Matti Aarnio Barry Finkel Larry Masinter Tanaka Akira Erik Forsberg Denis McKeon Russ Allbery Chuck Foster William P McQuillan Eric Allman Paul Fox Alexey Melnikov Harald Tveit Alvestrand Klaus M. Frank Perry E. Metzger Ran Atkinson Ned Freed Steven Miller Jos BackusJochen Friedrich Keith Moore Bruce Balden Randall C. Gellens John Gardiner Myers Dave Barr Sukvinder Singh Gill Chris Newman Alan Barrett Tim GoodwinJohn W. Noerenberg John Beck Philip GuentherEric Norman J. Robert von Behren Tony HansenMike O'Dell Jos den BekkerJohn Hawkinson Larry Osterman D. J. Bernstein Philip Hazel Paul Overell James BerrimanKai Henningsen Jacob Palme Norbert BollowRobert Herriot Michael A. Patton Raj Bose Paul Hethmon Uzi Paz Antony Bowesman Jim Hill Michael A. Quinlan Scott Bradner Paul E. HoffmanEric S. Raymond Randy BushSteve Hole Sam Roberts Tom Byrer Kari HurttaHugh Sasse Bruce CampbellMarco S. Hyman Bart Schaefer Larry CampbellOfer Inbar Tom Scola W. J. Carpenter Olle Jarnefors Wolfgang Segmuller Michael Chapman Kevin Johnson Nick Shelness Richard Clayton Sudish Joseph John Stanley Maurizio Codogno Maynard Kang Einar Stefferud Jim Conklin Prabhat Keni Jeff Stephenson R. Kelley CookJohn C. KlensinBernard Stern Steve CoyaGraham Klyne Peter Sylvester Mark Crispin Brad Knowles Mark Symons Dave Crocker Shuhei Kobayashi Eric Thomas Matt Curtin Peter Koch Lee Thompson Michael D'Errico Dan Kohn Karel De Vriendt Cyrus Daboo Christian KuhtzMatthew Wall Jutta Degener Anand Kumria Rolf Weber Mark Delany Steen Larsen Brent B. Welch Steve Dorner Eliot Lear Dan Wing Harold A. DriscollBarry LeibaJack De Winter Michael ElkinsJay Levitt Gregory J. Woodhouse Robert ElzLars-Johan Liman Greg A. Woods Johnny Eriksson Charles LindseyKazu Yamamoto Erik E. Fair Pete LoshinAlain Zahm Roger Fajman Simon LyallJamie Zawinski Patrik Faltstrom Bill Manning Timothy S. Zurcher Claus Andre FarberJohn Martin It would be reasonable for everyone in that list to believe that their work could be re-used within the IETF context (it post dates RFC 2026 sufficiently for that). We have now changed the rules such that their work can be used in other contexts, provided the Trust authorizes it; prior to that, the individuals would have had to authorize it.To let the Trust authorize that without explicit permission requires us to believe that everyone in that list (and every other similar list) either believed at the time that their work could be so used, believes now that it can be so used, or is sufficiently laissez-faire that they won't do anything to stop it, even if they don't agree. My reading of John's point is that this creates either a coordination burden or a legal risk for the authors re-using text created prior to the new rules. He doesn't want to bear that burden/risk, and I don't think the Trust can
RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
Ted Hardie asked me: Are you willing to personally indemnify the individuals who are later sued by those who don't hold this view or are you willing to pay for the appropriate insurance cover? Of course not. Are you (or your company) warning me that *you* might sue me for infringement of anything you contributed to a joint industry standard RFC? If so, thanks for the warning. Now, I'll ignore it. As I hope will most of the people and companies who rely on IETF RFCs. You can't threaten me by listing hundreds of people who had something to do with an RFC in the past. Or make me beg you or your company or any of those people for permission in order to treat an industry standard as a part of our common heritage with the authority in the IETF Trust to deal with it (as a copyrighted document) as it wishes in the public interest. It would be reasonable for everyone in that list to believe that their work could be re-used within the IETF context (it post dates RFC 2026 sufficiently for that). We have now changed the rules such that their work can be used in other contexts, provided the Trust authorizes it; prior to that, the individuals would have had to authorize it. Under US law, a joint copyright owner doesn't have to ask anyone's permission to change the rules. Sorry you don't like that. Or are you threatening to sue the IETF Trust if it changes the rules? Based on what legal principle? /Larry -Original Message- From: Ted Hardie [mailto:har...@qualcomm.com] Sent: Friday, January 09, 2009 11:42 AM To: lro...@rosenlaw.com; 'IETF Discussion' Subject: RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem At 11:09 AM -0800 1/9/09, Lawrence Rosen wrote: We should accept the notion that IETF, and now the IETF Trust, as a public interest corporation that manages the expressive creative activities through which these joint works are written, is the joint owner of copyright in every RFC. As such, a license from the IETF Trust is all we need to create derivative works, without even asking the co-authors of those old (or new) documents. Does anyone here believe that the IETF Trust doesn't own a joint copyright interest in every RFC it publishes and can thus authorize derivative works of those RFCs? [1] Are you willing to personally indemnify the individuals who are later sued by those who don't hold this view or are you willing to pay for the appropriate insurance cover? Take a look for a moment at RFC 2822. It is a successor to a document that does not contain an ISOC copyright (because ISOC came into being approximately 10 years later). It does have an ISOC copyright but RFC 2822 also has a very extensive list of contributors: Matti Aarnio Barry Finkel Larry Masinter Tanaka Akira Erik Forsberg Denis McKeon Russ Allbery Chuck Foster William P McQuillan Eric Allman Paul Fox Alexey Melnikov Harald Tveit Alvestrand Klaus M. Frank Perry E. Metzger Ran Atkinson Ned Freed Steven Miller Jos BackusJochen Friedrich Keith Moore Bruce Balden Randall C. Gellens John Gardiner Myers Dave Barr Sukvinder Singh Gill Chris Newman Alan Barrett Tim GoodwinJohn W. Noerenberg John Beck Philip GuentherEric Norman J. Robert von Behren Tony HansenMike O'Dell Jos den BekkerJohn Hawkinson Larry Osterman D. J. Bernstein Philip Hazel Paul Overell James BerrimanKai Henningsen Jacob Palme Norbert BollowRobert Herriot Michael A. Patton Raj Bose Paul Hethmon Uzi Paz Antony Bowesman Jim Hill Michael A. Quinlan Scott Bradner Paul E. HoffmanEric S. Raymond Randy BushSteve Hole Sam Roberts Tom Byrer Kari HurttaHugh Sasse Bruce CampbellMarco S. Hyman Bart Schaefer Larry CampbellOfer Inbar Tom Scola W. J. Carpenter Olle Jarnefors Wolfgang Segmuller Michael Chapman Kevin Johnson Nick Shelness Richard Clayton Sudish Joseph John Stanley Maurizio Codogno Maynard Kang Einar Stefferud Jim Conklin Prabhat Keni Jeff Stephenson R. Kelley CookJohn C. KlensinBernard Stern Steve CoyaGraham Klyne Peter Sylvester Mark Crispin Brad Knowles Mark Symons Dave Crocker Shuhei Kobayashi Eric Thomas Matt Curtin Peter Koch
RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
At 12:34 PM -0800 1/9/09, Lawrence Rosen wrote: Ted Hardie asked me: Are you willing to personally indemnify the individuals who are later sued by those who don't hold this view or are you willing to pay for the appropriate insurance cover? Of course not. Are you (or your company) warning me that *you* might sue me for infringement of anything you contributed to a joint industry standard RFC? Nope. And turning up the rhetoric to flame neither advances the discussion nor makes your arguments any more valid. Under US law, a joint copyright owner doesn't have to ask anyone's permission to change the rules. Sorry you don't like that. I don't have any opinion, like, or dislike on that, and, as I said, I'm not lawyer. The point made repeatedly, though, is that even if all of the current individual contributors agree that this is the case, they run the risk of litigation by those who do not when they use the current system. It asks the contributor to assert something; they either must do the work of being sure they can make that assertion or they must assume the risk of having made the assertion if they find themselves in disagreement with other contributors. We did not previously get these rights explicitly; we did get others. Whether we have the new rights now due to the characteristics of the work does not seem to be settled enough for the contributors to believe they can assume the risks. They see the enumerated list and worry someone will sue them for it. Their lawyers may be wrong and you right, but that doesn't get them to assume the risks. Or are you threatening to sue the IETF Trust if it changes the rules? Based on what legal principle? No, I am threatening to go get a calming cup of white tea, to remind myself why I was so happy when the IPR working group shut down. And, once again, I would be far happier having these discussion with you, Larry, if you had *ever* contributed anything to the IETF that didn't amount to mailing list political rhetoric. Since you have no evident likelihood of putting forth a document revision any of our standards, it's pretty hard to believe your view of the risk is as personal as, say, John's. Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
--On Friday, January 09, 2009 11:42 -0800 Ted Hardie har...@qualcomm.com wrote: ... My reading of John's point is that this creates either a coordination burden or a legal risk for the authors re-using text created prior to the new rules. He doesn't want to bear that burden/risk, and I don't think the Trust can (because it would have to analyze each document prior to assuming it, as it would be otherwise trivial for someone to submit a draft that clearly had no permission from the copyright holders). He wants an out that says I'm granting these rights to my text, you worry about any other rights. As a transition to text based on documents written within the new rules, that may be the way to go. What none of us wants is to have to restart this conversation at ground zero, because a lot of the other rights (like re-using code) set out in the new document should be applying to new work in new drafts now. Exactly. And note that makes a clear and plausible transition model: (1) Pre-5378 documents exist under pre-5378 rules, so any potential user for non-traditional purposes needs to either figure out who the relevant authors are and get their permission or decide the risk isn't worth worrying about. If some of those authors/ contributors make explicit transfers to the Trust, that is great, but none of them have to take responsibility for identifying all of the others. (3) Post-5378 new documents are posted according to 5378 rules, with no exceptions. (2) Post-5378 documents that incorporate pre-5378 materials must used 5378 rules for any material that is new. For the earlier materials, and for sorting out which is which, the burden falls on the potential user for non-traditional purposes to either figure out who the relevant authors are and get their permission, determine that all relevant authors have already given permission, or assume the risks. No one else --neither the author(s)/ editor(s) of the new document nor the Trust-- is required to take responsibility for pre-5378 contributors or contributions. Even an editor of the new document that worked on the old material is not required to make assertions about new rights on behalf of his or her former employer. This doesn't weaken the core grant of rights in 5378 in any fundamental way. If we are being realistic, it doesn't get us to the point 5378 wants to get us to any more slowly. It makes one fundamental change: the responsibility and liability for sorting out the IPR status of materials created and contributed prior to the 5378 shifts from the author of a post-5378 document to the person who wants to copy material out of that document in excess of 2026 / 3978/ 4748 rules. That does not increase the burdens on that person at all relative to the burdens he or she inevitably has with pre-5378 documents that are not being revised. It does not increase the risks to the Trust at all. It does let people trying to do technical work in the IETF do that work without signing up for legal determinations, work, or risks that do not involve the earlier work of others, and it is that sign-up requirement that is the problem with 5378. Now, what I recommend is that we try to see if we can agree that the three-stage description above is what we intend. If we can agree, then the _next_ step is figuring out how to get there in the minimum period of time. My problem with the Trust's latest proposed policy is that we've got extensive evidence --including the consensus decision that got us into the mess-- that the IETF is not good at evaluating legal documents and theories and their possible consequences and side-effects. I don't believe that the right way to solve that problem is to hand the IETF yet another legal document, with some language and a theory in it that seems subtle, and ask us to evaluate it. I believe that the IETF should accept a clearly-stated set of principles and that the Trust should then come back and say on the advice of Counsel, the following text implements that principle. If lawyers then want to argue about whether the text is optimal to implement those principles, that is fine with me, as long as the argument is limited to the relationship between principles and text and not an attempt to change principles. Remember that the Trustees do have insurance against getting that sort of thing wrong; the rest of us are not insured against either getting those things wrong or against the Trust doing so. Now, if the Trust will reassure us, on that same basis, that the new proposal gets us closer to those principles without creating an additional mess that will need to be sorted out in the future, then I'm in favor of the text. If the Trust is really saying, as the announcement appears to do here is
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
John, On 2009-01-10 10:32, John C Klensin wrote: ... And note that makes a clear and plausible transition model: (1) Pre-5378 documents exist under pre-5378 rules, so any potential user for non-traditional purposes needs to either figure out who the relevant authors are and get their permission or decide the risk isn't worth worrying about. If some of those authors/ contributors make explicit transfers to the Trust, that is great, but none of them have to take responsibility for identifying all of the others. (3) Post-5378 new documents are posted according to 5378 rules, with no exceptions. (2) Post-5378 documents that incorporate pre-5378 materials must used 5378 rules for any material that is new. For the earlier materials, and for sorting out which is which, the burden falls on the potential user for non-traditional purposes to either figure out who the relevant authors are and get their permission, determine that all relevant authors have already given permission, or assume the risks. No one else --neither the author(s)/ editor(s) of the new document nor the Trust-- is required to take responsibility for pre-5378 contributors or contributions. Even an editor of the new document that worked on the old material is not required to make assertions about new rights on behalf of his or her former employer. Thanks John, I believe that is an excellent summary of the viable options. My draft implicitly adds (2.5) Post-5378 documents that incorporate pre-5378 materials whose original contributors have duly agreed are posted according to 5378 rules, with no exceptions. To my mind the main open issue is whether we want to require authors to try for (2.5) before proceeding to (2). Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
John Klensin wrote: Note 2: Larry, I'm not competent to debate your joint authorship theory and hope that no one else, at least no one who is not an attorney admitted to practice in some relevant jurisdiction, will engage you on it. However, it appears to me as a non-lawyer that, if you are correct, we should be blowing away 5378 and all of its language and concentrating on 5377 (which no one has attacked since the WG concluded). If the theory is correct, then 5378 complicates things because it can easily be read as an attempt to establish principles of separate authorship in the IETF case and get everyone to agree to those principles, even if only as a between-contributors agreement. And one should not wish for those complications. I agree that the proper forum for this discussion is with the officers and legal counsel of IETF and not this public list. I have previously written to Jorge Contreras about some of these points and am always pleased by his thoughtful private responses. My only reason for bringing it up again on-list is that people here are publicly discussing specific legal wording to fix 5378. But as a fundamental principle of property law, I don't believe in IETF asking anyone's permission, even respected IETF contributors, to create derivative works of works already in the public domain or any works that IETF already owns jointly. As John Klensin noted, 5378 and the proposed workaround complicates things because it can easily be read as an attempt to establish principles of separate authorship in the IETF case and get everyone to agree to those principles. I can't agree to that. Can you? That's why I challenged Ted Hardie directly. Please don't take it personally or as flaming, but anyone who wants to assert a private ownership right in any copyright in any IETF RFC ought to do so now or forever hold your peace. Otherwise, I think it best that the IETF Trust exercise its rights under its joint copyright to do whatever is deemed appropriate and in the public interest, as determined by the IETF Trustees and its legal counsel, and not ask permission. /Larry -Original Message- From: John C Klensin [mailto:john-i...@jck.com] Sent: Friday, January 09, 2009 1:33 PM To: Ted Hardie; lro...@rosenlaw.com; 'IETF Discussion' Subject: RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem --On Friday, January 09, 2009 11:42 -0800 Ted Hardie har...@qualcomm.com wrote: ... My reading of John's point is that this creates either a coordination burden or a legal risk for the authors re-using text created prior to the new rules. He doesn't want to bear that burden/risk, and I don't think the Trust can (because it would have to analyze each document prior to assuming it, as it would be otherwise trivial for someone to submit a draft that clearly had no permission from the copyright holders). He wants an out that says I'm granting these rights to my text, you worry about any other rights. As a transition to text based on documents written within the new rules, that may be the way to go. What none of us wants is to have to restart this conversation at ground zero, because a lot of the other rights (like re-using code) set out in the new document should be applying to new work in new drafts now. Exactly. And note that makes a clear and plausible transition model: (1) Pre-5378 documents exist under pre-5378 rules, so any potential user for non-traditional purposes needs to either figure out who the relevant authors are and get their permission or decide the risk isn't worth worrying about. If some of those authors/ contributors make explicit transfers to the Trust, that is great, but none of them have to take responsibility for identifying all of the others. (3) Post-5378 new documents are posted according to 5378 rules, with no exceptions. (2) Post-5378 documents that incorporate pre-5378 materials must used 5378 rules for any material that is new. For the earlier materials, and for sorting out which is which, the burden falls on the potential user for non-traditional purposes to either figure out who the relevant authors are and get their permission, determine that all relevant authors have already given permission, or assume the risks. No one else --neither the author(s)/ editor(s) of the new document nor the Trust-- is required to take responsibility for pre-5378 contributors or contributions. Even an editor of the new document that worked on the old material is not required to make assertions about new rights on behalf of his or her former employer. This doesn't weaken the core grant of rights in 5378 in any fundamental way. If we are being realistic, it doesn't get us to
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
ned+i...@mauve.mrochek.com wrote: This is EXACTLY the approach we should be using: Formulate a set of goals, get agreement on them, and only then ask the laywers to turn that informal specification into competent legalese. ... The difference was like night and day. +1 That matches my experience, over the years. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
--On Saturday, January 10, 2009 11:07 +1300 Brian E Carpenter brian.e.carpen...@gmail.com wrote: Thanks John, I believe that is an excellent summary of the viable options. My draft implicitly adds (2.5) Post-5378 documents that incorporate pre-5378 materials whose original contributors have duly agreed are posted according to 5378 rules, with no exceptions. To my mind the main open issue is whether we want to require authors to try for (2.5) before proceeding to (2). I am all in favor of authors trying for 2.5 if they have the time and inclination although, mostly, I'd rather have them spend time on technical work (Marshall's suggestion last month that the Trust itself should take responsibility for rounding up old rights has some appeal here). What I'm opposed to is requiring authors of documents that might have had a very long history to take responsibility for claiming that they have identified all of the original contributors. My problem with 2.5, stated somewhat more aggressively than is probably desirable, is that it requires the submitter of a 2.5 document to stand up and say I have identified all of those who might claim to have rights in this document, will take responsibility for getting that identification right, and obtained their consent. There is a possible 2.5bis, which would be something like I've made a good-faith, reasonable-effort, attempt to identify everyone and have the agreements from everyone whom that process identified, but I make absolutely no warranty that I've identified everyone or that other claims won't come up; if they do, it is the user's problem, not mine. Whether that is enough different in practice from my (2) to be worth the complexity... I don't know. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
My own take has been that the code reuse problem is the dominant problem. Document transfer outside the IETF is sufficiently rare that I would agree with Fred that not solving that is fine. This also means that from my personal perspective, a solution that says (loosely based on a suggestion from someone else in a side conversation) that 1) If you can, you grant 5378 rights 2) If you can't, you grant the old rights, as long as there is no code in the document 3) If there is code, get the rights to the code so people can actually use the code in the RFC to implement the RFC. (MIBs are already covered, but we have lots of other kinds of code.) would seem a workable path. Yes, point 3 may hold up some work. But one could reasonably argue that such work needs to be held up so that folks can use the code we are giving them. And I fully agree that we should leave all legal wordsmithing to the trust and the lawyers. They have to do it anyway. Yours, Joel John C Klensin wrote: --On Saturday, January 10, 2009 11:07 +1300 Brian E Carpenter brian.e.carpen...@gmail.com wrote: Thanks John, I believe that is an excellent summary of the viable options. My draft implicitly adds (2.5) Post-5378 documents that incorporate pre-5378 materials whose original contributors have duly agreed are posted according to 5378 rules, with no exceptions. To my mind the main open issue is whether we want to require authors to try for (2.5) before proceeding to (2). I am all in favor of authors trying for 2.5 if they have the time and inclination although, mostly, I'd rather have them spend time on technical work (Marshall's suggestion last month that the Trust itself should take responsibility for rounding up old rights has some appeal here). What I'm opposed to is requiring authors of documents that might have had a very long history to take responsibility for claiming that they have identified all of the original contributors. My problem with 2.5, stated somewhat more aggressively than is probably desirable, is that it requires the submitter of a 2.5 document to stand up and say I have identified all of those who might claim to have rights in this document, will take responsibility for getting that identification right, and obtained their consent. There is a possible 2.5bis, which would be something like I've made a good-faith, reasonable-effort, attempt to identify everyone and have the agreements from everyone whom that process identified, but I make absolutely no warranty that I've identified everyone or that other claims won't come up; if they do, it is the user's problem, not mine. Whether that is enough different in practice from my (2) to be worth the complexity... I don't know. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
--On Friday, January 09, 2009 15:25 -0800 Dave CROCKER d...@dcrocker.net wrote: ned+i...@mauve.mrochek.com wrote: This is EXACTLY the approach we should be using: Formulate a set of goals, get agreement on them, and only then ask the laywers to turn that informal specification into competent legalese. ... The difference was like night and day. +1 That matches my experience, over the years. If my memory is correct, that was exactly the basis on which the most recent IPR WG was told to proceed. For one reason or another, it ended up expressing its ideas of the principles in the form of quasi-legal documents (or, if you prefer, documents containing legal-language statements) rather than publishing a clear statement of those principles independent of those documents. In fairness to the WG, that turned out to be easier, especially in the absence of clear consensus about which problems were most important. If the community -- and assorted ADs -- learn anything from this experience it should be, IMO, that if such a document shows up on Last Call instead of (or without) a normative statement of principles against which legal text can be checked and verified, we should Just Say No. But that discussion doesn't help much with the short-term problem. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
On Fri, Jan 09, 2009 at 06:52:40PM -0500, Joel M. Halpern wrote: My own take has been that the code reuse problem is the dominant problem. Document transfer outside the IETF is sufficiently rare that I would agree with Fred that not solving that is fine. If it really is the case that the *only* two problems was document transferoutside of the IETF (rare) and code reuse problem (what percentage of documents are are actual code that would require special case licensing --- small) it's actually pretty amazing that the problem was allowed to balloon to cover **all** text for **all I-D's and RFC's**. There's the old saying --- an engineer takes a large problem and break it up into several smaller problems, and having solved each of the small problems, solves the overall problem; a bureaucrat takes several small programs, and tangles them all together into one, gigantic, intractable problem. This also means that from my personal perspective, a solution that says (loosely based on a suggestion from someone else in a side conversation) that 1) If you can, you grant 5378 rights 2) If you can't, you grant the old rights, as long as there is no code in the document 3) If there is code, get the rights to the code so people can actually use the code in the RFC to implement the RFC. (MIBs are already covered, but we have lots of other kinds of code.) We do have precedent for include code that has explicit open source licensing rights. For example, the MD5 implementation in RFC 1321 has an explicit BSD-style license. How much code is there, really? I suppose pseudo-code might be a gray area tht will depend on how paranoid of a lawyer you are dealing with. One who uses the argument that copyright can not protect ideas, just the expression of the idea, will probably say that it's OK. One who tries to draw a parallel to translations as derived works might be more concerned. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
