--On Wednesday, July 23, 2008 10:37:42 PM -0700 Russ Allbery
<[EMAIL PROTECTED]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
