sob(_at_)harvard(_dot_)edu (scott bradner) writes:
there seems to be an assertion of evil intent here that is not the case
What gave you that idea? IMHO, let's leave intent for some other
discussion, and focus on the license.
After having read the discussion for the past few days, I still see no
useful text in RFC 3667 that permit me to do the things I mentioned
earlier, if the RFC 3667 license would be used. Repeated here for
simplicity:
For IDN, I want to be able to extract the tables from RFC 3454 and use
them in my implementation.
For Kerberos, I want to be able to use the ASN.1 schema in my
implementation, and copy the terminology section into my manual.
For SASL, I want to incorporate portions of the introduction section
from the RFC into my manual, to make sure some terminology is
explained correctly.
For GSS-API, I want to be able to copy the C header file with function
prototypes into my implementation.
The text that has been referenced is in section 7 of RFC 3667,
"Exposition of Why These Procedures Are the Way They Are":
e. the right to let third parties extract some logical parts, for
example MIB modules
I don't believe I can use this text in a legal argument to motivate
why I'm copying parts from a RFC.
First, the text appear to be from a discussion about the license, not
the actual license.
Secondly, the qualifier "some" in "extract some logical parts" is
worrying. Without further details, "some" might mean anything,
including preventing exactly those parts I need.
Thirdly, if you read the license, it seem (to me) clear that it
doesn't imply the right granted in (e).
3/ the IETF is quite interested in letting people create manuals
etc - there is no intent to limit the ability for a 3rd party
to reproduce RFCs or parts of RFCs in manuals
What I'm arguing for, then, is that the license should reflect the
intent.
I do not see any problem for the open source community unless that
community wants to create a new version of TCP and take parts of
existing IETF RFCs to include in its description of their revised TCP
I don't speak for the open source community, but I believe it should
be possible to do exactly that. Naturally, I would have no right to
claim that my version would be IETF's TCP, or that my version is the
"real" version. However, I need to have the right to create
derivative work from RFCs.
To perhaps give a better example of why I need this right, let's take
the first item above: IDN. After the IDN specification has been
published, some problems in Unicode NFKC has been discovered that may
have security consequences. If someone wanted to offer their users an
improved IDN library, they could take my library and modify it.
However, they could not describe how the new product work, by taking
the existing RFC and add a few paragraphs that solve the problem.
Instead, the RFC license, from my current understand at least, would
force them to write a complete new specification. I don't believe
that is acceptable. Fortunately, in this case, IDN was published
under the old RFC 2026 license, which I maintain would permit this
use.
Finally, derivative works need not only be about revised
specifications. It may simply be copying tables from a specification
into an implementation.
Thanks,
Simon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf