[rfc-i] Copyrights and the IRTF and Independent Stream

John C Klensin john+rfc at jck.com
Sat Aug 15 15:17:00 PDT 2009



--On Thu, 13 Aug 2009 17:16:19 -0400, Leslie Daigle
<leslie at thinkingcat.com> wrote...

> While I can infer one or several implications from the nicely
> detailed  message below, I find I walk away without an
> understanding of:  what is  the desired usage of Independent
> (or IRTF or IAB) RFCs; what is the  *undesired* usage of them?
> I.e., absent a clear target, it seems hard  to really evaluate
> an appropriate copyright vehicle (whether it's driven  by or
> for the Trust or not).
> 
> In the case of the IETF stream, it's quite clear -- open usage
> of the  RFCs, and no right to end-run the IETF process.   Is
> there as clear a  sentiment in Independent, IAB or IRTF
> streams?  If yes, is it the IETF  process (only) that should
> not be end-run, or also the stream's?

Leslie,

There are a bunch of side issues here, including whether "open
usage" is an adequate description or synonym for RFC 5377 and
whether "RFC Editor Contribution", as used in 5378, includes all
non-IETF documents or only the Independent Stream.  

However, the core issue with the other streams, as I understand
it, is that they, especially the IRTF and Independent ones, want
readers/users to have unrestricted rights to make derivative
works subject only to attribution provisions.  There is also a
desire to make those rights available without depending on the
discretion of the Trust, especially given the Trust's apparent
deference to the IETF and its rules (as shown in the TLP) and
the absence of instructions in 5377 (see especially the "no
consensus" language in  Section 4.4, which I think Brian quoted
to the list earlier).  All 5378 says on this subject is that the
Trust may grant derivative works sublicenses and that it will be
guided by RFC 5377 (which says nothing, as mentioned above).

RFC 5378 also says (extracted from Section 3.6)
   [...]
	Ownership of the copyright in an RFC does not diminish
	the Contributors' rights in their underlying
	contributions, but it does prevent anyone other than the
	IETF Trust (and its licensees) from republishing or
	modifying an RFC in RFC format.  In this respect,
	Contributors are treated the same as anybody else:
	though they may extract and republish their own
	Contributions without limitation, they may not do so in
	the RFC format used by the IETF.
   [...]

While one could quibble endlessly about how similar to the "RFC
format used by the IETF" something would have to be to fall
under that provision (e.g., if something is published with a
non-IETF Stream Header as provided for in Headers and
Boilerplates, is it still in the "RFC format used by the IETF"
or is it then in another format?), at least some of us
understand that provision to be an anti-spoofing measure for
IETF Standards-Track materials, with little justification for
applying it to documents that clearly belong to other tracks.

I'm going to ignore the "no derived rights" cases below in the
interest of brevity.

So your question has two important answers, at least as I
understand things:

(1) It is not clear from 5378 that copyright in RFCs from
non-IETF streams published after November 2008 belongs to the
Trust.  Section 3.6 distinguishes between copyright in
Contributions and copyright in RFCs and then says 

	"However, it is important that the IETF (through the
	IETF Trust) own the copyright in documents that are
	published as RFCs (other than Informational RFCs and
	RFCs that are submitted as RFC Editor Contributions)."

That exclusion is repeated in Section 5.9:

	...each Contributor hereby acknowledges that the
	copyright in any RFC in which such Contribution is
	included, other than an RFC that is an RFC Editor
	Contribution, shall be owned by the IETF Trust."

So, while it was (or seemed) clear prior to the advent of the
Trust and of RFC 5378 that all RFCs published belonged to ISOC
and/or to the authors, there is some possibility that 5378 put
the Trust out of that business.  That leaves it unclear how the
documents should be published (e.g., with what copyright notice,
if any).  In additional, if the Trust doesn't own the copyright
in the RFC, it can't do any sublicensing.

(2) Because of concerns about activities that one stream or
another might want to encourage (see Aaron's note) being delayed
by the need to obtain specific licenses by the Trust and concern
that lack of guidance from the IETF (independent of requests
from the streams) might leave the Trust hesitant to grant very
broad "attribution only" licenses, the other streams might
prefer to have (and require that) those "attribution only"
rights be granted directly by authors to the public rather than
having them depend on the discretion of the Trust (and time
availability of the overworked Trustees).  But, unless those
grants are handled carefully and limited to non-IETF streams,
there is potential for them to interfere with the IETF's
intended use of copyright to prevent spoofing of standards.

As I understand it, the other streams have not been able to get
any traction on discussion of those issues with the Trust.  I
understand that there were some useful private discussions
during IETF 75 but, since they were private discussions whose
content and results (if any) have not been reported to the
community, I don't know if they are relevant or not.  Nor do I
know whether the failure to get traction is because the issue
hasn't been understood, the Trustees have higher priorities, or
for some other reason.   

I do know that we've got some fairly constipated streams for
what ought to be, IMO, a problem that is easily solved, at least
for the medium term, in at least two ways:

(1) The IESG could, with a bit of cleverness, un-do the
"obsoletes" properties of 5738 and turn them into "updates" with
regard to the IETF Stream only.  Depending on how the IESG felt
about procedures, that might require posting of an I-D and its
approval as an RFC, but that action could be initiated today
(and could have been initiated six months ago).  With that
action in place, the IASA could direct the RFC Editor to publish
non-IETF documents under RFC 3798 provisions, probably with ISOC
copyright.  That would return us to status quo ante and unblock
things.  Then, when and if the Trust got all issues with
non-IETF streams sorted out, ISOC could contribute any RFC IPR
it has accumulated to the Trust.

(2) The IASA could agree to publication of non-IETF Stream RFCs
with both an appropriate 5378-linked statement _and_ a statement
from the authors invoking a CC attribution-only license and then
advise the RFC Editor to go ahead and publish that way if so
advised by authors and the relevant streams.  That would make
the 5738 statement/license essentially a non-op (no one sane
would ask the Trustees for a license to do something that the CC
attribution-only license already gave them), but a harmless one.

Just my opinion, IANAL, I have an appeal pending, and other
disclaimers...
	
   john





More information about the rfc-interest mailing list