Re: List moderator action

Simon,

IANAL so I will not debate whether section 3.3 would or would not
be considered effective by a hypothetical court in a hypothetical
jurisdiction. However, I don't think it matters since any IETF
participant is bound by all the IETF processes and policies, and
that includes IESG statements, and the list moderator action is
based on an IESG statement.

Regards/Ngā mihi
    Brian Carpenter

On 04-May-26 19:30, Simon Josefsson wrote:
> Brian E Carpenter <[email protected]> writes:
> 
>> On 03-May-26 07:32, Rob Sayre wrote:
>>> Hi,
>>> Apologies in advance for being a giant pain.
>>> Lars Eggert <[email protected] <mailto:[email protected]>> wrote:
>>>   > If you read Section 3.3 of RFC 5378 you will find the “specific
>>>   > context” is about documents.
>>> It is not. It is about "Contributions" in caps.
>>> While I agree with the goal of the IESG statement, and the moderator
>>> actions here, we have to go fix RFC 5378 for this one.
>>
>> What needs fixing? It says that the IETF requires the right to make
>> derivative works of all contributions, which includes emails.
>>
>> The final paragraph of section 3.3 allows "no derivative works"
>> legends only for two special cases: "information about proprietary
>> technologies" and republishing standards from other SDOs. Most emails
>> are neither of those cases; therefore "no derivative works" legends
>> are forbidden.
> 
> Section 5.3 is clear and uses well-defined terms, and according to the
> multiple legal advice I've gotten over the years, those are the terms
> that are binding.
> 
> Regarding the entire section 3, consider that its title is:
> 
>     3. Exposition of Why These Procedures Are the Way They Are .........6
> 
> The section is written informally and try to explain the legal words in
> other ways.  The introduction of the document re-inforces this:
> 
>     Section 1 provides definitions used in these policies.  Sections 3
>     and 4 of this document explain the rationale for these provisions.
>     Sections 1, 2, 5, and 6 of this document are normative, the other
>     sections are informative.  RFC 3979 (BCP 79) [RFC3979] deals with
> 
> Read that again: Section 3 has no normative bearing.
> 
> It is unfortunate that the IESG made a statement that enforce a
> particular legal interpretation which is based on content in Section 3.
> That puts the IETF into legal jeopardy and opens up for anti-trust
> and/or anti-openness risks, and harms the reputation of the IETF as an
> open standardization organization.
> 
> /Simon