[AFS3-std] Options for AFS Standardisation

[Jeffrey Hutzelman]

--On Wednesday, July 23, 2008 10:37:42 PM -0700 Russ Allbery 
<rra@stanford.edu> wrote:

> 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

You mean that it says "to prepare" instead of "to prepare and distribute" ?
I think we can work around that in our process.

> and it doesn't define community explicitly to
> mean everyone in the world without limitation.

And this as well.

Basically, I think we can reasonably require authors under our process to 
grant _more_ rights than would otherwise be required by the independent 
submission process.  The tricky part is getting those grants into the 
documents.

> 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.

It's a bit more complicated than that.  The section you quote is not 
identical to the text in BCP 78 from which it was drawn.  It applies to 
independent submissions to the RFC Editor, but only from the point at which 
the document is actually submitted to the RFC Editor for publication, and 
then only to the extent that RFC 4846 actually reflects the RFC Editor's 
policy (note that the RFC Editor has a history of publishing its policy 
documents as Informational RFC, but RFC 4846 was written by members of the 
IETF community, not by the RFC Editor, so it is not clear whether it 
expresses RFC Editor policy or is merely descriptive of the process).

Unfortunately, jaltman's comment notwithstanding, BCP 78 _does_ apply to 
_every_ Internet-Draft.  It is referenced explicitly in the copyright 
message and license message that must be included in every I-D.  RFC 4846 
describes the process by which independent submissions to the RFC Editor 
are handled, but does not replace or supercede any part of BCP 78.  Doing 
that would require an IETF consensus, which RFC 4846 does not formally 
represent.

However, the "rights, licenses, and restrictions" the copyright notice 
referes to from BCP 78 differ depending on the type of Internet-Draft.  In 
particular, the provisions of section 3.3 apply only to IETF Contributions.

BCP 78 defines an RFC Editor Contribution as "an Internet-Draft intended by 
the Contributor to be submitted to the RFC Editor for publication as an 
Informational or Experimental RFC but not intended to be part of the IETF 
Standards Process".  Our documents satisfy that description.


For documents fitting that definition, BCP 78 imposes the following 
requirements:

3.1 General Policy
3.2 Confidentiality Oblications
3.4 Representations and Warranties
3.5 No Duty to Publish
3.6 Trademarks

It does not impose the requirements of section 3.3, "Granting of Rights and 
Permissions", which applies only to IETF Contributions.  Instead, the terms 
that apply are those of section 4.2, which grants to the IETF Trust and 
IETF, for at least the life of the I-D, the rights

   (A) to copy, publish, display, and distribute the RFC Editor
       Contribution as an Internet-Draft,

   (B) to prepare or allow the preparation of translations of the RFC
       into languages other than English,

   (C) 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 not granting the IETF and IETF Trust any
       more rights than the license to the original RFC Editor
       Contribution, and

   (D) to reproduce any trademarks, service marks, or trade names...

Simon's document prohibits the use of the notices mentioned in (C) that 
would disallow preparation of derivative works, so that is not a problem. 
However, this text, which applies to I-D's before they are submitted to the 
RFC Editor for publication, deems the contributor to have granted these 
rights only to the IETF and IETF Trust, and not to anyone else.


Interestingly, I just noticed a giant loophole we can use.  Section 6 of 
BCP 78 lists "Notices and Rights Required in RFC Editor Contributions", 
which are different from those required for IETF documents.  In particular, 
while the normal copyright notice and disclaimer can be used, it is also 
permissible to simply include the phrase "By submitting this 
Internet-Draft, I accept the provisions of Section 4 of BCP 78".  This 
makes it clear that the document is intended as an RFC Editor contribution, 
_and_ gets rid of the meaningless IETF Trust copyright.  Further, the 
normal provision that other copyright messages are not permitted also does 
not apply.  I believe that means we can resolve all of the issues by 
requiring the use of particular text where the IETF Trust copyright and 
disclaimer would normally be found.  Something like the following...


>>>>>
Full Copyright Statement

   Copyright (C) <author(s)> (year).

   By submitting this Internet-Draft, I accept the provisions of
   Section 4 of BCP 78.

   In addition, by submitting this Internet-Draft, to the extent that
   this Internet-Draft or any portionthereof is protected by copyright
   and other rights of authorship, the Contributor, and each named
   co-Contributor, and the organization he or she represents or is
   sponsored by (if any) grant a perpetual, irrevocable, non-exclusive,
   royalty-free, world-wide right and license to any and all persons
   under all intellectual property rights in this Internet-Draft:

   (A) to copy, publish, display, and distribute this Internet-Draft,

   (B) to prepare or allow the preparation of translations of this
       Internet-Draft into languages other than English,

   (C) to prepare and distribute derivative works (other than
       translations) that are based on or incorporate all or part of
       this Internet-Draft, or comment upon it, the license to such
       derivative works not granting to any party any more rights than
       the license to this Internet-Draft,

   (D) to reproduce any trademarks, service marks, or trade names
       which are included in this Internet-Draft solely in connection
       with the reproduction, distribution, or publication of this
       Internet-Draft and derivative works thereof as permitted by
       this paragraph and/or by section 4 of BCP 78, and

   (E) to extract, copy, publish, display, distribute, modify, and
       incorporate into other works, for any purpose, any executable
       code or code fragments that are included in this Internet-Draft,
       it being understood that the licenses granted under this
       paragraph (E) shall not be deemed to grant any right under any
       patent, patent application, or other similar intellectual property
       right disclosed by me under XXX.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
   AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
   IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   PURPOSE.

<<<<<

The new text is taken primarily from BCP 78 section 4.2, with some 
modifications, except for paragraph (E), which is adapted from the same 
paragraph in section 3.3.  BCP 78 does not require this permission be 
granted for non-IETF documents, but I believe that it is important, 
especially for documents which are likely to include full or partial .xg 
files.


I expect that the first application of our process will be to publish 
whatever ends up being the final form of Simon's document, which will 
effectively become our charter.  Clearly this charter will need to detail 
exactly what is required of submitted documents, including exact 
boilerplate text in those cases where it cannot be incorporated by 
reference from another source (such as BCP 78).

I think that rather than requring all of the text I quote above to be 
included in every document, it would be beneficial for the charter to 
include a section similar to BCP 78 section 4, detailing exactly what 
additional rights are granted, such that submitted documents can simply 
refer to it just as they refer to BCP 78.

-- Jeff