Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
ajs@xxxxxxxxxxxx
Shinkuro, Inc.
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]