![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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 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.