[AFS3-std] Options for AFS Standardisation
Russ Allbery
rra@stanford.edu
Wed, 23 Jul 2008 22:37:42 -0700
Jeffrey Altman <jaltman@secure-endpoints.com> writes:
> This is fine except that an Independent Submission to the RFC Editor is
> not an IETF document and BCP 78 does not apply. All Independent
> Submissions to the RFC Editor for publication include an explicit
> statement that the document is not an IETF Document. All of the
> requirements and specifications governing the Independent Submission
> process is instead described in RFC 4846.
>
> http://www.rfc-editor.org/rfc/rfc4846.txt
>
> The normative reference to BCP 78 in that document is there because the
> relevant material from BCP 78 that applies to the Independent Submission
> process was copied from BCP 78. Note the requirements in Section 8 that
> assign rights not just to the RFC Editor but to the community.
Ah, thank you. I completely missed that.
This is almost sufficient. Here's the relevant provision:
By submission of an RFC Editor Contribution, each person actually
submitting the RFC Editor Contribution, and each named co-
Contributor, is deemed to agree to the following terms and
conditions, and to grant the following rights, on his or her own
behalf and on behalf of the organization the Contributor represents
or is sponsored by (if any) when submitting the RFC Editor
Contribution.
[...]
B. unless explicitly disallowed in the notices contained in an
RFC Editor Contribution, to prepare derivative works (other
than translations) that are based on or incorporate all or
part of the RFC Editor Contribution, or comment upon it. The
license to such derivative works shall not grant the IETF
Trust, the IETF, or other party preparing a derivative work
any more rights than the license to the original RFC Editor
Contribution, and
Provided that we rule out disallowing this (which I think Simon's language
is designed to do), the only flaw in this is that it doesn't explicity
state that such derivative works (and the original work for that matter)
may be redistributed freely, and it doesn't define community explicitly to
mean everyone in the world without limitation.
Unfortunately, given the creative interpretation of the Pine license, it's
worth spelling out, even if a license allows redistribution and derivative
works, that it *also* allows redistributing the derivative works.
If we can close those two loopholes and make it clear (it probably is for
people who know the process, but I didn't find it so from the plain
language) that even the I-Ds are "RFC Editor Contributions" for the
purposes of this section, I'm content.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>