One document matched: draft-carpenter-5378-old-text-01.txt
Differences from draft-carpenter-5378-old-text-00.txt
Network Working Group B. Carpenter
Internet-Draft Univ. of Auckland
Updates: 5378 (if approved) H. Alvestrand
Intended status: BCP Google
Expires: August 17, 2009 February 13, 2009
Including text under former copyright conditions
draft-carpenter-5378-old-text-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 17, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Carpenter & Alvestrand Expires August 17, 2009 [Page 1]
Internet-Draft Including old text February 2009
Abstract
This document specifies a procedure for including text in an IETF
document for which the current copyright conditions defined in RFC
5378 cannot readily be met.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . . 4
Appendix A. Non-normative initial version of disclaimer . . . . . 5
Appendix B. Non-normative explanation of background . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Carpenter & Alvestrand Expires August 17, 2009 [Page 2]
Internet-Draft Including old text February 2009
1. Introduction
RFC 5378 [RFC5378] failed to describe one case that has practical
consequences.
The case is this: a contribution submitted under RFC 5378 contains
material derived from one or more contributions submitted prior to
RFC 5378, and it has proved impossible, after reasonable efforts, to
obtain the agreement of the original contributors to the specific
additional rights required to be granted to the IETF under RFC 5378
compared with those granted under previous IETF rules. In this case
the document cannot be published consistently with RFC 5378.
This can arise when the original contributors, or their assigns, are
unwilling, unresponsive, unfindable, deceased, or no longer in
business.
This document is intended to specify the simplest possible solution
for such cases. Additional background information is given in
Appendix B below.
2. Procedure
Definition: In this document, the phrase "prior to RFC 5378" refers
to IETF Contributions made before November 10, 2008, when [RFC5378]
became effective.
Contributors of Internet-Drafts that contain substantial text
originally contributed to the IETF by other persons prior to RFC 5378
have certain responsibilities.
o They must identify the source of the substantial text that their
contribution includes.
o They, or people helping them, must make reasonable efforts to
obtain or verify the agreement of the original contributors to
their text being contributed under the terms of RFC 5378.
o If such agreement cannot be obtained within a reasonable time,
they must instead include a special disclaimer in the Internet-
Draft. The current text of the disclaimer will be specified by
the IETF Trust's "Legal Provisions Relating to IETF Documents",
originally located at
<http://trustee.ietf.org/policyandprocedures.html>. The initial
version of this text is in Appendix A below.
o In either case, the Internet-Draft must contain acknowledgement
and precise citation of the contributions concerned. If the
disclaimer is included, the acknowledgement should also identify
which previous contributors contributed which text, unless the
text concerned is scattered throughout the document.
Carpenter & Alvestrand Expires August 17, 2009 [Page 3]
Internet-Draft Including old text February 2009
Before approving a document containing material originally
contributed to the IETF prior to RFC 5378, for which permission to
contribute it under RFC 5378 has not been obtained, the IESG must be
satisfied that reasonable effort has been made to obtain the
necessary rights. If such is the case, the resulting document, and
any IETF Last Call message concerning the document, must contain the
special disclaimer and acknowledgement defined above.
The IESG and the IETF Trust, in collaboration, must provide a public
register of documents prior to RFC 5378 for which the rights required
by RFC 5378 have been provided retroactively, and a public register
of rights holders who have retroactively provided such rights for all
their IETF contributions prior to RFC 5378.
The IETF Trust is requested to ensure that its policies and licenses
allow for documents including the disclaimer.
3. Security Considerations
This document does not affect the security of the Internet.
4. IANA Considerations
This document requires no action by the IANA.
5. Acknowledgements
Much mailing list discussion by the IETF community, and private email
discussions with Jorge Contreras, Russ Housley, John Klensin, and
others, have led to this document.
This document was produced using the xml2rfc tool [RFC2629].
6. References
6.1. Normative References
[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide
to the IETF Trust", BCP 78, RFC 5378, November 2008.
6.2. Informative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
Carpenter & Alvestrand Expires August 17, 2009 [Page 4]
Internet-Draft Including old text February 2009
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667,
February 2004.
[RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978,
March 2005.
Appendix A. Non-normative initial version of disclaimer
The current valid version should be taken from the IETF Trust's
"Legal Provisions Relating to IETF Documents", originally located at
<http://trustee.ietf.org/policyandprocedures.html>. The initial
version was:
[[ Note to RFC Editor: please make sure this is the Trust's current
disclaimer text at the time of publication. ]]
[[ Note to the reader: the following text differs slightly from the
Trust's disclaimer text current on the date of this draft. ]]
"This document contains material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material are not known to have granted the IETF Trust the right to
allow modifications of such material outside the IETF Standards
Process. Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not be
modified outside the IETF Standards Process, and derivative works of
it may not be created outside the IETF Standards Process, except to
format it for publication as an RFC and to translate it into
languages other than English."
Next to the note, there should be a list of the contributions from
which the material in question was taken. If the material has been
contributed multiple times (such as in multiple versions of an
internet-draft), any version is a sufficient reference.
Appendix B. Non-normative explanation of background
This Appendix is not part of the formal rules of the IETF and does
not purport to offer legal advice.
Copyright provisions for IETF documents were first defined in
[RFC2026] and were subsequently refined in [RFC3667] and [RFC3978].
Carpenter & Alvestrand Expires August 17, 2009 [Page 5]
Internet-Draft Including old text February 2009
Their effect has always been to allow free use of contributions to
the IETF process in IETF discussions, IETF drafts and IETF
publications. Even prior to RFC 2026, such free use was considered
the norm by all participants. RFC 5378 makes no difference to the
IETF's right to use contributions freely within the IETF process.
However, use of contributions outside the IETF process has always
been subject to some limitations. The IETF does not require
copyright transfers, and as a result contributors retain control
except to the extent that the IETF rules applicable at the time of
submission indicate otherwise.
IETF and RFC Editor rules and practices have always allowed RFCs to
be reproduced as complete documents, in English or in translation.
This has not changed.
The particular point at issue is the use of IETF contributions in
works derived from IETF documents by third parties outside the IETF
process. The rules in RFC 2026, RFC 3667 and RFC 3978 do not allow
this without the contributors' permission, except for limited
exceptions.
The exception defined in RFC 2026 is that "derivative works that
comment on or otherwise explain it [the IETF document] or assist in
its implmentation [sic] may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind..."
This has been generally interpreted to allow extracts to be used in
software implementations, user manuals, text books, and the like.
RFC 3667 and RFC 3978 added explicit wording to further clarify that
code extracts may be freely used by anybody: "(E) to extract, copy,
publish, display, distribute, modify and incorporate into other
works, for any purpose (and not limited to use within the IETF
Standards Process) any executable code or code fragments that are
included in any IETF Document...". However, RFC 3667 and RFC 3978 do
not mention the category of "derivative works that comment on or
otherwise explain..." For contributions made when they were in
force, use of non-code extracts for commentary and explanation
outside the IETF process appears formally to require explicit
permission from the original contributors. In many jurisdictions,
this might fall under the "fair use" provisions of copyright law or
their local equivalent, and in any case most RFC authors would be
glad of such use.
[RFC5378] extends the rights granted by contributors to the IETF (in
practice, the IETF Trust) such that the IETF itself (via the Trust)
can grant the right to make derivative works to third parties. Short
of a full copyright transfer to the IETF, this cleans up the
situation for new documents. It allows the IETF to grant rights to
Carpenter & Alvestrand Expires August 17, 2009 [Page 6]
Internet-Draft Including old text February 2009
third parties to make use of new IETF documents in any way the IETF
is happy with, and it leaves the original contributors free to do
what they want with their own work (even in ways the IETF is unhappy
with).
As noted in the Introduction, there is an issue if a current IETF
contribution, submitted under the new rules of RFC 5378, includes
material originally submitted by a different contributor under one of
the previous rules (including prior to RFC 2026 when there was no
rule). Suppose Alice plans to submit a draft under RFC 5378
containing a modified version of a section of an RFC originally
submitted by Bob under one of the older rules. This is a very common
situation, for example when a protocol needs clarification or
correction, or a new version is most conveniently documented by
revising the old text. There are several possible approaches, all of
which appear to fully respect Bob's rights without delaying
publication:
1. Alice looks at the IETF web site, and finds that the previous RFC
is listed as already being OK for use under RFC 5378 conditions,
or that Bob and his employer are listed as allowing any of their
contributions to be so used. Alice submits a draft using the
normal RFC 5378 boilerplate, and includes an acknowledgement of
Bob's contribution, such as: "Significant amounts of text have
been adapted from RFCxxxx written by Bob, who has agreed to the
text being submitted under the IETF's current copyright
provisions".
2. Alice can easily find Bob's email address and he rapidly agrees
that his old contribution may be used under current IETF rules.
Alice submits a draft using the normal RFC 5378 boilerplate, and
includes an acknowledgement of Bob's contribution, such as:
"Significant amounts of text have been adapted from RFCxxxx
written by Bob, who has agreed to the text being submitted under
the IETF's current copyright provisions".
3. Similar, except that Bob prefers to be listed as a co-author.
Again, the normal RFC 5378 boilerplate will be used.
4. Similar, except that this would increase the number of listed
authors above the limit preferred by the RFC Editor. In this
case, a list of fully identified Contributors would be used, as
defined in the RFC Editor's Editorial Guidelines.
5. Bob can't be found, or doesn't reply in a reasonable period of
time, or says he doesn't agree, or says that his previous
employer actually owns the rights, and it would take months of
discussion with their lawyers to get agreement. In such cases,
Alice goes ahead, but includes the IETF Trust's recommended
disclaimer in the draft. This is drawn to the attention of the
working group and the IETF at the time of Last Call. Alice also
includes a straightforward acknowledgement with more detail, such
as: "Significant amounts of text in sections X, Y and Z have been
Carpenter & Alvestrand Expires August 17, 2009 [Page 7]
Internet-Draft Including old text February 2009
adapted from RFCxxxx written by Bob."
The same possibilities would apply to text from an Internet-Draft
submitted prior to RFC 5378, or to significant and substantial
amounts of text posted as email as part of an IETF discussion prior
to RFC 5378.
There is scope for judgment and common sense when using small
fragments of text, whether taken from speech, email, a draft, or an
RFC. This Appendix doesn't define rules or offer legal advice, but
it is not suggested that any of the above alternatives is necessary
for odd phrases and sentences culled from normal ongoing IETF
discussion prior to RFC 5378. However, when in doubt, it is
presumably safer to include the disclaimer.
A rule of thumb may be that if the contribution quoted is so small
that its inclusion would not merit an acknowledgement according to
RFC 3667 rules, it does not merit a permission search under the rules
of this document.
Note that for jointly written drafts, all direct and indirect
contributors take responsibility for identifying text from other
contributors contributed prior to RFC 5378. If Alice submits a draft
written by herself, Alicia and Alize, all three are responsible for
verifying that any old text from other contributions that they have
re-used is handled according to this document.
What amounts to sufficient agreement from Bob? The IETF process
takes place mainly on-line, so a clear email agreeing to RFC 5378
conditions should be enough. However, it would be better if Bob also
provides the hard-copy general non-exclusive license suggested by the
IETF Trust. If Bob writes that he is replying on behalf of his co-
contributors, that should also be enough. But if Bob states that he
cannot speak for his previous employers, that is not enough on its
own. In many cases, employment laws or contracts do not leave Bob
with copyright in his own writings, so the previous employer's
agreement is needed. The best way for that to happen is for the
employer concerned to sign the Trust's general license. In most
cases, it probably isn't reasonable for Alice to pursue this option.
It will be a matter of judgment how hard to work on getting agreement
from Bob and possibly his previous employer. If the issue is judged
important, the WG Chair, the Area Director, or even the IETF Trust
might be asked to assist. However, it seems likely that in many
cases, that much effort may seem excessive, and it will be sufficient
to include the disclaimer. It should be remembered that the IETF's
ability to do its own work is absolutely unaffected by this result.
Carpenter & Alvestrand Expires August 17, 2009 [Page 8]
Internet-Draft Including old text February 2009
It should be noted that when the last alternative applies and the
disclaimer is included, the situation for a third party wishing to
re-use the old text is exactly as it always has been: the third party
has to identify the legitimate copyright holder(s) ("Bob") and get
their permission. The IETF, the IETF Trust, and the recent
contributors ("Alice") are not concerned.
The procedure defined in the main body of this document is intended
to ensure that in the case of affected documents, the contributors,
or people acting on their behalf, make a modest and reasonable effort
to gain agreement from earlier contributors that RFC 5378 rules may
be applied (basically, checking the IETF web site, and if necessary,
sending "Bob" an email). If this fails, they have a simple and
straightforward alternative - the disclaimer - which leaves all
parties no worse off than under the old rules. And in all cases,
normal good practice is followed by including an acknowledgment.
Authors' Addresses
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland 1142
New Zealand
Email: brian.e.carpenter@gmail.com
Harald Alvestrand
Beddingen 10
Trondheim 7013
Norway
Email: harald@alvestrand.no
Carpenter & Alvestrand Expires August 17, 2009 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 08:19:09 |