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

Harald Alvestrand harald at alvestrand.no
Mon Jul 20 23:57:01 PDT 2009


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


More information about the rfc-interest mailing list