The FAQ, which points to the code components list, is clear that the
list is only about what is automatically considered code. For that
purpose, the list is comprehensive. Anything not listed there is not
considered code unless it is marked <code begin>...
I am not sure what clarification you are asking for?
Yours,
Joel
On 12/15/2021 3:18 PM, Brian E Carpenter wrote:
Joel,
On 16-Dec-21 08:54, Joel M. Halpern wrote:
The list is the list of things that will be considered to be code even
if they are not marked. As such, it is inherently complete. And not
limiting.
Yes, but the list doesn't state that it's not limiting. IMHO that's a bug.
Brian
The trust complies with RFC 8721 section 4.3 in this regard.
Yours,
Joel
On 12/15/2021 2:45 PM, Brian E Carpenter wrote:
On 16-Dec-21 07:44, John Levine wrote:
It appears that Bob Hinden <bob.hinden@xxxxxxxxx> said:
I agree, it not necessary to have a delimiter token. Just say
something like:
A suggested algorithm in pseudo code for <foo> is as follows:
in the document. It is essentially just text.
I agree except for the "essentially". It is just text.
We went through a long process to decide what licenses to offer for
RFCs and for
computer code in them. The TLP even describes what we consider to be
code:
https://trustee.ietf.org/documents/trust-legal-provisions/code-components-list-3/
As has been pointed out off list, that list is incomplete, which would
be OK if it was stated to be non-exclusive, but it isn't.
My original concern was different - if an implementer wants to borrow
from the pseudocode to make real code, they might be making a derivative
work from the RFC in a way that is not allowed by the Trust's legal
provisions**.
As far as I know, we have never discussed this issue to see what the
community consensus might be.
** Before John says it, the author of the pseudocode is perfectly at
liberty to grant any license for it that they want, outside the IETF
standards process. But that's more work and may be tricky in a corporate
context.
Regards
Brian
