Including text under former copyright conditions
Department of Computer Science
University of Auckland
PB 92019
New Zealand
1142
Auckland
brian.e.carpenter@gmail.com
Beddingen 10
Norway
7013
Trondheim
harald@alvestrand.no
General
Network Working Group
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.
[[ Note to be removed by the RFC Editor: This version of the draft describes a completely
modified procedure compared to the one presented at IETF74, which did not obtain consensus.
It contains small and large changes throughout. Discussion is invited on the ipr-wg@ietf.org list. ]]
Terminology: In this document, the phrases "prior to RFC 5378" and "pre-5378" refer to
IETF Contributions made before November 10, 2008, when RFC 5378 became effective.
The phrase "Original Contributor" refers to an Indirect Contributor in the sense of ,
whose Contribution was prior to RFC 5378. Other terminology is defined in RFC 5378.
RFC 5378 failed to describe one case that has practical consequences.
The case is this: a new IETF Contribution contains material derived from one or more pre-5378 Contributions,
but the Original Contributors have not agreed to the specific additional rights
granted to the IETF under RFC 5378 compared to previous IETF rules.
In this case, the Contributor cannot accurately make the warranties
required by RFC 5378 with respect to the pre-5378 material included in
his or her Contribution.
This can arise when the Original Contributors, or their assigns, are unwilling,
unresponsive, unfindable, deceased, no longer in business, or simply too numerous.
This document is intended to specify the simplest possible solution for such
cases. Additional background information is given in below.
It should be noted that Section 5.6 of already requires
that Indirect Contributors must be acknowledged in all IETF documents. This continues
a requirement previously specified in section 3.4 (a) of
and , and in section 10.3.1 (4) of .
The present document extends this requirement in certain cases.
Contributors of Internet-Drafts that contain text originally
contributed to the IETF by other persons prior to RFC 5378 have certain responsibilities,
to be exercised to the best of their knowledge and ability.
Unless the Contributor(s) know that the Original Contributors have agreed
to their text being contributed under the terms of RFC 5378,
the Internet-Draft and any resulting RFC must include an appropriate legend of disclaimer.
The current text of this legend will be specified by the IETF Trust's
"Legend Instructions" as defined in . The
initial version of this text is given for informational purposes
in below.
If and only if this legend is included:
The acknowledgement required by Section 5.6 of should identify
the source(s) of pre-5378 text, such as RFCs and Internet-Drafts.
This requirement does not extend to small fragments of text culled from IETF discussions.
The acknowledgement should also identify which Original Contributors contributed which
sections of pre-5378 text.
This requirement does not apply if the text concerned is scattered throughout the document.
The IETF Trust is directed to ensure that its policies and licenses
allow for documents including the disclaimer.
[[ Discussion invited: is it appropriate and useful to include these
voluntary procedures? The BOF at IETF74 seemed to accept a "MAY" approach,
but there was no clear consensus call on that point. ]]
All Contributors to the IETF prior to RFC 5378 are invited to provide retroactively
to the IETF Trust the rights in their Contributions required by RFC 5378.
The IETF Trust may provide a public register
of pre-5378 documents 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 pre-5378 Contributions.
Contributors of Internet-Drafts including pre-5378 material who wish to avoid also
including the disclaimer may take any steps they wish, or ask helpers to take such steps,
to contact the Original Contributors and obtain their agreement to their text being
contributed under the terms of RFC 5378.
This document does not affect the security of the Internet.
This document requires no action by the IANA.
Much mailing list discussion by the IETF community, and private email discussions
with Scott Bradner, Jorge Contreras, Russ Housley, John Klensin, and others,
have led to this document. The discussions at IETF74 in San Francisco led
a significant rewrite.
This document was produced using the xml2rfc tool .
&RFC5378;
&RFC2629;
&RFC2026;
&RFC3667;
&RFC3978;
The current valid version should be taken from the IETF Trust's
"Legal Provisions Relating to IETF Documents", originally located at
.
The initial version was:
[[ Note to RFC Editor: please make sure this is the Trust's
current disclaimer text at the time of publication. ]]
"This document may contain 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 may not 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 or to translate it into languages
other than English."
This Appendix is not part of the formal rules of the IETF and does not
purport to offer legal advice. Contributors to the IETF who are in any doubt
as to how to proceed are advised to take appropriate legal advice.
Copyright provisions for IETF documents were first defined in
and were subsequently refined in and .
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.
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 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 significantly delaying publication:
Alice realises that the old material was written by a large number of "Bobs", or by people
no longer active in the IETF and possibly even deceased, or by people who no longer work for
the employer to whom their copyright was assigned by their conditions of employment, or any
other situation where obtaining their agreement is a substantial effort or a
practical impossibility. In this case, Alice includes acknowledgments and the disclaimer,
and we are done. The acknowledgment will look something like "Significant amounts of text
in sections X, Y and Z have been adapted from RFCxxxx written by Bob."
Alice looks at the IETF Trust 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".
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 with the same acknowledgment
as Option 2.
Similar, except that Bob prefers to be listed as a co-author. Again, the normal RFC 5378
boilerplate will be used.
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.
Bob 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 has
wasted her time, and she reverts to Option 1 above.
The same possibilities would apply to text from an Internet-Draft submitted prior to
RFC 5378, or to 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 about the copyright status of odd phrases and sentences culled from
normal ongoing IETF discussion prior to RFC 5378. However, the originators of such fragments
have the chance to complain about their use during Working Group or
IETF Last Call. Of course, when in doubt, it is always safe to include the disclaimer.
Note that for jointly written drafts, all direct and indirect contributors
take responsibility for identifying pre-5378 text from other contributors.
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 a reasonable amount of time to wait for Bob to reply, when trying
Options 3 through 6 above? There is normally no reason to wait more than a few days.
If the issue is considered unusually important for some reason,
it will be a matter of judgment how hard to work on getting agreement from Bob and
possibly his previous employer. The WG Chair, the Area Director,
or the IETF Trust might be asked to assist. However, it seems likely that in most cases,
that much effort will seem excessive, and it will be fine to include the disclaimer. It should
be remembered that the IETF's ability to do its own work is absolutely unaffected by this
result.
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 herself.
It should be noted that when 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 do not waste their time. They, or people acting on their
behalf, may choose to make a modest and reasonable effort to gain agreement
from earlier contributors that RFC 5378 rules may be applied (basically, checking the IETF Trust web site,
and if necessary, sending "Bob" an email). But they have a simple and straightforward default choice - 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.