Re: [Trustees] Objection to reworked para 6.d (Re: Rationale forProposed TLP Revisions)
On 2009-07-20, at 16:44, "Contreras, Jorge" > wrote: 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. No, no angst over the term. I find the idea fetching, in principle, too, but I can't see how the proposed change does what is needed. If the goal is to be able to allow the trust to relicence the code as it sees fit, parallel with its ability to cope with the license of rfc text, then I get the purpose of the change. If this is just to avoid the bureaucracy of publishing a new rfc then no, sorry, I don't think that's a good idea. The bureaucratic hurdles are there to find consensus, and I see no reason to make this a special case. If we think rfc production is too bureaucratic, let's fix that. Andrew Sullivan a...@shinkuro.com___ 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)
On Mon, Jul 20, 2009 at 4:53 PM, Joel M. Halpern wrote: > I think Harald's suggestion makes sense and should be implemented. I agree. Barry ___ 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)
I think Harald's suggestion makes sense and should be implemented. Joel Contreras, Jorge wrote: 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 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
