[saag] Re: on derivative work rights statements in emails to Security Area mailing lists

Nico Williams writes:
> I suppose, but we can't really have to check copyrights and licensing on
> every such contribution.

People volunteering text for a spec normally make it clear that they're
doing so. Normal people deal with the _occasional_ edge cases by asking
questions when they're unsure ("are you ok with this?"), not by trying
to engage in a giant power grab.

Furthermore, if a company screwed by IETF decides to sue, the power grab
won't hold up in court. Look at, e.g.,

    https://cdn.ca9.uscourts.gov/datastore/opinions/2014/08/18/12-56628.pdf

where an appeals court spent quite a few pages explaining why Barnes &
Noble hadn't provided adequate notice of its terms---despite a big link
to its terms being visible on _every single page of its site_ and _close
to the buttons people had to click on_. That's much more notification
than IETF provides of its copyright grab.

> > What started this whole no-modifications discussion was an incident
> > having nothing to do with IETF being able to modify IETF standards. The
> > incident was IESG posting an IESG-mangled version of a complaint that I
> > had filed, rather than posting an exact copy. This turned a simple
> > situation of a single document into an unnecessarily complicated
> > situation of (1) the original document and (2) the IESG-mangled version
> > of the document.
> Remind us: how bad was that mangling?

>From the perspective of readers trying to track what was going on, IESG
was doubling the work.

Imagine a git user doing a mass commit that frivolously touches every
line (e.g., adding an empty comment to each line), burying any actual
changes. Is this a novice git user, or part of a supply-chain attack?
What if the user keeps doing this again and again?

Content-wise, I haven't had time to invest in a detailed comparison, but
I glanced at the central diagram in the document. IESG had completely
botched that diagram, placing a dozen items at the top level instead of
the original two items. Those two items corresponded to the two BCP 79
provisions that were (and are) being violated. Funny how IESG's response
to the contents didn't clearly separate those two provisions!

> The IESG's interpretation of that applying only to contributions of the
> for of Internet-Draft and similar strikes me as reasonable.

Section 3 of BCP 78 has title "Exposition of Why These Procedures Are
the Way They Are" and is explicitly labeled as informative. IESG has
taken _examples_ from this _informative_ Section 3 of BCP 78 and has
misrepresented those examples as _limitations_ on the _normative_
procedure in Section 5. See https://cr.yp.to/2025/20251024-rules.pdf for
full quotes.

The normative procedure is clear. It leaves no room for interpretation,
and assigns no power whatsoever to IESG.

> They can ban you from IETF mailing lists

No, not under the RFC 3934 provisions that they've been citing. The RFC
3934 authority is with WG chairs, not with IESG. WG chairs don't always
go along with what IESG wants.

There's a separate procedure (BCP 83) that IESG does have power over,
but it's also subject to various limits that RFC 3934 isn't subject to.
There's also a current effort to massively expand censorship powers. See
https://blog.cr.yp.to/20251005-modpod.html for further details.

> How is my reply to you, with quote trimming and so on not a "derivative
> work"?

Of course it's a derivative work! However, as I said before, you aren't
violating copyright law when you quote the specific point you're
replying to. Again, see

    https://www.govinfo.gov/content/pkg/USCODE-2024-title17/html/USCODE-2024-title17-chap1-sec107.htm

allowing copies for "fair use" for "purposes such as criticism, comment"
etc., and laying out the criteria for how courts decide what's "fair",
looking at the amount copied, at the nature of the use, etc.

> But what is your notice going to actually do for you?

Same answer as for, e.g., RFC 5831: it's following the official IETF
procedure for opting out of modifications.

---D. J. Bernstein

P.S. For readers bumping into this message who haven't seen the context:
Please see https://blog.cr.yp.to/20251004-weakened.html to understand
what's actually going on here.


===== NOTICES =====

This document may not be modified, and derivative works of it may not be
created, and it may not be published except as an Internet-Draft. (That
sentence is the official language from IETF's "Legend Instructions" for
the situation that "the Contributor does not wish to allow modifications
nor to allow publication as an RFC". I'm fine with redistribution of
copies of this document; the issue is with modification.)

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]