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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf