If it needs clarification, it would not be that.
I suppose (although i would like to think about it, and of course would
need to talk to my fellow trustees) that
New:
Components in IETF Contributions which are considered code without
special marking are:
might be a useful edit.
Yours
Joel
On 12/15/2021 4:13 PM, Brian E Carpenter wrote:
On 16-Dec-21 09:52, Joel M. Halpern wrote:
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?
The FAQ is fine but the list does not explain itself.
OLD:
Code Components which may be found in IETF Contributions and IETF
Documents:
NEW:
Non-exclusive list of Code Components which may be found in IETF
Contributions and IETF Documents:
Regards
Brian
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
