Yes, I believe that there is a real world example.
Without creating needless FUD, let me say that someone did recently
point out possible implications of the BSD license that we did not
intend. Fairly awkward implications.
1) It may well be possible to fix that with a clarification.
2) But suppose that it were harder to fix, and that it were discovered 4
months from now.
At that point we need to fix the license to match our intentions. And
since that is really a matter that affects even RFCs that already came
out, we would like to cover those without needing to re-issue them.
There is nothing we can do, for good or ill, about folks who already
used the earlier license. But we can fix things going forward.
I believe that the trust's intention was for the BSD license to be as
close as possible to the IETF RFC statement. But things happen. (In
the worst case, courts say "those words don't mean what you think they
mean.)
Since this is only about the rights we grant to folks in our documents,
not about the rights folks grant to us, it seems simplest to write
things in a way that gives us the flexibility we should have.
Joel
Andrew Sullivan wrote:
On Tue, Jul 21, 2009 at 03:07:15PM -0400, Joel M. Halpern wrote:
And, even more specifically, it is only about how we describe that
license in the event that we want to change forward-going extractors.
I think it is exactly this premise that some are wondering about. Is
there any circumstance under which it is reasonable to try to change
the licence of a piece of code once that code has already been
released?
If so, then Harald's text makes sense, because otherwise his worry
about needing to re-publish all those covered RFCs is reasonable.
But some of us are wondering whether there is any circumstance in
which such an effort would be reasonable anyway. As Harald points out
elsewhere, the code is already released under its first licence, so it
is not like it's possible to change the terms really. To me,
therefore, this just seems like a way to make lawyers nervous without
adding any additional benefit.
If there is a real use case for wanting "to change forward-going
extractors", I don't know what it is.
A
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf