RE: [Trustees] Objection to reworked para 6.d (Re: Rationale forProposed TLP Revisions)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
> ajs at shinkuro.com
> Shinkuro, Inc.
> 

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.