Harald Alvestrand <harald(_at_)alvestrand(_dot_)no> writes:
This seems more or less correct, even though it may sound surprising at
first. More generally, and more clearly expressed, it can be stated as
this: The license for a piece of work applies to the piece of work, it
does not apply to the license itself. The license of a work is not
normally not considered part of the work; it is metadata about the work.
But (and the reason why this is important, and IETF-relevant) how is
this case different from the case where you introduce pieces of an RFC
(which also don't need to be considered part of the work) as comments
into a work?
The only way I can see to avoid having the comment be part of the work
is to use different licenses for the code and the comment. (Do you see
any other way?)
That is possible, but leads to problems.
The result is a complex license on the combined work. The combined
license says essentially something like "License A applies to portion X
and the IETF Trust License applies to portion Y". That combined license
may not be compatible with other licenses, both free and non-free
For example, the combined license would not be compatible with the GPL
because modifications of the entire work is not permitted.
I believe it is possible to find proprietary licenses that have other
clauses that render the license incompatible with the IETF Trust
license. So the problem is wider than just free software licenses. I
believe the IETF needs to realize that GPL software runs part of the
Internet and that catering to these licensing needs is as important as
catering to the licensing needs of, say, Microsoft.
The license compatibility question is more relevant for free software
because people are more conservative in evaluating software licenses in
the free software community compared to the enterprise setting where
licenses are typically only ever evaluated when someone sues or is sued
My point has been that triggering this situation works counter to the
goal of the IETF. In a strict setting, it means implementers cannot use
verbatim text from RFCs, but needs to rewrite the text to avoid re-use
of material under the IETF Trust license. I believe that opens up for
interoperability problems (when a re-written comment is subtly different
from the original meaning, and the comment influences code). If people
decide that this rewriting needs to happen to avoid contamination from
the IETF Trust license, it would also delay getting IETF protocols
This has been my rationale for suggesting that IETF documents should be
licensed under a free software compatible license. I am aware that
battle is already lost, so I have mixed feelings about discussing this
further. However if others bring up related topics I feel a need to
respond. My hope is that it is possible to alter the policies in the
future. Fortunately, I believe the new BCP 78 has created good ground
to make that possible.
Generally, however, I think this question is very different from where
this thread started. It started, as far as I consider, with Stephan
suggesting that free software authors publish "free" (as in licensed
under a free software license) standards in the IETF. That is not
possible, and is unrelated to the question we discuss here. I'm happy
to discuss both questions, but I'm concerned that you and others may
believe that you dispute my first claim by discussing this separate
With the GPL text, you don't have the copyright, and you don't have a
license that permits modified versions. But you do have the right to
With the excerpt from an RFC, you don't have the copyright, and you
don't have a license that permits modified versions. But you do have
the right to copy it - you even have the right to copy pieces of it.
Why are you insisting that the first is perfectly reasonable, and the
second is a show-stopper?
I'm not saying the second is a show stopper. The Internet appears to
work relatively well on most days. However, I insist that it is a
potential impediment and that it works counter to the goals of the IETF.
But to answer your question (heh!): I believe the situations are
different because the first is about meta-data of a work, and the second
results in a complex combined license.
Ietf mailing list