Subject: Copyrights and the IRTF and Independent Stream

From: Olaf Kolkman <[email-masked]>
Date: Thu, 13 Aug 2009 19:01:15 +0200

[Cross post]

Dear Colleagues,

This mail is about rights in RFCs and Internet drafts. The topic draws
context, and uses terminology from:
RFC 4844: The RFC Series and RFC Editor
RFC 4846: Independent Submissions to the RFC Editor
RFC 5378: Rights Contributors Provide to the IETF Trust
RFC 5377: Advice to the Trustees of the IETF Trust on Rights to Be
Granted in IETF Documents

First some administrational notes.

This mail serves as setting a baseline for a public discussion and is
based on a few (virtual and real-life) hallway discussions. The goal
of this discussion is to make sure all issues are brought to the table
and the stream maintainers and the Trust are aware of the communities
opinions. I see my role as an IAB member that is driving the
discussion, and mildly moderating it. In the end it is the role of the
IAB to see that an appropriate stream dependent process has been
followed and that the streams do not interact inapropriatly. So in
that sense this discussion informs the IAB too.

Although this mail is sent to multiple lists I would like to urge folk
to discuss the issues on the rfc-interest list:
   http://www.rfc-editor.org/mailman/listinfo/rfc-interest

Without further ado.

As you may know RFCs are published from different streams. With
respect to the incoming and outgoing rights only the rights of the
IETF stream documents are well defined. And currently the IAB has
chosen to have IAB documents fall under this regime too. The situation
is less clear for Independent and IRTF Stream documents: all existing
provisions are targeted specifically towards IETF Contributions (in
the narrow context defined by RFC5378). Besides, currently and in the
context of copyrights, Internet Drafts (I-Ds) are seen as IETF
contributions.

Maintainers of the Independent and IRTF stream would like to have
documents from their streams published with full rights to make
derivative works or make no derivative works whatsoever, and require
attribution in both cases.

There are two strategies to make this work:

1. Allow I-Ds and RFCs for the IAB, IRTF, and Independent stream to be
published with a Creative Commons license added.

A rough outline of one of the ideas that is floating around ist that
all contributions that are intended to become an RFC or are an IETF
contribution (in the sense of RFC 5378 definition) will continue to
have the 5378 license terms as defined by the trust. Since 5378 is
non-exclusive authors may add a creative commons license if they'd
like to. Care should be taken that those licenses would not be applied
to IETF contributions, as that could lead to 'spoofed standard-track
RFCs'

2. Have the trust manage the rights for the IAB, IRTF, and Independent
streams RFCs and I-Ds.

Both strategies may require that at the moment Internet Drafts is
published as an RFC it is clear on which stream they are intended to
be published, with which rights, and that the authors have appropriate
authority to grant/sublicense those rights.

In both cases we want to avoid that IETF contributions (I-Ds and
RFCs, although it is not clear whether this is a strong requirement
for I-Ds) are published with a license policy that would circumvent the
Trust's control over the outgoing rights.

A tactic/straw-man to implement (2) is as follows:

    i) Treat all I-Ds as or similar to IETF contributions (this way
       there is no doubt about the Trust having all necessary rights,
       see BCP78 section 5.3). There seem to be two paths to proceed:

        i.1) The stream controllers choose to apply the RFC5378 rules.
        	    This possibility is offered in section 4 of 5378 and the
  	    IAB stream chooses to apply the rules through its
	    declaration in section 11.

        i.2) The streams write a stream specific "Rights contributors
             provide to the IETF trust" document.

     ii) Have the stream controllers request  the IETF Trust to create
         license(s) for non IETF-Stream RFCs that grant for (full|no)
	derivative rights, attribution required. (document this
	request in an RFC).

    iii) Ask the trust to develop language that can be put on an I-D
         with which the author can request (full|no) derivative rights
         if/when the I-D is published on a specific non-IETF stream
	document. This sort of text would serve as an indication of
	consent with wide licensing and could be included as
	boilerplate material together with an indication of intended
	stream (as in draft-iab-streams-headers- boileplates).

There are some pros and cons to this scheme that we need to identify
in public discussion, hence this mail.

During the hallway discussion, I've seen the following arguments and
identified the following open questions. I don't claim completeness.

- The Trust is not well equiped to hold non-IETF documents. Mainly
   because it requires the interperetation that all documents are IETF
   Documents.

   Is this interpretation based on language in the Trust agreement or
   on the definition of IETF Documents in the context of BCP78?

   Or, is the trust well suited, and does implementation only need some
   boilerplate changes?

- IETF Stream RFCs need to be protected by limited derivative rights
   so that the IETF keeps ownership over its Standards and can maintain
   those.

   Suppose a I-D with full derivative rights is posted (either because
   the author has published it with Creative Commons, or because the
   Trust allows full derivative rights for stream specific I-Ds) would
   narrowing down the rights by publication as an IETF stream RFC cause
   any problems?

Feedback welcome,

--Olaf Kolkman

---

From: Scott Brim <[email-masked]>
Date: Sun, 16 Aug 2009 08:19:53 -0400

What happens when an IRTF document becomes polished enough that it is
adopted by the IETF and put on standards track?  If the text is
already published under one rights regime, can the IETF then apply
more restrictive conditions?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 16 Aug 2009 11:14:07 -0400

I believe that the simple answer is "yes", as long as one understands 
what is happening.
There is an IRTF RFC.  It grants all rights to anyone to make derivative 
works, modify, etc.
Then, one of the derivative works is the IETF I-D and eventual RFC. 
Even if there is no change in text (almost unheard of), it is a 
different work, and that work has the more restrictive rights for 
derivation.
Yes, we would have to understand that anyone could go back to the IRTF 
RFC and do anything they want with that text.  Those rights can not (and 
should not) be revoked.

Yours,
Joel

Scott Brim wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ipr-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: Scott Brim <[email-masked]>
Date: Sun, 16 Aug 2009 11:45:09 -0400

OK, there's at least one way of looking at it that works.  

Excerpts from Joel M. Halpern on Sun, Aug 16, 2009 11:14:07AM -0400:
> I believe that the simple answer is "yes", as long as one
> understands what is happening.
> There is an IRTF RFC.  It grants all rights to anyone to make
> derivative works, modify, etc.
> Yes, we would have to understand that anyone could go back to the
> IRTF RFC and do anything they want with that text.  Those rights can
> not (and should not) be revoked.
> 
> Yours,
> Joel
> 
> Scott Brim wrote:
> >What happens when an IRTF document becomes polished enough that it
> >is adopted by the IETF and put on standards track?  If the text is

---

From: Todd Glassey <[email-masked]>
Date: Sun, 16 Aug 2009 09:42:35 -0700

Joel M. Halpern wrote:
> RFC and do anything they want with that text.  Those rights can not 
> (and should not) be revoked.
cannot be contractually revoked is the operative phrase - nothing else 
is relevant. The same is true of any old versions of RFC's. There is 
nothing in the IETF's process which forces adopters to keep their 
technology current to released standards which is something that has 
caused a number of things in the real world including security holes in 
products being allowed to remain.

Seriously - once an "IETF Technology Grant to the Public" is made which 
is what the publication under the existing terms are, that granted work 
cannot be revoked or changed in any way - even deprecating a RFC or 
Standard Document for a new version or RFC may stop people from working 
on those old documents in the IETF but in the real world are meaningless 
based solely on the licensing the IETF made available.

There is another issue I want to add to this and that is when data in 
associated mailing lists from Work Group List Sponsors strays into IETF 
work under Note Well, those IP's should also be part of the IETF 
evidence archive for each and every standards run. Entities who sponsor 
IETF WG Lists in many instances also sponsor their own development lists 
which then feed pre-vetted content into the IETF Standards process but 
without these ancillary communications it is impossible to see what that 
vetting is.

That said we need a special rule for "IETF Mailing List Sponsors which 
states that any mailing lists they operate under the provision as a 
trustee for holding evidence of the IETF's standards development 
process, must provide that material with the archives of the IETF 
Mailing List they manage for the IETF's WGs. Also those digital content 
streams must be kept safe from alteration and editing by 
cryptographically signing them with a set of tools built for maintaining 
IETF lists."

And of course we will need a WG to build that tool set

Todd

> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.392 / Virus Database: 270.13.58/2305 - Release Date: 08/15/09 18:10:00
>
>