Re: Question about pseudocode and <CODE BEGINS>

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux