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

Leslie Daigle leslie at thinkingcat.com
Mon Aug 31 17:36:16 PDT 2009

Having pursued this out-of-band with another list reader -- a little bit 
of clarification of my point...

Looking at the timeline of any given I-D:

T0:  I-D version -00 is submitted to the drafts repository
Ts:  I-D is accepted for consideration in a stream approval process
Ta:  I-D is approved for publication
Tp:  I-D is published as an RFC

For IETF work, Ts is when a document is accepted as a working group 
item, or at some (currently not well demarcated) point in the process of 
having it published as an individual RFC reviewed by the IESG.

One part of the discussion is "what copyright should apply at Tp" -- 
IETF is restrictive, the IRTF and Independent streams want more open 
copyright.  Cool.

The other part of the discussion is:  at what point in that timeline 
does the copyright requirement at Tp get applied?

For IETF processes, there are a number of good reasons why the copyright 
at Ts needs to align with that at Tp:  the IETF needs to know it can 
continue to work on the documents circulated within its processes, and 
so on and so forth.

In your first note, it seemed the suggestion was you would need to know 
what  stream the document was going to be published in, at T0.  I.e., 
that you would apply the copyright regime of Tp at T0.  I think that's 
unrealistic, and unnecessary.  How many documents get started as 
personal contributions, aimed at a WG, possibly spending some time 
there, and ultimately getting published as an Independent (stream) 
document?  More than 2....

So, I think the copyright at T0 should be independent of stream;  that 
there need to be enough valid copyright notices available at T0 to cover 
all streams (though they don't have to be tied to streams); and that as 
documents get considered in a stream (Ts), they could be respun with 
appropriate copyright for the stream (and possibly several iterations of 
that, if the document changes streams).


Leslie Daigle wrote:
> Having read the thread, I'd like to come back to this particular 
> question.  (Feel free to forward this as appropriate -- this mailer 
> seems to strip off all CC's, so I've no idea where this went/should go).
> I think SM nailed it with the question " What are the decision makers 
> trying to achieve through copyrights?".
> Setting aside the question of what the Trust is constituted to do (and 
> what motivations it might have), it seems like your option 2 below 
> smells of delegating material decisions outside the stream decision 
> makers' realm, and that seems wrong.  It's the streams that have the 
> responsibility of identifying what they need (now and going forward), 
> however unpalatable the task of expressing that in legalese.
> That said, I don't understand the "have to figure out which stream the 
> RFC will appear in" theme:  that'll never be concrete; it isn't today, 
> and it would break things if we tried to cast it in stone, IMO.
> Perhaps a more reasonable approach would be:
> I-D's:
> Create/encourage a "derivative works with attribution" boiler plate for 
> I-Ds.  (Whether this assigns any rights to the Trust is a separate matter)
> RFC Streams:
> Each stream figures out what rights it requires in order to accept I-D's 
> for consideration.  For the IETF, this is clearly 5378 only.  If an I-D 
> has been published a few times with more liberal rights, it has to be 
> respun with that copyright.   Other streams can determine whether they 
> accept things with more liberal rights attached.
> I realize that this means a document could get to -10 with liberal 
> rights, and then do a quick respin to -11 with 5378 rights and get 
> published as an IETF stream RFC, leaving the penultimate version free 
> for use in a much more liberal fashion than the IETF would like.  But, 
> that's why I think SM's question is spot on...
> Leslie.
> Olaf Kolkman wrote:
>> 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
>> ------------------------------------------------------------------------
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest at rfc-editor.org
>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest


      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
leslie at thinkingcat.com

More information about the rfc-interest mailing list