I think Andrew makes a lot of sense. I really can't envision a situation where
the IETF would want to change licence terms en masse, given the impact Andrew
demonstrates on deployed or ready-to-deploy product.
Andrew Sullivan wrote:
On Tue, Jul 21, 2009 at 10:52:30AM -0400, Joel M. Halpern wrote:
Clearly, any change in IETF policy can not change the text in an RFC.
Only if by "the text" you exclude all the implicitly included text
that is the resolution of a pointer in "the text" strictly construed.
If the actual text says, "This code is covered by the licence
currently published by the Trust," then the real meaning of that text
changes depending on $current_licence. This sort of referential issue
is what Russell is talking about when discussing the present King of
France and whether His Imaginary Majesty is bald. I'd prefer not to
relive that portion of my undergrad education every time someone
decides a licence change would be good.
Nor can it change what someone has done historically complying with that
text.
Sure.
The issue is that we may discover that we would prefer that folks use a
different license going forward.
That is the scenario (c) that I described. I have shipping derivative
code under BSD, but new derivative code is forced to be under GPL, for
instance. (I find that to be a pretty absurd situation to be trying
to cause, but it appears to be what is wanted by some.) This means
that my competitor can't use the derived code under the same terms I
can, and presumably that new interoperating products of my own, using
the same code, can't be released under the same licence as I used the
first time. Is that really what we want?
The position I outline in (d) is what we might call the early-binding
option: the Trust can't change the licence terms of code in an RFC
after the RFC is published, period. If there is a desire to change
the licence, a new RFC is needed (and, of course, the obsoleted RFC's
code is still under its original licence). From my point of view,
this is the clearest alternative. Everything else sounds to me like a
good way to generate work for corporate counsel in figuring out
exactly what licence is in effect on any given day, but not a good way
to ensure that geeks can get their jobs done with a minimum of fuss
(which is, I assume, a major part of the ultimate goal).
But given the pain that gratuitous boilerplate changes introduce, I
would prefer not to need such for an easily foreseeable situation.
Surely the right answer, then, is to minimise gratuitous boilerplate
changes, which can be partly achieved by saying, "You need a new RFC
to change the licence terms."
A
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf