Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 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 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 ___ 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] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
On Mon, Jul 20, 2009 at 02:19:24PM -0400, Contreras, Jorge wrote: > > I also think that Harald's alternate language would work. Is it a problem that this means that shipping code's license could change at some time in the future? Are there practical issues to that if (for instance) the Trust decided to change from BSD to some copyleft-like license? Note that I'm thinking of shipping, and not already deployed, code. So one develops based on the BSD-licensed code, and then the license changes and you ship another instance. Is this a problem? I'm assuming not, because the original licensee still has the code under the original terms. But I thought it wouldn't hurt to ask. 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)
I don't think it means that. Rather, what it does is the RfC says "the code must include whatever license the trust document says. When the code is produced, that link is dereferenced, the license is determined, and the license is inserted in the code. No, no one can reasonably produce code under an unspecified license. What this does is allow the trust to change, in a forward-going fashion, what license code produced from the RFC must use. Otherwise, once the RFC came out, everyone must forever use BSD, even if the community decided that everyone should henceforth use ABC. Thus, it is a later binding, but not so late that the code user does not know what he is committing to when that person produces software using our code. Joel Andrew Sullivan wrote: On Mon, Jul 20, 2009 at 02:19:24PM -0400, Contreras, Jorge wrote: I also think that Harald's alternate language would work. Is it a problem that this means that shipping code's license could change at some time in the future? Are there practical issues to that if (for instance) the Trust decided to change from BSD to some copyleft-like license? Note that I'm thinking of shipping, and not already deployed, code. So one develops based on the BSD-licensed code, and then the license changes and you ship another instance. Is this a problem? I'm assuming not, because the original licensee still has the code under the original terms. But I thought it wouldn't hurt to ask. A ___ 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)
On Mon, Jul 20, 2009 at 02:56:01PM -0400, Joel M. Halpern wrote: > Rather, what it does is the RfC says "the code must include whatever > license the trust document says. > When the code is produced, that link is dereferenced, the license is > determined, and the license is inserted in the code. 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? 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)
Andrew Sullivan wrote: On Mon, Jul 20, 2009 at 02:56:01PM -0400, Joel M. Halpern wrote: Rather, what it does is the RfC says "the code must include whatever license the trust document says. When the code is produced, that link is dereferenced, the license is determined, and the license is inserted in the code. 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? 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? I agree completely that any licensing change needs solid community input and rough consensus (as well as being legal). That's entirely orthogonal to the binding time issue (I think). My worry is the logistics of executing the change. We have two possibilities: 1 - the update consists of revisions of *every single RFC* that references the BSD license 2 - some RFCs continue to carry the BSD license, even while the "real" current license is different. 1 seems like a logistical nightmare. 2 seems confusing to me. Harald ___ 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)
Date:Tue, 21 Jul 2009 08:57:01 +0200 From:Harald Alvestrand Message-ID: <4a6566bd.1080...@alvestrand.no> | We have two possibilities: | | 1 - the update consists of revisions of *every single RFC* that | references the BSD license | 2 - some RFCs continue to carry the BSD license, even while the "real" | current license is different. Harald, what you're anticipating there is absurd, if an RFC gets issued containing code with the BSD licence, then that is the licence that code, in that RFC will have forevermore, nothing can change that - and nothing should change that, nothng the trustees or community can do can ever change that - only the rights holder (author) of the code can cause it to be offered with some different licence.Any system where it even looked as if it were possible for anyone to simply alter the licence under which code that had previously been published became available would be a disaster. The issue is, and must be, entirely the licence under which code must be offered in order to be published - that the IETF can decide - no code in an RFC unless it has this licence on it (or one of those licences, or whatever the community wants). There is no obligation to publish code if it doesn't meet our requirements, but once we have published it, and the IETF and code authors have agreed upon licence terms for the code, the IETF (or trustees) cannot simplly arbitrarily change the licence. So, it seems to me as if what you're trying to accomplish is just absurd, we don't want to, or need to, go back and change old RFCs, the licence on code in those RFCs is, and always will be, whatever it says in that RFC (which doesn't stop the author also offering the same code, via other methods, with different licence terms - nor from one of those other methods being via the IETF, either via the web page, or in a new RFC. Given that, and the desire for considered community input, rather than arbitrary trustee action, I think the proposed wording is better than your proposed alternative. On he latter, Joel at least interpreted your original message as giving the TLP a status where ... j...@joelhalpern.com said: | Otherwise, once the RFC came out, everyone must forever use BSD, even if | the community decided that everyone should henceforth use ABC. which is impossible, nothing that we ever do can never be changed in the future (as it applies in the further future) - if we were to decide later that ABC is better than BSD, the TLP can be changed, just as they are now. The only question currently is the method by which that should happen, by an explicit community review process (just as now) or by simple trustee action, simply publishing a changed requirement. The original wording is the former, Harald's proposal suggests the latter. kre ___ 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)
On Tue, Jul 21, 2009 at 08:57:01AM +0200, Harald Alvestrand wrote: > We have two possibilities: > > 1 - the update consists of revisions of *every single RFC* that > references the BSD license > 2 - some RFCs continue to carry the BSD license, even while the "real" > current license is different. > > 1 seems like a logistical nightmare. 2 seems confusing to me. Ok, this is what I was trying to understand. What you are proposing is that the licence on the code in the RFC can change restrospectively, by virtue of the Trust changing the licence they select. This scenario is exactly what inspired my first question, then. Imagine I have a product, and it is shipping. It has code taken from an RFC. The original RFC was published when the Trust used the BSD licence. Therefore, as far as I know, the code I used is under BSD licence. Suppose now that the Trust now changes the licence they use to the GPL. (I know, I know, this won't happen, &c. But there's nothing to prevent it, as far as I can tell, except community consensus. I don't know what that might be in the future.) If I understand what you want, I think there are four possibilities: a. The product I have already shipped is now suddenly covered by the GPL. It may be in violation of the licence therefore. b. The prodict I have already shipped does not change, but products I ship after the Trust changes policy are covered under the new rules. So my shipped product is BSD, and my unshipped stuff is suddenly GPL (possibly forcing me to change my product, or its licence). c. The code I used remains under the BSD because of the date I used it, but new uses of that code are under GPL (so my competitors would have to have a different licence, or version 2 of my product might have to have a different licence). d. The date the RFC was published binds the licence, so that the terms on the code embedded in the RFC change. This is equivalent to your option (2), I think, and you say its undesirable. I argue that compared to (a-c), (d) is a big win. If (d) is right, however, your option (1) isn't a problem: the RFCs that are already published don't need a new licence in them, because they stick to the old one. Therefore, the new text only gives the Trust a way around getting a new RFC published with the new licence explicitly selected by community consensus. I don't see the reason to provide that short cut. If, however, you think (a-c) are preferable, then your proposed change makes sense. If I were building a product, however, I would be very wary of using any code whose licence might change after I've shipped my code. 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)
NO, I believe he is suggesting something slightly different. First, realize that the structure does not include any license statement with the code in the RFC. That is covered by the boilerplate. Second, the issue being addressed is the instruction to someone who extracts the code from the RFC and uses it. We are trying to allow them to do this. The instruction, as proposed by the trust says that we will put in the RFC text saying "when you extract this, put the BSD license, as defined by the trust at ..." Clearly, any change in IETF policy can not change the text in an RFC. Nor can it change what someone has done historically complying with that text. The issue is that we may discover that we would prefer that folks use a different license going forward. There are two ways to allow for that. 1) As proposed by Harald, we can just have the text in the RFC say "use what the trust says." If the trust changes what it says, then extractors thereafter have to comply with the new IETF policy. (We assume, for this discussion, that the trust statements and IETF policy align.) 2) Or, the trust can keep a chronological log of required license statements, and when a change is needed record "after date X, use license Y", and provide new boilerplate to be used in I-Ds and RFCs after date X. Mostly, it does not make a big difference. The historical records have to exist in any case. But given the pain that gratuitous boilerplate changes introduce, I would prefer not to need such for an easily foreseeable situation. Yours, Joel Andrew Sullivan wrote: On Tue, Jul 21, 2009 at 08:57:01AM +0200, Harald Alvestrand wrote: We have two possibilities: 1 - the update consists of revisions of *every single RFC* that references the BSD license 2 - some RFCs continue to carry the BSD license, even while the "real" current license is different. 1 seems like a logistical nightmare. 2 seems confusing to me. Ok, this is what I was trying to understand. What you are proposing is that the licence on the code in the RFC can change restrospectively, by virtue of the Trust changing the licence they select. This scenario is exactly what inspired my first question, then. Imagine I have a product, and it is shipping. It has code taken from an RFC. The original RFC was published when the Trust used the BSD licence. Therefore, as far as I know, the code I used is under BSD licence. Suppose now that the Trust now changes the licence they use to the GPL. (I know, I know, this won't happen, &c. But there's nothing to prevent it, as far as I can tell, except community consensus. I don't know what that might be in the future.) If I understand what you want, I think there are four possibilities: a. The product I have already shipped is now suddenly covered by the GPL. It may be in violation of the licence therefore. b. The prodict I have already shipped does not change, but products I ship after the Trust changes policy are covered under the new rules. So my shipped product is BSD, and my unshipped stuff is suddenly GPL (possibly forcing me to change my product, or its licence). c. The code I used remains under the BSD because of the date I used it, but new uses of that code are under GPL (so my competitors would have to have a different licence, or version 2 of my product might have to have a different licence). d. The date the RFC was published binds the licence, so that the terms on the code embedded in the RFC change. This is equivalent to your option (2), I think, and you say its undesirable. I argue that compared to (a-c), (d) is a big win. If (d) is right, however, your option (1) isn't a problem: the RFCs that are already published don't need a new licence in them, because they stick to the old one. Therefore, the new text only gives the Trust a way around getting a new RFC published with the new licence explicitly selected by community consensus. I don't see the reason to provide that short cut. If, however, you think (a-c) are preferable, then your proposed change makes sense. If I were building a product, however, I would be very wary of using any code whose licence might change after I've shipped my code. A ___ 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)
On Jul 21, 2009, at 10:27 AM, Andrew Sullivan wrote: On Tue, Jul 21, 2009 at 08:57:01AM +0200, Harald Alvestrand wrote: We have two possibilities: 1 - the update consists of revisions of *every single RFC* that references the BSD license 2 - some RFCs continue to carry the BSD license, even while the "real" current license is different. 1 seems like a logistical nightmare. 2 seems confusing to me. Ok, this is what I was trying to understand. What you are proposing is that the licence on the code in the RFC can change restrospectively, by virtue of the Trust changing the licence they select. This scenario is exactly what inspired my first question, then. Imagine I have a product, and it is shipping. It has code taken from an RFC. The original RFC was published when the Trust used the BSD licence. Therefore, as far as I know, the code I used is under BSD licence. Suppose now that the Trust now changes the licence they use to the GPL. (I know, I know, this won't happen, &c. But there's nothing to prevent it, as far as I can tell, except community consensus. I don't know what that might be in the future.) If I understand what you want, I think there are four possibilities: a. The product I have already shipped is now suddenly covered by the GPL. It may be in violation of the licence therefore. b. The prodict I have already shipped does not change, but products I ship after the Trust changes policy are covered under the new rules. So my shipped product is BSD, and my unshipped stuff is suddenly GPL (possibly forcing me to change my product, or its licence). c. The code I used remains under the BSD because of the date I used it, but new uses of that code are under GPL (so my competitors would have to have a different licence, or version 2 of my product might have to have a different licence). d. The date the RFC was published binds the licence, so that the terms on the code embedded in the RFC change. This is equivalent to your option (2), I think, and you say its undesirable. I am not a lawyer, but I don't see how legally we could do anything but (d). Regards Marshall I argue that compared to (a-c), (d) is a big win. If (d) is right, however, your option (1) isn't a problem: the RFCs that are already published don't need a new licence in them, because they stick to the old one. Therefore, the new text only gives the Trust a way around getting a new RFC published with the new licence explicitly selected by community consensus. I don't see the reason to provide that short cut. If, however, you think (a-c) are preferable, then your proposed change makes sense. If I were building a product, however, I would be very wary of using any code whose licence might change after I've shipped my code. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ 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] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
On Tue, Jul 21, 2009 at 10:52:30AM -0400, Joel M. Halpern wrote: > Clearly, any change in IETF policy can not change the text in an RFC. Only if by "the text" you exclude all the implicitly included text that is the resolution of a pointer in "the text" strictly construed. If the actual text says, "This code is covered by the licence currently published by the Trust," then the real meaning of that text changes depending on $current_licence. This sort of referential issue is what Russell is talking about when discussing the present King of France and whether His Imaginary Majesty is bald. I'd prefer not to relive that portion of my undergrad education every time someone decides a licence change would be good. > Nor can it change what someone has done historically complying with that > text. Sure. > The issue is that we may discover that we would prefer that folks use a > different license going forward. That is the scenario (c) that I described. I have shipping derivative code under BSD, but new derivative code is forced to be under GPL, for instance. (I find that to be a pretty absurd situation to be trying to cause, but it appears to be what is wanted by some.) This means that my competitor can't use the derived code under the same terms I can, and presumably that new interoperating products of my own, using the same code, can't be released under the same licence as I used the first time. Is that really what we want? The position I outline in (d) is what we might call the early-binding option: the Trust can't change the licence terms of code in an RFC after the RFC is published, period. If there is a desire to change the licence, a new RFC is needed (and, of course, the obsoleted RFC's code is still under its original licence). From my point of view, this is the clearest alternative. Everything else sounds to me like a good way to generate work for corporate counsel in figuring out exactly what licence is in effect on any given day, but not a good way to ensure that geeks can get their jobs done with a minimum of fuss (which is, I assume, a major part of the ultimate goal). > But given the pain that gratuitous boilerplate changes introduce, I > would prefer not to need such for an easily foreseeable situation. Surely the right answer, then, is to minimise gratuitous boilerplate changes, which can be partly achieved by saying, "You need a new RFC to change the licence terms." 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)
Andrew Sullivan wrote: On Tue, Jul 21, 2009 at 08:57:01AM +0200, Harald Alvestrand wrote: We have two possibilities: 1 - the update consists of revisions of *every single RFC* that references the BSD license 2 - some RFCs continue to carry the BSD license, even while the "real" current license is different. 1 seems like a logistical nightmare. 2 seems confusing to me. Ok, this is what I was trying to understand. What you are proposing is that the licence on the code in the RFC can change restrospectively, by virtue of the Trust changing the licence they select. This scenario is exactly what inspired my first question, then. Imagine I have a product, and it is shipping. It has code taken from an RFC. The original RFC was published when the Trust used the BSD licence. Therefore, as far as I know, the code I used is under BSD licence. Suppose now that the Trust now changes the licence they use to the GPL. (I know, I know, this won't happen, &c. But there's nothing to prevent it, as far as I can tell, except community consensus. I don't know what that might be in the future.) If I understand what you want, I think there are four possibilities: a. The product I have already shipped is now suddenly covered by the GPL. It may be in violation of the licence therefore. b. The prodict I have already shipped does not change, but products I ship after the Trust changes policy are covered under the new rules. So my shipped product is BSD, and my unshipped stuff is suddenly GPL (possibly forcing me to change my product, or its licence). c. The code I used remains under the BSD because of the date I used it, but new uses of that code are under GPL (so my competitors would have to have a different licence, or version 2 of my product might have to have a different licence). I think this is the version that applies, with one difference that matters. Under the BSD license, you can ALSO give copies of the copy you took from the RFC to anyone at any time, and they will have the right of modification, but not the right to publish the code without the BSD license text - that is, the BSD license is a sublicenseable license. Effectively, the code will be available under all licenses that the Trust has ever licensed stuff under between the time of publication and the present time; if a more restrictive license is used (perish the thought!), you have the right to fork the code, and distribute the forked code under the BSD license in perpetuity. d. The date the RFC was published binds the licence, so that the terms on the code embedded in the RFC change. This is equivalent to your option (2), I think, and you say its undesirable. I argue that compared to (a-c), (d) is a big win. If (d) is right, however, your option (1) isn't a problem: the RFCs that are already published don't need a new licence in them, because they stick to the old one. Therefore, the new text only gives the Trust a way around getting a new RFC published with the new licence explicitly selected by community consensus. I don't see the reason to provide that short cut. If, however, you think (a-c) are preferable, then your proposed change makes sense. If I were building a product, however, I would be very wary of using any code whose licence might change after I've shipped my code. See above. But as usual, IANAL, I just have opinions. Harald ___ 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)
Robert Elz wrote: Date:Tue, 21 Jul 2009 08:57:01 +0200 From:Harald Alvestrand Message-ID: <4a6566bd.1080...@alvestrand.no> | We have two possibilities: | | 1 - the update consists of revisions of *every single RFC* that | references the BSD license | 2 - some RFCs continue to carry the BSD license, even while the "real" | current license is different. Harald, what you're anticipating there is absurd, if an RFC gets issued containing code with the BSD licence, then that is the licence that code, in that RFC will have forevermore, nothing can change that - and nothing should change that, nothng the trustees or community can do can ever change that - only the rights holder (author) of the code can cause it to be offered with some different licence.Any system where it even looked as if it were possible for anyone to simply alter the licence under which code that had previously been published became available would be a disaster. Robert, I'm afraid that your perception disagrees with the structure that RFC 5378 set up. The Trust has enough rights to license code under a license of its choice, and has currently chosen to use the BSD license. The authors may *in addition* license the code under the BSD license, the GPL license, or any other license they feel like using, and there's no way the Trust can stop them from doing that. But neither can the authors restrict the Trust's ability to license the code. It may be a disaster, but it's been in that state since November 2008. Harald ___ 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)
I think Andrew makes a lot of sense. I really can't envision a situation where the IETF would want to change licence terms en masse, given the impact Andrew demonstrates on deployed or ready-to-deploy product. Andrew Sullivan wrote: On Tue, Jul 21, 2009 at 10:52:30AM -0400, Joel M. Halpern wrote: Clearly, any change in IETF policy can not change the text in an RFC. Only if by "the text" you exclude all the implicitly included text that is the resolution of a pointer in "the text" strictly construed. If the actual text says, "This code is covered by the licence currently published by the Trust," then the real meaning of that text changes depending on $current_licence. This sort of referential issue is what Russell is talking about when discussing the present King of France and whether His Imaginary Majesty is bald. I'd prefer not to relive that portion of my undergrad education every time someone decides a licence change would be good. Nor can it change what someone has done historically complying with that text. Sure. The issue is that we may discover that we would prefer that folks use a different license going forward. That is the scenario (c) that I described. I have shipping derivative code under BSD, but new derivative code is forced to be under GPL, for instance. (I find that to be a pretty absurd situation to be trying to cause, but it appears to be what is wanted by some.) This means that my competitor can't use the derived code under the same terms I can, and presumably that new interoperating products of my own, using the same code, can't be released under the same licence as I used the first time. Is that really what we want? The position I outline in (d) is what we might call the early-binding option: the Trust can't change the licence terms of code in an RFC after the RFC is published, period. If there is a desire to change the licence, a new RFC is needed (and, of course, the obsoleted RFC's code is still under its original licence). From my point of view, this is the clearest alternative. Everything else sounds to me like a good way to generate work for corporate counsel in figuring out exactly what licence is in effect on any given day, but not a good way to ensure that geeks can get their jobs done with a minimum of fuss (which is, I assume, a major part of the ultimate goal). But given the pain that gratuitous boilerplate changes introduce, I would prefer not to need such for an easily foreseeable situation. Surely the right answer, then, is to minimise gratuitous boilerplate changes, which can be partly achieved by saying, "You need a new RFC to change the licence terms." A ___ 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)
What are we smoking? The license can't be changed after the RFC is published. At least, it can't be made more restrictive. I can't imagine the chaos if one must prove your right to follow a particular set of license rules based on proving exactly when you extracted code from a published RFC. Particularily as companies merge and split and due diligence is performed, etc. Secondly, we need to consider the folks contributing the code ... they have a right to expect a particular set of license conditions will apply to their contribution. I can imagine being willing to release code under BSD or GPL but not either based on my personal philosophy, etc. Dave Morris On Tue, 21 Jul 2009, Joel M. Halpern wrote: NO, I believe he is suggesting something slightly different. First, realize that the structure does not include any license statement with the code in the RFC. That is covered by the boilerplate. Second, the issue being addressed is the instruction to someone who extracts the code from the RFC and uses it. We are trying to allow them to do this. The instruction, as proposed by the trust says that we will put in the RFC text saying "when you extract this, put the BSD license, as defined by the trust at ..." Clearly, any change in IETF policy can not change the text in an RFC. Nor can it change what someone has done historically complying with that text. The issue is that we may discover that we would prefer that folks use a different license going forward. There are two ways to allow for that. 1) As proposed by Harald, we can just have the text in the RFC say "use what the trust says." If the trust changes what it says, then extractors thereafter have to comply with the new IETF policy. (We assume, for this discussion, that the trust statements and IETF policy align.) 2) Or, the trust can keep a chronological log of required license statements, and when a change is needed record "after date X, use license Y", and provide new boilerplate to be used in I-Ds and RFCs after date X. Mostly, it does not make a big difference. The historical records have to exist in any case. But given the pain that gratuitous boilerplate changes introduce, I would prefer not to need such for an easily foreseeable situation. Yours, Joel Andrew Sullivan wrote: On Tue, Jul 21, 2009 at 08:57:01AM +0200, Harald Alvestrand wrote: We have two possibilities: 1 - the update consists of revisions of *every single RFC* that references the BSD license 2 - some RFCs continue to carry the BSD license, even while the "real" current license is different. 1 seems like a logistical nightmare. 2 seems confusing to me. Ok, this is what I was trying to understand. What you are proposing is that the licence on the code in the RFC can change restrospectively, by virtue of the Trust changing the licence they select. This scenario is exactly what inspired my first question, then. Imagine I have a product, and it is shipping. It has code taken from an RFC. The original RFC was published when the Trust used the BSD licence. Therefore, as far as I know, the code I used is under BSD licence. Suppose now that the Trust now changes the licence they use to the GPL. (I know, I know, this won't happen, &c. But there's nothing to prevent it, as far as I can tell, except community consensus. I don't know what that might be in the future.) If I understand what you want, I think there are four possibilities: a. The product I have already shipped is now suddenly covered by the GPL. It may be in violation of the licence therefore. b. The prodict I have already shipped does not change, but products I ship after the Trust changes policy are covered under the new rules. So my shipped product is BSD, and my unshipped stuff is suddenly GPL (possibly forcing me to change my product, or its licence). c. The code I used remains under the BSD because of the date I used it, but new uses of that code are under GPL (so my competitors would have to have a different licence, or version 2 of my product might have to have a different licence). d. The date the RFC was published binds the licence, so that the terms on the code embedded in the RFC change. This is equivalent to your option (2), I think, and you say its undesirable. I argue that compared to (a-c), (d) is a big win. If (d) is right, however, your option (1) isn't a problem: the RFCs that are already published don't need a new licence in them, because they stick to the old one. Therefore, the new text only gives the Trust a way around getting a new RFC published with the new licence explicitly selected by community consensus. I don't see the reason to provide that short cut. If, however, you think (a-c) are preferable, then your proposed change makes sense. If I were building a product, however, I would be very wary of using any code whose licence might change after I've shipped my code.
Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
The folks contributing the code have a different constraint. They ahve agreed separately to let the IETF have all rights to do anything we want with the source, including giving it to anyone else, and giving them any rights we want. (Note, this is copyright related rights only. This has nothing to do with patent rights.) The text we are discussing is only about what license we require other folks to put on code they extract from an RFC. And, even more specifically, it is only about how we describe that license in the event that we want to change forward-going extractors. The difference in the wording has no effect on folks after they have extracted the code and complied with the instructions. Joel David Morris wrote: What are we smoking? The license can't be changed after the RFC is published. At least, it can't be made more restrictive. I can't imagine the chaos if one must prove your right to follow a particular set of license rules based on proving exactly when you extracted code from a published RFC. Particularily as companies merge and split and due diligence is performed, etc. Secondly, we need to consider the folks contributing the code ... they have a right to expect a particular set of license conditions will apply to their contribution. I can imagine being willing to release code under BSD or GPL but not either based on my personal philosophy, etc. Dave Morris On Tue, 21 Jul 2009, Joel M. Halpern wrote: NO, I believe he is suggesting something slightly different. First, realize that the structure does not include any license statement with the code in the RFC. That is covered by the boilerplate. Second, the issue being addressed is the instruction to someone who extracts the code from the RFC and uses it. We are trying to allow them to do this. The instruction, as proposed by the trust says that we will put in the RFC text saying "when you extract this, put the BSD license, as defined by the trust at ..." Clearly, any change in IETF policy can not change the text in an RFC. Nor can it change what someone has done historically complying with that text. The issue is that we may discover that we would prefer that folks use a different license going forward. There are two ways to allow for that. 1) As proposed by Harald, we can just have the text in the RFC say "use what the trust says." If the trust changes what it says, then extractors thereafter have to comply with the new IETF policy. (We assume, for this discussion, that the trust statements and IETF policy align.) 2) Or, the trust can keep a chronological log of required license statements, and when a change is needed record "after date X, use license Y", and provide new boilerplate to be used in I-Ds and RFCs after date X. Mostly, it does not make a big difference. The historical records have to exist in any case. But given the pain that gratuitous boilerplate changes introduce, I would prefer not to need such for an easily foreseeable situation. Yours, Joel Andrew Sullivan wrote: On Tue, Jul 21, 2009 at 08:57:01AM +0200, Harald Alvestrand wrote: We have two possibilities: 1 - the update consists of revisions of *every single RFC* that references the BSD license 2 - some RFCs continue to carry the BSD license, even while the "real" current license is different. 1 seems like a logistical nightmare. 2 seems confusing to me. Ok, this is what I was trying to understand. What you are proposing is that the licence on the code in the RFC can change restrospectively, by virtue of the Trust changing the licence they select. This scenario is exactly what inspired my first question, then. Imagine I have a product, and it is shipping. It has code taken from an RFC. The original RFC was published when the Trust used the BSD licence. Therefore, as far as I know, the code I used is under BSD licence. Suppose now that the Trust now changes the licence they use to the GPL. (I know, I know, this won't happen, &c. But there's nothing to prevent it, as far as I can tell, except community consensus. I don't know what that might be in the future.) If I understand what you want, I think there are four possibilities: a. The product I have already shipped is now suddenly covered by the GPL. It may be in violation of the licence therefore. b. The prodict I have already shipped does not change, but products I ship after the Trust changes policy are covered under the new rules. So my shipped product is BSD, and my unshipped stuff is suddenly GPL (possibly forcing me to change my product, or its licence). c. The code I used remains under the BSD because of the date I used it, but new uses of that code are under GPL (so my competitors would have to have a different licence, or version 2 of my product might have to have a different licence). d. The date the RFC was published binds the licence, so that the terms on the code emb
Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
On Tue, Jul 21, 2009 at 03:07:15PM -0400, Joel M. Halpern wrote: > And, even more specifically, it is only about how we describe that > license in the event that we want to change forward-going extractors. I think it is exactly this premise that some are wondering about. Is there any circumstance under which it is reasonable to try to change the licence of a piece of code once that code has already been released? If so, then Harald's text makes sense, because otherwise his worry about needing to re-publish all those covered RFCs is reasonable. But some of us are wondering whether there is any circumstance in which such an effort would be reasonable anyway. As Harald points out elsewhere, the code is already released under its first licence, so it is not like it's possible to change the terms really. To me, therefore, this just seems like a way to make lawyers nervous without adding any additional benefit. If there is a real use case for wanting "to change forward-going extractors", I don't know what it is. 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)
On Tue, 21 Jul 2009, Joel M. Halpern wrote: The text we are discussing is only about what license we require other folks to put on code they extract from an RFC. And, even more specifically, it is only about how we describe that license in the event that we want to change forward-going extractors. The difference in the wording has no effect on folks after they have extracted the code and complied with the instructions. But that it might change adds a burden of being able to identify the point in time that the code was extracted and hence applicable license. I've worked in enough small development organizations to believe that to be a potentially significant problem. ___ 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)
Yes, I believe that there is a real world example. Without creating needless FUD, let me say that someone did recently point out possible implications of the BSD license that we did not intend. Fairly awkward implications. 1) It may well be possible to fix that with a clarification. 2) But suppose that it were harder to fix, and that it were discovered 4 months from now. At that point we need to fix the license to match our intentions. And since that is really a matter that affects even RFCs that already came out, we would like to cover those without needing to re-issue them. There is nothing we can do, for good or ill, about folks who already used the earlier license. But we can fix things going forward. I believe that the trust's intention was for the BSD license to be as close as possible to the IETF RFC statement. But things happen. (In the worst case, courts say "those words don't mean what you think they mean.) Since this is only about the rights we grant to folks in our documents, not about the rights folks grant to us, it seems simplest to write things in a way that gives us the flexibility we should have. Joel Andrew Sullivan wrote: On Tue, Jul 21, 2009 at 03:07:15PM -0400, Joel M. Halpern wrote: And, even more specifically, it is only about how we describe that license in the event that we want to change forward-going extractors. I think it is exactly this premise that some are wondering about. Is there any circumstance under which it is reasonable to try to change the licence of a piece of code once that code has already been released? If so, then Harald's text makes sense, because otherwise his worry about needing to re-publish all those covered RFCs is reasonable. But some of us are wondering whether there is any circumstance in which such an effort would be reasonable anyway. As Harald points out elsewhere, the code is already released under its first licence, so it is not like it's possible to change the terms really. To me, therefore, this just seems like a way to make lawyers nervous without adding any additional benefit. If there is a real use case for wanting "to change forward-going extractors", I don't know what it is. A ___ 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)
No matter what, we have to be clear in our records about when things change, and folks who extract things need to somehow record when they did so. That is actually true no matter what, since once the code is extracted, without some backtrace there is no way verify things. I would expect folks extracting large pieces of code to mark the RFC they got it from, and when they took it. But that is up to them. The IETF ought not mandate any more details than we absolutely have to about how the code is extracted / used. Joel David Morris wrote: On Tue, 21 Jul 2009, Joel M. Halpern wrote: The text we are discussing is only about what license we require other folks to put on code they extract from an RFC. And, even more specifically, it is only about how we describe that license in the event that we want to change forward-going extractors. The difference in the wording has no effect on folks after they have extracted the code and complied with the instructions. But that it might change adds a burden of being able to identify the point in time that the code was extracted and hence applicable license. I've worked in enough small development organizations to believe that to be a potentially significant problem. ___ 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] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
On Tue, Jul 21, 2009 at 03:35:31PM -0400, Joel M. Halpern wrote: > Without creating needless FUD, let me say that someone did recently > point out possible implications of the BSD license that we did not > intend. Fairly awkward implications. > 1) It may well be possible to fix that with a clarification. > 2) But suppose that it were harder to fix, and that it were discovered 4 > months from now. > > At that point we need to fix the license to match our intentions. No, we need to change the licence to match the intentions _or_ accept that the damage was done, too bad, and move on. Note that the latter approach is actually the compromise that's been worked out in respect of some other rights and explicit granting of them: instead of forcing contributors to make absurd claims about having explicitly obtained rights throughout history, we give them a way to say, "Maybe I haven't got all the rights. Be careful about relicencing this." > There is nothing we can do, for good or ill, about folks who already > used the earlier license. But we can fix things going forward. Harald argued earlier that you _can't_ fix things once you've released something, at least in any more-restrictive way: once you've released the code under some licence, whoever has the code under that licence automatically can use those terms. Since we've been talking about the BSD licence, then anyone can republish any of the code under BSD terms. So you might as well just leave the licence on the already-published things alone, and just change the rules for new publication. This has the happy property of not opening up some giant legal sinkhole where the exact same code embedded in the exact same document gets a different licence depending on the time of day someone downloads it, and from whom. > Since this is only about the rights we grant to folks in our documents, > not about the rights folks grant to us, it seems simplest to write > things in a way that gives us the flexibility we should have. I am claiming that you cannot write things in a way that gives you the ability to do what you want (which is, in effect, to undo an action the results of which you don't find congenial). I moreover note that some people are expressing concerns about the way the Trust is operating, and the proposed change moves one more thing from "community agrees on a rule change" to "Trust informs community about a change of rules". And therefore, since I claim you can't get the benefit you want anyway, there's no reason to make the change. 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)
Date:Tue, 21 Jul 2009 18:40:52 +0200 From:Harald Alvestrand Message-ID: <4a65ef94.2050...@alvestrand.no> | I'm afraid that your perception disagrees with the structure that RFC | 5378 set up. I was misunderstanding what's going on, Joel has been educating me off list... But while my reasoning changes slightly, my conclusion does not. | The Trust has enough rights to license code under a license | of its choice, and has currently chosen to use the BSD license. I think we can agree that the trust (the IETF) cannot give away more rights than it has obtained from the contributor (however much they are, and if that's "everything related to copyright" that's fine). I can think of no reason why the trust (IETF) should ever offer less than what the contributor has allowed - that would be entirely contrary to the purposes for which we need licences from the contributor in the first place - the aim is to make sure that the code is available with as few restrictions as possible, having the trust add restrictive licence terms would be counter productive (regardless of what those terms are). If all that's reasonable, then it follows that licence in == licence out, and while it is possible that might be change from time to time, the change must be to the licence in first, and that then means that the licence out change affects only those RFCs published after the change, one earlier must still be on the old terms (if the change was broadening the licence to the IETF, then no earlier submission by anyone would be broader in the new way, and so the outgoing licence could not be the new broader form, if the change is to narrow the rights given to the IETF, that will necessarily narrow what the IETF can grant users of the code, but there's no reason it should restrict the rights granted under older submissions, that were published with a broader grant to the IETF. So, I remain fairly convinced that there's no need at all to ever make (or pretend to make) any change which would ever require updating all past RFCs, a change should only ever affect future publications. kre ps; there is no assumption in anything above that every RFC must necessarily have the exact same licence terms, negotiation with contributors might sometimes be reasonable, nothing above is altered by this, what matters is that the licence granted to the IETF for any particular code segment should be exactly the licence the IETF grants to users of that code. ___ 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)
Robert Elz wrote: Date:Tue, 21 Jul 2009 18:40:52 +0200 From:Harald Alvestrand Message-ID: <4a65ef94.2050...@alvestrand.no> | I'm afraid that your perception disagrees with the structure that RFC | 5378 set up. I was misunderstanding what's going on, Joel has been educating me off list... But while my reasoning changes slightly, my conclusion does not. | The Trust has enough rights to license code under a license | of its choice, and has currently chosen to use the BSD license. I think we can agree that the trust (the IETF) cannot give away more rights than it has obtained from the contributor (however much they are, and if that's "everything related to copyright" that's fine). I can think of no reason why the trust (IETF) should ever offer less than what the contributor has allowed - that would be entirely contrary to the purposes for which we need licences from the contributor in the first place - the aim is to make sure that the code is available with as few restrictions as possible, having the trust add restrictive licence terms would be counter productive (regardless of what those terms are). The working group's non-consensus on this point is documented in section 4.4 of RFC 5377: 4.4. Rights Granted for Use of Text from IETF Contributions There is no consensus at this time to permit the use of text from RFCs in contexts where the right to modify the text is required. The authors of IETF Contributions may be able and willing to grant such rights independently of the rights they have granted to the IETF by making the Contribution. If all that's reasonable, then it follows that licence in == licence out, and while it is possible that might be change from time to time, the change must be to the licence in first, and that then means that the licence out change affects only those RFCs published after the change, one earlier must still be on the old terms (if the change was broadening the licence to the IETF, then no earlier submission by anyone would be broader in the new way, and so the outgoing licence could not be the new broader form, if the change is to narrow the rights given to the IETF, that will necessarily narrow what the IETF can grant users of the code, but there's no reason it should restrict the rights granted under older submissions, that were published with a broader grant to the IETF. The "RFC 5378" license to the trust allows, for instance, the Trust to grant the right of copying small snippets of code without attaching the full BSD license to them. The current TLP does not give that right. Incoming and outgoing rights for code are currently different. So, I remain fairly convinced that there's no need at all to ever make (or pretend to make) any change which would ever require updating all past RFCs, a change should only ever affect future publications. I'm fairly convinced that there will come a time when we need to relicense text that was previously licensed by the Trust in a way that is more liberal than the current text of the TLP allows for (while remaining within the scope of rights granted to the trust). That's why I yell so much on this matter. Harald ___ 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)
Date:Wed, 22 Jul 2009 08:32:38 +0200 From:Harald Alvestrand Message-ID: <4a66b286.9080...@alvestrand.no> I don't want to say much more on this issue, I suspect enough has been said now, but just one final (from me) point ... | The working group's non-consensus on this point is documented in section | 4.4 of RFC 5377: | | 4.4. Rights Granted for Use of Text from IETF Contributions | |There is no consensus at this time to permit the use of text from |RFCs in contexts where the right to modify the text is required. The |authors of IETF Contributions may be able and willing to grant such |rights independently of the rights they have granted to the IETF by |making the Contribution. I have no idea how to interpret that - one meaning might be that contributors of code to the IETF can assume that the IETF will not grant rights that allow modification of the text. If that's how it works out, then once again, whatever you think other parts of the RFC say, contributors can rely upon that, and then the IETF cannot later change its mind, and allow modification - the contributor gave the code based upon the assumption that would not be permitted. On the other hand, if we're all convinced that the contributor must be giving the IETF the rights to do whatever it likes with the contribution, including permitting modifications - then the IETF should be (and by referring to a BSD like licence, in fact, is) allowing people do do whatever they want with code in an RFC - which includes modifying it. After all "there is no consensus to permit" also can be written with the exact same meaning as "there is no consensus not to permit", that's what "no consensus" means (though authors sometimes try to describe a point where there's no agreement at all to make it look as if the result of that should be what they think the outcome should be - which is what the paragraph you quoted looks like to me. That is, we couldn't get people to agree to prohibit modifications, so we'll write a paragraph that makes it look like the base position is to prohibit that, and then make it clear that we didn't agree that distribution with modification rights should be allowed - everyone will just conclude that it isn't allowed... That's bogus, and it looks to me (by use of the BSD licence, which if the advertising clause were removed, which it should be (and is in the current version of the BSD licence) about as liberal as it is possible to be. That is, I cannot see it is possible to be more liberal (advertising excepted, and that's a minor point) than the BSD licence which is being specified. Making it truly difficult to change makes it harder for the distribution to be made more restricted, which looks to me to be just about the only way it is possible to move (and if the advertising clause has been, or can be quicky, removed from the IETF's version of the BSD licence, then we're about as unrestricted as it is possible to get). On the other hand, if the IETF's "BSD licence" is currently prohibiting modifications, then it clearly is not a BSD licence at all (so you'd be right, that name ought to be removed as being misleading) - and that ought to be fixed, as quoted above (being read carefully) we have no consensus to prohibit distribution with modifications permitted (unless the contributors are not granting that right, of course) so we may as well just allow modifications. kre ___ 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)
Harald Alvestrand wrote: > > The working group's non-consensus on this point is documented in section > 4.4 of RFC 5377: >... ... of historical interest only, IMHO... > The "RFC 5378" license to the trust allows, for instance, the Trust to > grant the right of copying small snippets of code without attaching the > full BSD license to them. The current TLP does not give that right. This is getting awfully deep into IANAL territory. Since IANAL and I don't want to play one on TV, let me shift the focus away from whether that distinction entails a difference -- to the question of whether opening a discussion of such details tends to clarify or confuse. IMHO, it tends to confuse far more than it clarifies. > Incoming and outgoing rights for code are currently different. Likewise, discussing that difference, IMHO, tends to confuse far more than it clarifies. > I'm fairly convinced that there will come a time when we need to > relicense text that was previously licensed by the Trust in a way that > is more liberal than the current text of the TLP allows for (while > remaining within the scope of rights granted to the trust). May I suggest that many of us don't share this conviction? May I also suggest that opening such a question (where the IPR WG couldn't reach consensus) doesn't seem terribly likely to find any quick consensus? May I suggest that punting such a question to some future group of Trustees to decide for us is even less likely to find a quick consensus? IETF participants admittedly tend towards paranoia. We should accept this and avoid things which feed their paranoia. We should especially (IMHO) avoid things that feed their paranoia with exactly the same food as a previous round. Please, Harald, do us a favor and accept the "BSD" license as "good enough" for the "forseeable" future. Yes, we can all imagine scenarios where something else would be "better", but we'd like to put something to bed here so that RFC publication can stop stumbling over "license" questions. > That's why I yell so much on this matter. Your opinion is noted. You have our permission to say, "I told you so!" when/if we're proven wrong. -- John Leslie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
Harald Alvestrand wrote: ... Hi, I'm trying to understand whether this change affects me. So... 1) Many specs I'm editor of contain ABNF. Does it need to be labeled as code component (I believe not). 2) These specs also collect all ABNF fragments into an appendix, containing the collected ABNF. Does that appendix need to contain the BSD license text (I believe not, but heard from colleagues that their docs are blocked because they do not). 3) If I *extract* ABNF from these documents (such as for the purpose of generating an input file for an ABNF parser), do I need to include the BSD license text? If so, can somebody explain how to do that given the constraints of the ABNF syntax? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
Julian Reschke wrote: ... 3) If I *extract* ABNF from these documents (such as for the purpose of generating an input file for an ABNF parser), do I need to include the BSD license text? If so, can somebody explain how to do that given the constraints of the ABNF syntax? ... Explanation: for some reason I thought that the ABNF syntax only allows comments that are attached to an ABNF rule; but it appears that I was confused. So please ignore the third point. BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
--On Monday, July 20, 2009 14:20 +0200 Julian Reschke wrote: > Julian Reschke wrote: >> ... >> 3) If I *extract* ABNF from these documents (such as for the >> purpose of generating an input file for an ABNF parser), do >> I need to include the BSD license text? If so, can somebody >> explain how to do that given the constraints of the ABNF >> syntax? >> ... > > Explanation: for some reason I thought that the ABNF syntax > only allows comments that are attached to an ABNF rule; but it > appears that I was confused. Independent of that, considering any sequence of ABNF statements as necessarily "code" goes far beyond the intent of the IPR WG as I, at least, understood it. If you, as author, want to identify it as "code", that is your perogative, but this is about copyright and not patents and, at least IMO, metalanguage, metasyntax, pseudo-code, etc., are not intrinsically code in the sense that the WG discussed and intended it. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
At 08:25 AM 7/20/2009, John C Klensin wrote: --On Monday, July 20, 2009 14:20 +0200 Julian Reschke wrote: > Julian Reschke wrote: >> ... >> 3) If I *extract* ABNF from these documents (such as for the >> purpose of generating an input file for an ABNF parser), do >> I need to include the BSD license text? If so, can somebody >> explain how to do that given the constraints of the ABNF >> syntax? >> ... > > Explanation: for some reason I thought that the ABNF syntax > only allows comments that are attached to an ABNF rule; but it > appears that I was confused. Independent of that, considering any sequence of ABNF statements as necessarily "code" goes far beyond the intent of the IPR WG as I, at least, understood it. If you, as author, want to identify it as "code", that is your perogative, but this is about copyright and not patents and, at least IMO, metalanguage, metasyntax, pseudo-code, etc., are not intrinsically code in the sense that the WG discussed and intended it. I agree this is about copyright (not patents). However, your interpretation of "code" does not align with the words in the RFC. See Section 4.3 of RFC 5377: IETF Contributions often include components intended to be directly processed by a computer. Examples of these include ABNF definitions, XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values, MIBs, ASN.1, and classical programming code. ... Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
You are correct. I remembered the text differently, but should have checked. I apologize. john --On Monday, July 20, 2009 12:23 -0400 Russ Housley wrote: > At 08:25 AM 7/20/2009, John C Klensin wrote: > > >> --On Monday, July 20, 2009 14:20 +0200 Julian Reschke >> wrote: >> >> > Julian Reschke wrote: >> >> ... >> >> 3) If I *extract* ABNF from these documents (such as for >> >> the purpose of generating an input file for an ABNF >> >> parser), do I need to include the BSD license text? If >> >> so, can somebody explain how to do that given the >> >> constraints of the ABNF syntax? >> >> ... >> > >> > Explanation: for some reason I thought that the ABNF syntax >> > only allows comments that are attached to an ABNF rule; but >> > it appears that I was confused. >> >> Independent of that, considering any sequence of ABNF >> statements as necessarily "code" goes far beyond the intent >> of the IPR WG as I, at least, understood it. If you, as >> author, want to identify it as "code", that is your >> perogative, but this is about copyright and not patents and, >> at least IMO, metalanguage, metasyntax, pseudo-code, etc., >> are not intrinsically code in the sense that the WG discussed >> and intended it. > > I agree this is about copyright (not patents). However, your > interpretation of "code" does not align with the words in the > RFC. See Section 4.3 of RFC 5377: > > IETF Contributions often include components intended to be > directly > processed by a computer. Examples of these include ABNF > definitions, > XML Schemas, XML DTDs, XML RelaxNG definitions, tables of > values, > MIBs, ASN.1, and classical programming code. ... > > Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
Julian Reschke wrote: Harald Alvestrand wrote: ... Hi, I'm trying to understand whether this change affects me. So... 1) Many specs I'm editor of contain ABNF. Does it need to be labeled as code component (I believe not). In my understanding, all ABNF is code by definition (included in the Trust's list of "things considered code"), so no. 2) These specs also collect all ABNF fragments into an appendix, containing the collected ABNF. Does that appendix need to contain the BSD license text (I believe not, but heard from colleagues that their docs are blocked because they do not). I believe it would be silly to make it contain the BSD license. Some people on the IESG seem to think that the IESG has made such a statement; one of my WGs has a couple of documents that are blocked until this is resolved. 3) If I *extract* ABNF from these documents (such as for the purpose of generating an input file for an ABNF parser), do I need to include the BSD license text? If so, can somebody explain how to do that given the constraints of the ABNF syntax? ; is a fine character. A block of comment should be fine. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
John C Klensin wrote: --On Monday, July 20, 2009 14:20 +0200 Julian Reschke wrote: Julian Reschke wrote: ... 3) If I *extract* ABNF from these documents (such as for the purpose of generating an input file for an ABNF parser), do I need to include the BSD license text? If so, can somebody explain how to do that given the constraints of the ABNF syntax? ... Explanation: for some reason I thought that the ABNF syntax only allows comments that are attached to an ABNF rule; but it appears that I was confused. Independent of that, considering any sequence of ABNF statements as necessarily "code" goes far beyond the intent of the IPR WG as I, at least, understood it. If you, as author, want to identify it as "code", that is your perogative, but this is about copyright and not patents and, at least IMO, metalanguage, metasyntax, pseudo-code, etc., are not intrinsically code in the sense that the WG discussed and intended it. ABNF was specifically used as an example of "code" in the WG discussions. RFC 5377 section 4.3: IETF Contributions often include components intended to be directly processed by a computer. Examples of these include ABNF definitions, XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values, MIBs, ASN.1, and classical programming code. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
