RE: RIM patents a URN (and ignores IETF IPR rules)
> -Original Message- > From: Contreras, Jorge > Sent: Friday, November 20, 2009 2:38 PM > To: 'Fred Baker'; Michael Montemurro > Cc: Cullen Jennings; IETF-Discussion list > Subject: RE: RIM patents a URN (and ignores IETF IPR rules) > > > > > -Original Message- > > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > > Behalf Of Fred Baker > > Sent: Thursday, November 19, 2009 8:53 PM > > To: Michael Montemurro > > Cc: Cullen Jennings; IETF-Discussion list > > Subject: Re: RIM patents a URN (and ignores IETF IPR rules) > > > > In my company's case, we file IPR disclosures on patent > applications > > as well as allowed claims. That is consistent with our corporate > > policy of encouraging innovation and patenting defensively; our > > disclosures as a rule include the fact that we do not seek > monetary > > reward unless another party would rather trade IPR licenses > mediated > > by expensive lawyers than accept a free RFC 1988 license. > > Fred - this is not only good corporate practice, disclosure > of patent applications > is unambiguously required by RFC 3977. Just to clarify: I was referring to the first part of Fred's paragraph: what's required is disclosing patent applications, not the other corporate policies that Fred's company might adopt. > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: RIM patents a URN (and ignores IETF IPR rules)
> -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Fred Baker > Sent: Thursday, November 19, 2009 8:53 PM > To: Michael Montemurro > Cc: Cullen Jennings; IETF-Discussion list > Subject: Re: RIM patents a URN (and ignores IETF IPR rules) > > In my company's case, we file IPR disclosures on patent applications > as well as allowed claims. That is consistent with our corporate > policy of encouraging innovation and patenting defensively; our > disclosures as a rule include the fact that we do not seek monetary > reward unless another party would rather trade IPR licenses mediated > by expensive lawyers than accept a free RFC 1988 license. Fred - this is not only good corporate practice, disclosure of patent applications is unambiguously required by RFC 3977. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] Objection to reworked para 6.d (Re: Rationale forProposed TLP Revisions)
> Ok. So is the point then just not to have to issue a new RFC if the > Trust decides they want a different license? I.e. is that the > "future-proofing" that the proposed change is supposed to provide? I apologize if my unfortunate use of the term "future-proofing" has caused angst. But I was referring to the proposal made by Harald Alvestrand, as a member of the community, not a proposal made by the Trust. Harald's proposal should not be taken as an indication of the Trust's intentions. I believe that Russ and I were merely saying that Harald's proposal seemed reasonable. If other members of the community disagree, then that's fine too. > > If so, in light of the other comments people are making about how the > Trust appears to be rather more activist than some people find > congenial (I am reserving my opinion on that topic), I'm not sure the > proposed change is a good one. If the Trust needed to change the > license, there would be two reasons to do it, I think: > > 1. The community wants the change. > > 2. External forces (say, legal precedents) cause the > currently-selected license to be the wrong one. > > But both of those cases seem to me to be the sort of thing that > requires some community input and some rough consensus, no? If so, > then what would be hard about writing a new RFC that captured this > update, and publishing it the way of the usual RFC process? > > A > > > -- > Andrew Sullivan > a...@shinkuro.com > Shinkuro, Inc. > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
> -Original Message- > From: trustees-boun...@ietf.org > [mailto:trustees-boun...@ietf.org] On Behalf Of Russ Housley > Sent: Monday, July 20, 2009 8:41 AM > To: ietf@ietf.org > Cc: trust...@ietf.org; wgcha...@ietf.org; > rfc-inter...@rfc-editor.org; i...@iab.org; i...@ietf.org > Subject: Re: [Trustees] Objection to reworked para 6.d (Re: > Rationale for Proposed TLP Revisions) > > I think that the alternate text proposed by Harald meets the current > need without constraining the future. > > Russ I also think that Harald's alternate language would work. The sentence in question was inserted to offer guidance to users of code, not to comply with any specific legal requirement of the BSD License. If others think that Harald's formulation would be more helpful (and more future-proof), then it is a reasonable approach to adopt. > > > >Apologies for this being a month late. > > > > From the rationale: > >>4.e -- this new section clarifies the legend requirements for Code > >>Components that are used in software under the BSD License. In > >>short, the user must include the full BSD License text or a shorter > >>pointer to it (which is set forth in Section 6.d) > >> > >>Explanation: The issue of the appropriate BSD License language to > >>include in Code > >>Components extracted from IETF documents has been discussed > extensively > >>within the IESG. The proposed TLP language is intended to > be consistent > >>with the IESG's latest guidance language, and allows the > user of IETF > >>Code to include either the full BSD license language (about > 15 lines of > >>text), or a short "pointer" to the BSD language (about 4 lines). > >>6.b -- a new sentence has been added to the legend that > must be placed > >>on all IETF Documents, pointing out the BSD License requirements > >>described in 4.e above and emphasizing that code in IETF Documents > >>comes without any warranty, as described in the BSD License. > >> > > > >>Explanation: See 4.e above > >> > >The text added, which is intended to be placed on all IETF documents > >(internet-drafts and RFCs), is: > > > >>Code Components > >>extracted from this document must include BSD License text as > >>described in Section 4.e of > >>the TLP and are provided without warranty as described in > the BSD License. > > > > > >I object to this change. > > > >The reason is this: > > > >- The RFCs are intended to be permanent (as in "forever"). > >- The purpose of the "incoming/outgoing split" was to make sure the > >Trust had the tools it needed to fix any errors made, or to respond > >to changed circumstances, by changing the rights granted > under "outgoing". > >- The BSD license is a specific license text, and there is no > >guarantee that there won't be new circumstances that warrant generic > >licensing under a different license in the future. > > > >Thus, this change limits the ability of the Trust to respond to > >future changes; if it ever decides (as an example) to use the Apache > >License instead of the BSD license because some court has found the > >BSD text to be objectionable in some manner, this will lead to all > >documents published with this text to be misleading. > > > >(As an example of changed circumstances - the Wikimedia Foundation > >just changed its licensing terms from GPL to a Creative Commons > >license - this required some fancy footwork to make it seem legal, > >even though a large majority of contributors agreed that it was the > >right thing to do. I don't want to see that kind of trouble > in the IETF.) > > > >If the text added instead read: > > > > Code Components extracted from this document must include > license text > > as described in the TLP and are provided without warranty > as described in > > the TLP license provisions > > > >I would have no objection. This preserves the Trust's ability to > >change provisions. > > > > Harald Alvestrand > > > > > > ___ > 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] [IAB] Proposed Revisions to the IETF Trust Legal Provisions (TLP)
> The statement in 2.b, in conjunction with a July 2009 Effective > Date (see the top of the document), leaves documents published > between the presumptive Effective Date of the procedures in > effect today and that date in a strange sort of never-never > land, since 2.b doesn't mention 5378. The Feb. 15 version of the TLP is currently in effect. Documents published between Feb. 15 and the effectiveness of the revised TLP will continue to be governed by the Feb. 15 TLP. There should be no gap in coverage. > I can only infer from this that the Trustees did not do a > careful review of the proposed new procedures in toto. That is not true. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)
> But, > using this draft with the serious problem Simon spotted and the > minor "no justification for adding boilerplate" one that I > spotted as the most recent of what have been many examples, it > appears that the IAOC/Trustees are composed of human beings with > many other things on their minds and calendars rather than of > infallible entities. John -- this is just to note that the items raised by you and Simon aren't errors caused by hurried or sloppy work by the Trust, they are reasonable points of disagreement over policy and interpretation. It's certainly legitimate for you to raise and discuss these points, but you shouldn't assume that, just because you or Simon have a particular interpretation, the alternate interpretation embodied in the TLP is a careless error. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: References to Redphone's "patent"
> > Shall we ask the FSF members of IETF also to comment on the > need for IETF to > develop a comprehensive policy toward patents so that encumbrances to > Internet standards can be understood and avoided in the future? > > /Larry IETF does have a patent policy. It is at RFC 3979. It may not be to everyone's liking, but it does exist. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] Last Call for Comments: Proposed work-around to thePre-5378 Problem
> For the above text to be more clear, I'd suggest something like: > > NEW PROPOSED > > c. Derivative Works and Publication Limitations. If a Contributor >desires to limit the right to make modifications and derivative >works of an IETF Contribution, then one of the notices in >clause (i) or (ii) below must be included. Note that a >contribution with such a clause cannot become a Standards Track >document or, in most cases, a working group document, > That works for me. For what it's worth, in clauses (i) and (ii) we were just being deferential to that historical language, which has been around since, I think 2026. I'm all for clearing it up. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] Last Call for Comments: Proposed work-around to thePre-5378 Problem
> -Original Message- > From: Thomas Narten [mailto:nar...@us.ibm.com] > Sent: Monday, February 09, 2009 6:23 PM > To: Marshall Eubanks > Cc: Contreras, Jorge; Trustees; SM; ietf@ietf.org > Subject: Re: [Trustees] Last Call for Comments: Proposed > work-around to thePre-5378 Problem > > > > NEW PROPOSED > > > > > >c. Derivative Works and Publication Limitations. If a > Contributor > > > desires to limit the right to make modifications > and derivative > > > s/desires/needs/ > > > I don't think that "desires" is appropriate here - as John pointed > > out, the contributor has no discretion here, except for their > > judgement as to whether rights are available. > > Actually, in this case, it is the submitters choice, since we are > talking about case (i) or (ii) (and not (iii) which has been the > challenging case). And "desires" is the wording that has been used > here for a while. > > But that said, a more neutral term is fine by me, since the > motivations for needing to select this may vary. > > How about "chooses"? > > Thomas "chooses" is fine with me ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] Last Call for Comments: Proposed work-around to thePre-5378 Problem
Ok, I think (hope) I understand the intention now. How about the following as a friendly clarifying amendment to the proposed text: Proposed Yesterday: c. Derivative Works and Publication Limitations. If a Contributor desires to limit its publication, or the Contribution includes pre-5378 Material that may limit the right to make modifications and derivative works of an IETF Contribution, one of the following notices must be included. The notices set forth in clauses (i) and (ii) below may not be used with any standards-track document, nor with most working group documents. The "Proposed Yesterday" text blurs the distinction between c.i/ii and c.iii. I think that this could be done more clearly, as suggested in NEW PROPOSED below. In the first sentence of c, the old concept of clauses i and ii is preserved. The new concept in iii is treated in the next sentence. NEW PROPOSED c. Derivative Works and Publication Limitations. If a Contributor desires to limit the right to make modifications and derivative works of, or to publish, an IETF Contribution that is not a standards-track document or, in most cases, a working group document, then one of the notices in clause (i) or (ii) below must be included. If an IETF Contribution contains pre-5378 Material as to which the IETF Trust has not been granted, or may not have been granted, the necessary permissions to allow modification of such pre-5378 Material outside the IETF Standards Process, then the notice in clause (iii) may be included by the Contributor of such IETF Contribution to limit the right to make modifications to such pre-5378 Material outside the IETF Standards Process. NEW PROPOSED c.iii. introduction (Notice stays the same) For consistency and clarity the introduction to c.iii is made to conform with 6.c as follows iii. If an IETF Contribution contains pre-5378 Material as to which the IETF Trust has not been granted, or may not have been granted, the necessary permissions to allow modification of such pre-5378 Material outside the IETF Standards Process: > -Original Message- > From: SM [mailto:s...@resistor.net] > Sent: Sunday, February 08, 2009 7:04 PM > To: Contreras, Jorge > Cc: Trustees; ietf@ietf.org > Subject: RE: [Trustees] Last Call for Comments: Proposed > work-around to thePre-5378 Problem > > At 14:24 08-02-2009, Contreras, Jorge wrote: > >Sorry for jumping into this thread late, but I would > recommend leaving > >6.c and 6.c.iii as proposed in the TLP draft that was circulated. > > [snip] > > >I think "does not wish" is right, as it gives the new Contributor > >maximum flexibility in withholding the right to make > non-IETF derivative > >works if his Contribution includes pre-5378 Material. I > don't see any > >of the proposed changes making this clearer or better. > > I'm writing this in plain English. The trustees can convert > it to legalese. > > The new Contributor is using text from pre-5378 Material in a > document after RFC 5378 was published. The text was only available > for reuse within the IETF Standards Process as the Contributor has > not been given rights according to RFC 5378 from the author of that > text for reasons stated previously. > > The new Contributor would like to say that the document contains > Pre-5378 Material and he/she can only give rights for modifications > within the IETF Standards Process. The new Contributor is unable to > give any rights for non-IETF derivative works as that falls outside > the Internet Standards Process. > > This is not about the new Contributor "does not wish" or "elects" to > withhold the rights as he/she does not have a choice in the matter. > > Regards, > -sm > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] Last Call for Comments: Proposed work-around to thePre-5378 Problem
Title: Re: [Trustees] Last Call for Comments: Proposed work-around to thePre-5378 Problem John - thanks for that clarification. Would "elect" be less value-laden than "wish"? - Original Message - From: John C Klensin To: Contreras, Jorge; Thomas Narten ; Ray Pelletier Cc: Trustees ; wgcha...@ietf.org ; ietf@ietf.org ; i...@iab.org ; i...@ietf.org ; rfc-edi...@rfc-editor.org Sent: Sun Feb 08 17:38:10 2009 Subject: RE: [Trustees] Last Call for Comments: Proposed work-around to thePre-5378 Problem --On Sunday, February 08, 2009 5:24 PM -0500 "Contreras, Jorge" wrote: > Sorry for jumping into this thread late, but I would recommend > leaving 6.c and 6.c.iii as proposed in the TLP draft that was > circulated. > > 6.c.iii > >> OLD: >> >> > iii. If a Contribution includes Pre-5378 Material and the >> > Contributor does not wish to allow modifications of such >> > Pre-5378 Material to be made outside the IETF Standards >> > Process: >> >> "does not wish" is not right. The issue is that the current >> author of the document is unable (for whatever reason) to >> make assertions about the pre-5378 material. > > I think "does not wish" is right, as it gives the new > Contributor maximum flexibility in withholding the right to > make non-IETF derivative works if his Contribution includes > pre-5378 Material. I don't see any of the proposed changes > making this clearer or better. >... Jorge, I think people are trying to make two specific points. If you tell us that both are irrelevant, then I, for one, will accept that and move on. The points are: (1) This language should not let a submitting author (a term that is a tad more precise than "Contributor" for this purpose, but substitute as you like) off the hook for compliance with the letter and intent of 5378 for his or her one new, post whenever-November-10-is, contribution. If the Note Well, or 5378 itself, or something else, takes care of that regardless of what the workaround text says, it would be helpful to clarify that somewhere. (2) As a submitting author, I may be so convinced that 5378 is a wonderful thing that I would dearly wish, with all of my might, that I could offer a document in full compliance with its text and intent. But I may just not have enough rights to do that (something wishing is unlikely to cure) and hence have to opt for IETF use only. Some of us would like to avoid an assertion that we "wish" to not provide the broader rights as it may be counterfactual. That distinction may make absolutely no difference from an IPR standpoint, but some of us have an allergy to IETF procedural rules that require people to assert things that aren't true. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Trustees] Last Call for Comments: Proposed work-around to thePre-5378 Problem
Sorry for jumping into this thread late, but I would recommend leaving 6.c and 6.c.iii as proposed in the TLP draft that was circulated. 6.c.iii > OLD: > > > iii. If a Contribution includes Pre-5378 Material and the > > Contributor does not wish to allow modifications of such Pre-5378 > > Material to be made outside the IETF Standards Process: > > "does not wish" is not right. The issue is that the current author of > the document is unable (for whatever reason) to make assertions about > the pre-5378 material. I think "does not wish" is right, as it gives the new Contributor maximum flexibility in withholding the right to make non-IETF derivative works if his Contribution includes pre-5378 Material. I don't see any of the proposed changes making this clearer or better. PROPOSED > > iii. If a Contribution includes Pre-5378 Material for which the > > Contributor of the pre-5378 material has not or may not have > > granted the necessary permissions to the IETF Trust to allow > > modifications of such Pre-5378 Material to be made outside the > > IETF Standards Process: This language seems unnecessarily dense, and since it includes "may not", it has the same effect as "does not wish", doesn't it? In other words, if a Contribution includes pre-5378 Material, the (new) Contributor should have the absolute discretion whether or not to withhold the derivatives right and should not have to make any kind of legal determination whether or not the old Contributor has granted necessary permissions. 6.c OLD c. Derivative Works and Publication Limitations. If a Contributor desires to limit the right to make modifications and derivative works of an IETF Contribution, or to limit its publication, one of the following notices must be included. PROPOSED > c. Derivative Works and Publication Limitations. If a > Contributor desires to limit its publication, or the > Contribution includes pre-5378 Material that limits the right > to make modifications and derivative works of an IETF > Contribution, one of the following notices must be included. > The notices set forth in clauses (i) and (ii) below may not be > used with any standards-track document, nor with most working > group documents. Same issue (other than the problem that there is no antecedent to the pronoun "its" in line 2). Using "that limits" in line 3 implies that the new Contributor must make a legal determination about the rights in pre-5378 Material, which I do not think is the desired approach. > -Original Message- > From: trustees-boun...@ietf.org > [mailto:trustees-boun...@ietf.org] On Behalf Of Thomas Narten > Sent: Friday, February 06, 2009 2:02 PM > To: Ray Pelletier > Cc: Trustees; wgcha...@ietf.org; ietf@ietf.org; i...@iab.org; > i...@ietf.org; rfc-edi...@rfc-editor.org > Subject: Re: [Trustees] Last Call for Comments: Proposed > work-around to thePre-5378 Problem > > Ray, > > > > NEW: > > > > > >iii. If a Contribution includes Pre-5378 Material and the > > >Contributor is unable (for whatever reason) to obtain the > > >necessary permissions to allow modifications of such Pre-5378 > > >Material to be made outside the IETF Standards Process: > > > The language suggests a tasking to obtain 5378 licenses from > > contributors of pre-5378 material. I think that is something we > > want to avoid. I think the following language obtains the same > > results but with less stress on the participants. > > I agree, but that might also be seen to be getting closer to > overruling what RFC 5378 says, something that I understand to be out > of scope. > > > iii. If a Contribution includes Pre-5378 Material for which the > > Contributor of the pre-5378 material has not or may not have > > granted the necessary permissions to the IETF Trust to allow > > modifications of such Pre-5378 Material to be made outside the > > IETF Standards Process: > > IMO, this is improved wording I support it. > > Thanks, > Thomas > ___ > 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: ANNOUNCEMENT: The IETF Trustees invite your comments on revised proposed legend text to work-around the Pre-5378 Problem
> -Original Message- > From: John C Klensin [mailto:john-i...@jck.com] > Sent: Friday, January 23, 2009 1:15 AM > To: Ed Juskevicius > Cc: ietf@ietf.org; ietf-annou...@ietf.org; wgcha...@ietf.org; > i...@iab.org; i...@ietf.org; rfc-edi...@rfc-editor.org; > 'Trustees'; Contreras, Jorge > Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your > comments on revised proposed legend text to work-around the > Pre-5378 Problem > ... > I wonder if > "Without obtaining... this document may not be modified > outside..." is a stronger assertion than the Trust is in a > position to make. Would it not be preferable (and several words > shorter) to just say something like "The IETF Trust cannot give > permission for modifications of this document outside the IETF > Standards Process, nor for derivative works outside the IETF > Standards Process, except ..." (translated into appropriate > legal language, of course). > > That way, you are giving no advice at all about licenses or > people who might have rights. You also aren't telling people > what they can't do, only what you don't have enough permission > or ownership to tell them they can do. That just feels better > to me. Actually, those words are included in a legend that will be applied by document authors. Thus, the "speaker" is the author, not the Trust. The author is telling the Trust (and everyone else) that derivatives cannot be made to the pre-5378 material. Does that help with your discomfort? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: RFC 5378 "contributions"
the Contribution was made. > > > john > > * I've said this several times before, but neither common sense > nor fairness permits the IETF to say "RFC 5378 became effective > when it was published the first week in November, therefore any > comments, contributions or drafts that appeared after that date > constitute grants of permission under 5378's rules" ... > especially in the absence of any specific notice to that effect > on relevant mailing lists, the presence of a Note Well in the > IETF registration packet that referred to the old rules, etc. > Those of us who trust that common sense interpretation (or who > have been given legal advice that the odds of a judge accepting > an early-November date contrary to that interpretation are > fairly small) need to behave as if we cannot assume that > Contributions made before late November or early December do not > imply permission to use the Contributions under 5378 rules. > > --On Wednesday, January 14, 2009 22:52 -0500 Andrew Sullivan > wrote: > > > On Wed, Jan 14, 2009 at 08:33:35PM -0500, Contreras, Jorge > > wrote: > >> No, absolutely not. Use of pre-5378 materials in the > >> IETF standards process has never been an issue, only use > >> outside the IETF is problematic (ie, allowed under 5378 but > >> not the earlier rules). > > > > Why is the actual situation of the use relevant? > > "Contribution" is defined in section 1a of RFC 5378, and it > > plainly says that mailing list posting and anything one says > > at the microphone in any meeting is included in the > > definition. In section 5.1, RFC 5378 says that, by submitting > > the Contribution, the Contributor is "deemed to have agreed > > that he/she has obtained the necessary permissions" to enter > > into the agreement allowing the IETF to use the Contribution > > according to the new rules. > > > > So, just because the Contribution doesn't _happen_ to end up > > in use outside the IETF by virtue of the IETF's actions does > > not mean that a Contributor doesn't have to obtain the rights > > to allow such re-use. I believe that the _intent_ of 5378 is > >... > > ___ > 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: RFC 5378 "contributions"
Title: Re: RFC 5378 "contributions" No, absolutely not. Use of pre-5378 materials in the IETF standards process has never been an issue, only use outside the IETF is problematic (ie, allowed under 5378 but not the earlier rules). - Original Message - From: ietf-boun...@ietf.org To: IETF Discussion Sent: Wed Jan 14 19:32:27 2009 Subject: RFC 5378 "contributions" Hi - I originally asked this question on the WG chairs' list, and was asked to ask again here... The discussion about RFC 5378 (what little I've been able to understand of it, anyway) has focussed on I-Ds and RFCs. However, the definition of "contribution" in that document includes, among other things, mailing list discussions. Does this mean that we need to get contributor permission before using, for example, material from a pre-5378 RFC in a mailing list discussion, or before including text from a pre-5378 email posting in an internet draft? This seems really silly, but that's what the discussion is starting to sound like to me. Randy ___ 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 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
RFC 5378 Trademarks (was where to send RFC 5378 license forms)
> > On Fri, Dec 19, 2008 at 5:30 AM, Simon Josefsson > wrote: > > ... > >> If you are updating a pre-RFC 5378 document that contains > trademarked > >> words, it isn't sufficient for the old contributor to have > signed the > >> IETF Trust form if the document contains trademarks. You need to > >> contact him anyway, to get permission to reproduce the trademark. > >> > >> /Simon > > > > You should consult an attorney but, as far as I know, at > least in the > > US, there is no magic permission needed to "reproduce" a trademark. > > Usually trademarks are to indicate the source of a product > or service > > and as long as you don't mislead people about that, you are fine. > > Then what use does section 3.4 of RFC 5378 serve? > > 3.4. Rights to Use Trademarks > >Contributors may wish to seek trademark or service mark > protection on >any terms that are coined or used in their Contributions. The IETF >makes no judgment about the validity of any such trademark rights. >However, the IETF requires each Contributor, under the licenses >described in Section 5.3 below, to grant the IETF Trust a perpetual >license to use any such trademarks or service marks solely in >exercising rights to reproduce, publish, discuss, and > modify the IETF >Contribution. This license does not authorize the IETF or > others to >use any trademark or service mark in connection with any product or >service offering. > > It was co-authored by the IETF attorney, so I suspect it is > intended to > serve some purpose. > > If it serves a purpose, contributors needs to get the necessary right > and be able to transfer it to the IETF Trust in order to submit a > contribution. As far as I understand, that would involve talking with > the old contributor if trademarks are involved. For background, the trademark license was included in RFC 3978 because someone was concerned about Contributors who submitted documents to IETF for standards-track use and included trademarked product names in them. The IETF wanted to ensure that the IETF process would not be hindered by the Contributor, and also wanted to ensure that the trademarks were identified so that implementers would not be surprised by the trademark owner's claim after a standard was adopted. While it's true that trademark *infringement* requires an infringing use (i.e., use on a product or service), and that IETF would likely not be engaged in such an infringing use, the US also gives owners of "famous" marks the ability to sue for trademark "dilution", which does not require an infringing use. To be absolutely safe, the IETF has requested the trademark license to avoid any infringement or dilution suit. This being said, for the sake of completeness, the Contributor License should probably include both trademark and copyright grants (thanks to Simon for identifying this). However, given that RFC 3978 includes the same trademark license as 5378, the issue only exists for pre-3978 documents. Moreover, RFC 2026 requires identification (via IPR disclosure) of any IPR rights relating to Contributions, which technically would include trademarks. If a Contributor did not identify the relevant trademarks in an IPR disclosure (a rare occurrence), then one would question the enforceability of those trademarks against IETF. Pre-2026 IPR policies such as those contained in RFC 1602 and 1310 include wording relating to rights that could also include trademarks. Thus, I think that including a trademark grant in the Contributor License would be an improvement, but don't view this as a large issue in any case. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
Title: Re: where to send RFC 5378 license forms Yes, I think we mention federal works in 5378. Unfortunately I don't think there are a lot of them, but have not done an inventory. - Original Message - From: Marshall Eubanks To: Contreras, Jorge Cc: Simon Josefsson ; Harald Alvestrand ; Randy Presuhn ; IETF Discussion Sent: Fri Dec 19 19:11:46 2008 Subject: Re: where to send RFC 5378 license forms Dear Jorge; On Dec 19, 2008, at 2:13 PM, Contreras, Jorge wrote: > > >>>> (I tracked the first sentence of the "Managed objects are accessed" >>>> phrase back to RFC 1065, August 1988; authors-of-record >> were Marshall >>>> Rose and Keith McCloghrie. There were drafts before that, >> of course.) >>> >>> That date is before RFC 1310 which makes things more interesting. >>> >>> Even more interesting is that the date is before 1 March >> 1989, when >>> the >>> US signed the Berne convention. According to: >>> >>> http://www.copyright.cornell.edu/public_domain/ >>> >>> 1978 to 1 March 1989 >>> Published without notice, and without subsequent >> registration within >>> 5 years >>> In the public domain >> >> I had forgotten that - the Trust Counsel should give a >> reading on this. > > Indeed -- I don't see a copyright notice in RFC 1065. This may be a > useful approach for old RFCs that lack a copyright notice. Does > anyone > know when the ISOC copyright notice was first applied to RFCs? > Also do not forget that the US Government does not claim copyright. Were any RFCs written by US Civil Servants ? Then their work is in the Public Domain. Regards Marshall ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: where to send RFC 5378 license forms
> >> As a slightly harder example: what is the set of names > >> required to cover > >> all the boilerplate text that goes into an RFC containing a > >> MIB module? > > > > See above. In addition, MIB modules were licensed broadly > > under RFC 3978, so they are less problematic than non-code > > text. > > Maybe I still don't fully understand what 5398 does, but, while > that broad licensing of MIB modules presumably permits the IETF > (and others) to work with them, it doesn't imply the transfers > to the Trust, and ability of the Trust to relicense, required by > 5398, does it? Yes it does -- see below > And, if not, the broad licensing of MIB modules > doesn't help a new author of a document that incorporates a MIB > module make the assertions that 5398 requires, does it? > > If the answer is "no", then such an author would still have to > go back to the original Contributor(s) of the MIB module and > persuade them to generate the new license, just as he or she > would with any other older contributed text. Right? My point was that code was already broadly licensed under the OLD copyright rules in 3978, so the post-5378 contributor doesn't face the same predicament when he/she re-uses pre-5378 code as when he/she re-uses pre-5378 text (i.e., his/her warranty is TRUE when made with respect to pre-5378 code fragments). Here's the code license granted under 3978: (E) to extract, copy, publish, display, distribute, modify and incorporate into other works, for any purpose (and not limited to use within the IETF Standards Process) any executable code or code fragments that are included in any IETF Document (such as MIB and PIB modules), ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: History of RFC copyright text
Dave -- very useful -- thanks!! > -Original Message- > From: Dave CROCKER [mailto:d...@dcrocker.net] > Sent: Friday, December 19, 2008 3:56 PM > To: IETF Discussion > Cc: Contreras, Jorge > Subject: History of RFC copyright text > > > > Bob Braden wrote: > >> Indeed -- I don't see a copyright notice in RFC 1065. > This may be a > >> useful approach for old RFCs that lack a copyright notice. > Does anyone > >> know when the ISOC copyright notice was first applied to RFCs? > > > > Probably some time after 1989, when the ISOC took over > funding of the > > RFC Editor. I don't recall exactly, but it should not be > hard to find out. > > > This is probably worth summarizing, so I just did a scan of > the RFC archive: > > > > > 1) There is no copyright text in RFCs until: > > > > Network Working Group > M. Gahrns > > Request for Comments: 2221 > Microsoft > > Category: Standards Track > October 1997 > > > > > > IMAP4 Login Referrals > ... > > Copyright Notice > > > >Copyright (C) The Internet Society (1997). All Rights Reserved. > ... > > 10. Full Copyright Statement > > > > > >Copyright (C) The Internet Society (1997). All Rights Reserved. > > > >This document and translations of it may be copied and > furnished to > >others, and derivative works that comment on or > otherwise explain it > >or assist in its implmentation may be prepared, copied, published > >andand distributed, in whole or in part, without > restriction of any > >kind, provided that the above copyright notice and this > paragraph are > >included on all such copies and derivative works. However, this > >document itself may not be modified in any way, such as > by removing > >the copyright notice or references to the Internet > Society or other > >Internet organizations, except as needed for the purpose of > >developing Internet standards in which case the procedures for > >copyrights defined in the Internet Standards process must be > >followed, or as required to translate it into languages > other than > >English. > > > >The limited permissions granted above are perpetual and > will not be > >revoked by the Internet Society or its successors or assigns. > > > >This document and the information contained herein is > provided on an > >"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING > >TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, > INCLUDING > >BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > >HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > >MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." > > > > > > 2) In my view, the next change was the critical one, because > it altered the > ownership model, with authors being declared as having > ownership rights (where > my non-lawyers eyes read the earlier one as declaring ISOC as > owning the rights, > modulo the ones authors can't give away): > > > > Network Working Group > J. Cuellar > > Request for Comments: 3693 > Siemens AG > > Category: Informational >J. Morris > >Center for Democracy > & Technology > > > D. Mulligan > > Samuelson Law, Technology & Public > Policy Clinic > > > J. Peterson > > > NeuStar > > > J. Polk > > >Cisco > > > February 2004 > > > > > > Geopriv Requirements > ... > > > > Copyright Notice > > > >Copyright (C) The Internet Society (2004). All Rights Reserved. > ... > > 13. Full Copyright Statement > > > > > >Copyright (C) The Internet Society (2004). This > document is subject
RE: IPR Questions Raised by Sam Hartman at the IETF 73 Plenarys
Larry - thank you for your contribution! > I further want to comment that, as far as I can tell, it may > not even be > necessary to get *everyone* to sign. Here's the reason: Most > RFCs are joint > works. Quoting (FWIW) from my own book on the subject of licensing: > > "In the United States, unless they agree otherwise, each of the joint > authors may separately license a joint work--and all of its > parts--without > the consent of any of the other joint authors, and every > author must account > to the other authors for their share of the profits derived from the > license. Consult local law to determine whether one owner of > a joint work > may license without the consent of the others or must account > to the others > for his or her licensing revenue." The problem lies with collective works, rather than joint works. In some cases, the multiple authors of IETF documents have each made distinct contributions (i.e., sections or distinct text) rather than collaborating to produce joint text. Unfortunately it is not possible, in hindight, to determine whether works with multiple authors are joint works or collective works. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: where to send RFC 5378 license forms
> >> (I tracked the first sentence of the "Managed objects are accessed" > >> phrase back to RFC 1065, August 1988; authors-of-record > were Marshall > >> Rose and Keith McCloghrie. There were drafts before that, > of course.) > > > > That date is before RFC 1310 which makes things more interesting. > > > > Even more interesting is that the date is before 1 March > 1989, when > > the > > US signed the Berne convention. According to: > > > > http://www.copyright.cornell.edu/public_domain/ > > > > 1978 to 1 March 1989 > > Published without notice, and without subsequent > registration within > > 5 years > > In the public domain > > I had forgotten that - the Trust Counsel should give a > reading on this. Indeed -- I don't see a copyright notice in RFC 1065. This may be a useful approach for old RFCs that lack a copyright notice. Does anyone know when the ISOC copyright notice was first applied to RFCs? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: where to send RFC 5378 license forms
> Who owns the oft-repeated >The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this >document are to be interpreted as described in [RFC2119]. > I'm referring to the bits effectively required by the MIB > doctors, e.g.: >This memo defines a portion of the Management Information > Base (MIB) >for use with network management protocols in the Internet > community. >In particular, it defines a basic set of managed objects for Simple >Network Management Protocol (SNMP)-based management of ... > > and >For a detailed overview of the documents that describe the current >Internet-Standard Management Framework, please refer to > section 7 of >RFC 3410 [RFC3410]. > >Managed objects are accessed via a virtual information > store, termed >the Management Information Base or MIB. MIB objects are generally >accessed through the Simple Network Management Protocol (SNMP). >Objects in the MIB are defined using the mechanisms defined in the >Structure of Management Information (SMI). This memo > specifies a MIB >module that is compliant to the SMIv2, which is described > in STD 58, >RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 >[RFC2580]. > > and various incarnations of this stuff that appear in the text of RFCs > that happen to contain MIB modules, not the stuff that's in > the MIB modules. > (Earlier versions of this were rather lengthy.) I will check into this. Ideally, all boilerplate would be owned by the IETF Trust, but I am not aware that anyone has ever focused on this material. Technically, the copyright owner would be the author(s) who wrote the first document that says those words. However, the copyright in such generic phrases is vestigial at best. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: where to send RFC 5378 license forms
> -Original Message- > From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] > Sent: Thursday, December 18, 2008 5:52 PM > To: Contreras, Jorge > Cc: Randy Presuhn; IETF Discussion > Subject: Re: where to send RFC 5378 license forms > > Jorge, > > I'm working on the assumption that once a contributor or a > contributor's assign has signed the license form in its > RFC5378 version, we can all submit drafts including that > contributor's earlier text without further ado. Is that correct? > > Brian That's right. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: where to send RFC 5378 license forms
> Just as a simple "for example": what is the set of names that > needs to be > posted just to cover all of the boilerplate text we're > required to put in our > documents? The boilerplate text is owned by the IETF Trust. No author permissions are needed. > As a slightly harder example: what is the set of names > required to cover > all the boilerplate text that goes into an RFC containing a > MIB module? See above. In addition, MIB modules were licensed broadly under RFC 3978, so they are less problematic than non-code text. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Draft Trust Policy re: Rights in IETF Documents
Dropping "for the avoidance of doubt" is fine. The ability to prohibit derivative works of I-Ds is still allowed, just as it was under 3978. See Section 6.b of this document. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of C.T. Aiken Sent: Friday, July 18, 2008 9:55 AM To: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: Draft Trust Policy re: Rights in IETF Documents Until "7f" that all sounds good, but I'm not sure about "7f": > ADD - For the avoidance of doubt, each Contributor to the > IETF Standards Process licenses each Contribution that he > or she makes as part of the IETF Standards Process to the > IETF Trust pursuant to the provisions of [-Inbound]. No > language to the contrary, or terms, conditions or rights > that differ from or are inconsistent with the rights and > licenses granted under BCP 78, shall have any effect and > shall be null and void, whether published or posted by such > Contributor, or included with or in such Contribution. That also sounds right for published RFCs. But apparently it's not limited to RFCs and affects *all* Contributions. SNIP Apparently there is an exception. Maybe that's perfectly clear in your text, and I just don't see it (IANAL). I agree with Frank, the disparity needs to be resolved. After looking at both documents, I couldn't see a way to reconcile the two. Also, petty point, but it would make sense to strike "for the avoidance of doubt" from 7f. I don't see what, if anything, it adds. C.T. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
> Ted, jumping ahead a little bit, how much of your concern would > be eliminated if that entry in the template said "Royalty Free > and RAND" (or "RAND and Royalty Free"), rather than just RF? I > agree that "RF and totally unreasonable" is a possible case, but > am trying to understand whether we have a disconnect about the > language we have used or about some general and important > principle? A useful convention that's being used more and more is the term RANDz, which means "RAND without monetary compensation". This captures both the monetary aspect as well as the reasonableness of other terms. Of course, to avoid any uncertainty, it would be helpful to define RANDz somewhere in the IETF policy documents (RFC 3979, etc.). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: MUST implement AES-CBC for IPsec ESP
Larry, Please note that any responses to your question "Are any of these encryption algorithms patented?" are being provided by individuals in the spirit of helpfulness and open sharing of information. Neither IETF nor the IETF Trust provide assurances or advice as to whether or not technology covered by IETF standards are covered by patent claims. The exclusive mechanism for soliciting and disclosing patent claims within the context of IETF activity is specified in RFC 3979, as we have discussed before. Please do not take anyone's efforts to respond to your questions as "official" IETF positions, as they are not and may not be relied upon as such. Regards, Jorge > -Original Message- > From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 20, 2007 6:28 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; ietf@ietf.org; [EMAIL PROTECTED] > Subject: Re: MUST implement AES-CBC for IPsec ESP > > > On Sat, 20 Jan 2007 14:45:26 -0800 > "Lawrence Rosen" <[EMAIL PROTECTED]> wrote: > > > > > For ESP encryption algorithms, the document that was > sent out for > > > > Last Call contains the following table: > > > > > > > > RequirementEncryption Algorithm (notes) > > > > --- > > > > MUST NULL (1) > > > > MUST- TripleDES-CBC [RFC2451] > > > > SHOULD+AES-CBC with 128-bit keys [RFC3602] > > > > SHOULD AES-CTR [RFC3686] > > > > SHOULD NOT DES-CBC [RFC2405] (3) > > > > > > > > The Last Call comment suggests changing the "SHOULD+" > for AES-CBC > > > > to "MUST." > > > > Are any of these encryption algorithms patented? > > > > Almost certainly not. DES was patented, but the patent was never > enforced; it has long since expired. (Trivia: IBM filed a statement > saying that DES was royalty-free *if* used in one of the > NIST-approvedd > modes of operation. But they never went after anyone who used it in > other ways.) To my knowledge, 3DES was never patented; even if it had > been, it was first publicly described in 1979, so I doubt that any > patent would still be valid. > > AES itself had to be unencumbered; see > http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/aes_9709.htm#sec2d . > The designers of Rijndael never even attempted to patent it; see the > text quoted in RFC 3602 or the old Rijndael home page. > > CBC dates from at least 1980 -- I seem to recall 1978, but I > don't have > a citation handy. > > That leaves CTR mode. I doubt very much that it's patented, > since it's > been very well known for many years and NIST rarely standardizes > patented algorithms in this space (which I know you appreciate...). > However, I don't have any citations to prove this negative. > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Copyright status of early RFCs
Take a look at Section 5.4 of RFC 1602, which redefined the IETF's IP process originally set forth in RFC 1310: 5.4. Rights and Permissions In the course of standards work, ISOC receives contributions in various forms and from many persons. To facilitate the wide dissemination of these contributions, it is necessary to establish specific understandings concerning any copyrights, patents, patent applications, or other rights in the contribution. The procedures set forth in this section apply to contributions submitted after 1 April 1994. For Internet standards documents published before this date (the RFC series has been published continuously since April 1969), information on rights and permissions must be sought directly from persons claiming rights therein. -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Friday, April 07, 2006 10:44 AM To: Carl Malamud Cc: ietf@ietf.org Subject: Re: Copyright status of early RFCs Carl Malamud wrote: > John and Brian - > > My jaw dropped when I saw this query come through. > > I thought that wide replication of the series was the whole > point. It is. And I can tell you that the IETF Trust's firm intention is to maintain this. But the IETF, and the Trust on behalf of the IETF, can't convey rights it doesn't own, and the question was about early RFCs. The IETF is a mere 20 years old, younger than RFC 791 for example. (BTW we should have celebrated the 25th anniversary of that, I think.) > If there are issues, I thought they had to do with derivative > works. For example, a particularly risk-averse author of a new > book might query whether "publication of 3 random pages from each > RFC" falls within the scope of allowable actions. > > I would take the position that checking with authors is not necessary > because permission has already been granted for replication of unmodified > RFCs. It would not seem a stretch for the IETF chair, the IAB, and > the RFC Editor to take a similar position. But we are not lawyers. The legal advice has consistently been to also check with the original authors. That's all I can tell you. > If a position is taken to the contrary, I would be more than happy > to undertake the publishing project and invite the relevant parties > to bring legal action I'd guess that for all the RFCs that carry the magic words "Distribution of this memo is unlimited" you'd be on fairly safe ground. But those words aren't in the early RFCs. Brian > Carl > > >>John, >> >>At the moment there has been no transfer of rights in the early >>RFCs to the IETF Trust, so I think you need to ask the >>RFC Editor, or simply look at >>http://www.rfc-editor.org/copyright.23Jan01.html >> >>IANAL, but I have been told that in any case it is necessary >>to check with the original authors. >> >>Brian >> >>John Levine wrote: >> >>>A friend of mine wants to include copies of some early RFCs in a book. >>> >>>My understanding is that anything published before 1976 without a >>>copyright notice, which would presumably include RFCs up through about >>>number 700, is in the public domain. >>> >>>Does the IETF or IAB or RFC Editor take a position on this? >>> >>>Regards, >>>John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for >>>Dummies", >>>Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor >>>"More Wiener schnitzel, please", said Tom, revealingly. >>> >>> >>>___ >>>Ietf mailing list >>>Ietf@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ietf >>> >>> >> >>___ >>Ietf mailing list >>Ietf@ietf.org >>https://www1.ietf.org/mailman/listinfo/ietf >> > > > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPR language in IASA BCP (fwd)
>In reviewing the IASA BCP I noticed a minor issue: >S 2.2 and 3.1 refer to "perpetual right to use, display, etc." >The standard language here typically includes both "royalty-free" >(or "fully-paid up") and "irrevocable". I would particularly think >we want to specify that no future royalties are due. Actually, that would be a fairly major issue. Right now, the language prescribes the rights that IASA needs to obtain on behalf of the IETF, but it does not impose a requirement on how much IASA can pay, or the terms of payment. Those are left to IASA and the IAS's discretion/negotiation. Adding the language you suggested would mean that IASA could not buy royalty-bearing or installment-fee software. Adding the part about "irrevocability" would mean that the licensor could not terminate the license if IETF breached. While this would be nice, most commercial licensors would refuse to license their software on that basis. Do you really want to impose these types of constraints on IASA? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- End Forwarded Message -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Perhaps clarify: #825 - IASA responsibilities regarding IPR
>P.S: I'm prepared to live with whatever Jorge recommends; but I'd really >prefer to avoid open-ended reassignments. I'm not really advocating one position or the other, but I can say that IASA wouldn't be co-opting any functions of the IP-WG. Rather, this all relates to IPR that IETF itself gets (e.g., in the IETF databases, lists, etc.) It would have little to do with the IPR in standards and standards-track documents. -Original Message- From: John Leslie [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 01, 2005 3:24 PM To: Wijnen, Bert (Bert) Cc: Margaret Wasserman; Contreras, Jorge; Harald Tveit Alvestrand; ietf@ietf.org Subject: Re: Perhaps clarify: #825 - IASA responsibilities regarding IPR Wijnen, Bert (Bert) <[EMAIL PROTECTED]> wrote: > To: Margaret Wasserman <[EMAIL PROTECTED]>, >> At 12:16 PM +0100 2/1/05, Wijnen, Bert (Bert) wrote: >>> >>> The IASA is responsible for managing all intellectual >>> property rights (IPR), including but not limited to >>> trademarks, and copyrights, that belong to the IETF. I must admit to thinking we were moving away from all-inclusive language here. As I read this, we'd be _asking_ the IASA to constantly increase the scope of this responsibility as folks allege that new areas should be considered "Intellectual Property Rights". >> Is this really what we want to say? > > I believe so. The above is theadditional responsibility for IASA. I'm afraid I don't understand this reply. >> Or do we want to say something like: >> >> The IASA is responsible for managing all intellectual property rights >> (IPR) related to IETF administrative support, including but not >> limited to trademarks, copyrights, attendance lists, tools, etc.? >> >> We have an IPR WG and have undertaken a mammoth effort to define our >> standards-related IPR and how that will be assigned and managed, and >> I am not sure that we want to hand management of that IPR over to the >> IASA/IAOC, do we? Given the number of the people in the community >> that were involved/interested in that effort, I think that we may >> continue to want direct community control over the standards-related >> IPR. Clearly there are some things we _do_ want to hand over to IASA; but a blanket redirection of everything the IPR WG (and others) have been working on _to_ the IASA seems out of line with what has been discussed. P.S: I'm prepared to live with whatever Jorge recommends; but I'd really prefer to avoid open-ended reassignments. -- John Leslie <[EMAIL PROTECTED]> ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Perhaps clarify: #825 - IASA responsibilities regarding IPR
- Please spell out "intellectual property rights". > I think that IPR was defined elsewhere - Domain names are not IPR. > For this purpose, I would treat them like IPR - What about patents? > IETF should not be getting patents on anything. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Perhaps clarify: #825 - IASA responsibilities regarding IPR
>I suggest we change the text in section 3 from: > The IASA is responsible for undertaking any and all required actions > that involve trademarks on behalf of the IETF. > >to: > > The IASA is responsible for managing all IPR, including but not > limited to trademarks, domain names, and copyrights, that belongs > to the IETF. It is responsible for undertaking any and > all required actions on behalf of the IETF to obtain, protect and > manage the rights that the IETF needs to carry out its work. >I'm sure Jorge could phrase it better. but I think the meaning >is clear. That looks good. In line 2, "belongs" should be "belong", but otherwise I don't have any other improvements. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Legal review results 1: Intellectual property
> If we assume that the IETF will never be interested in preventing others
> from using its software, we can remove the stuff that says ".. and ISOC
> will not utilize or access. without the written consent of the IAD".
> Jorge - see any problems with removing this?
JLC> No problem.
>We should perhaps ask Jorge to modify his words to ensure that they don't
>preclude IASA from using or contributing to open source software
JLC> I had tried to ensure this, but if there's something that seems
to be a problem I'm all for fixing it!
By the way, this language related primarily to IASA's rights
in software developed for it by someone else, and didn't really
have much to do with software developed by IASA itself. IASA/IETF
is completely free to contribute to open source projects with software
developed by IASA personnel, to the extent that there are any.
-Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: Monday, January 24, 2005 9:34 AM
To: Harald Tveit Alvestrand
Cc: ietf@ietf.org; Contreras, Jorge
Subject: Re: Legal review results 1: Intellectual property
Harald Tveit Alvestrand wrote:
> (explicit CC to Jorge, since I'm interpreting his words)
>
> --On fredag, januar 21, 2005 10:49:21 -0500 Bruce Lilly
> <[EMAIL PROTECTED]> wrote:
>
>> Verbosity aside, I don't believe that "sole control and custodianship"
>> applies to open source software. I am not a lawyer, but the "Old text"
>> seems not only more easily comprehended [I am reminded of Jonathan
>> Swift's satirical look at lawyers in Gulliver's Travels, and dismayed
>> that things haven't improved in 275 years] but seems to be considerably
>> more favorable to open source software than the proposed "new text";
>> the latter appears to be heavily biased towards commercial software.
>
>
> On reading the text again, I think this text:
>
>> (B) If an IASA Contract provides for the creation, development or
>> modification of any software (including, without limitation, any
>> search tools, indexing tools and the like) ("Developed Software")
>> then the IAD shall, whenever reasonable and practical, ensure
>> that such contract either (a) grants ownership of such Developed
>> Software to ISOC, or (b) grants ISOC a perpetual, irrevocable
>> right, on behalf of IASA and IETF, to use, display, distribute,
>> reproduce, modify and create derivatives of such Software
>> (including, without limitation, pursuant to an open source style
>> license). It is preferred that Developed Software be provided and
>> licensed for IASA and IETF use in source code form.
>> ISOC will permit IASA and its designee(s) to have sole control and
>> custodianship of such Developed Software, and ISOC
>> will not utilize or access such Developed Software in
>> connection with any ISOC function other than IETF without
>> the written consent of the IAD. The foregoing rights are not required
>> in the case of off-the-shelf or other commercially-available software
>> that is not developed at the expense of ISOC.
>
>
> actually is OK for making software free - that would come under the
> section that says:
>
>> or (b) grants ISOC a perpetual, irrevocable
>> right, on behalf of IASA and IETF, to use, display, distribute,
>> reproduce, modify and create derivatives of such Software
>> (including, without limitation, pursuant to an open source style
>> license).
>
>
> If we assume that the IETF will never be interested in preventing others
> from using its software, we can remove the stuff that says ".. and ISOC
> will not utilize or access. without the written consent of the IAD".
> Jorge - see any problems with removing this?
>
> The "IASA and its designee(s)" says that IASA, not ISOC, decides to give
> others permission to use it - ISOC can't give orders to IASA to limit it.
>
We should perhaps ask Jorge to modify his words to ensure that they don't
preclude IASA from using or contributing to open source software.
Brian
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
