Olaf Kolkman | 13 Aug 19:01
Picon
Favicon

Copyrights and the IRTF and Independent Stream


[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.
(Continue reading)

Scott Brim | 16 Aug 14:19
Picon
Favicon

Re: Copyrights and the IRTF and Independent Stream

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?
_______________________________________________
Ipr-wg mailing list
Ipr-wg <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipr-wg
Joel M. Halpern | 16 Aug 17:14

Re: Copyrights and the IRTF and Independent Stream

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:
> 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?
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipr-wg
Scott Brim | 16 Aug 17:45
Picon
Favicon

Re: Copyrights and the IRTF and Independent Stream

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.
> 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:
> >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?
Todd Glassey | 16 Aug 18:42
Picon
Favicon

Re: Copyrights and the IRTF and Independent Stream

Joel M. Halpern wrote:
> 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.
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 
(Continue reading)

Marshall Eubanks | 17 Aug 17:02
Picon

Proposed Policy for Modifications to Trust Legal Provisions (TLP)

Greetings;

During the last review of the Trust Legal Provisions (TLP),
it became clear that there is no clear
procedure for modifying the TLP.  The current TLP only states that a new
version may be published for community review but not who can ask for  
a change,
where announcements are sent, where the changes can be discussed and  
many
other things.  As a consequence, there have been questions about why  
the IETF Trust is proposing changes to the TLP, the problems that the  
changes fix, and the consequences of the changes.

In order to solve this problem, we have drafted a conceptual procedure  
for modifying
the TLP in the future.  This procedure can be found below.  We want to  
engage in a dialogue on these general concepts. Note that in items  
1,2,3,4 and 6, there is an implicit "Or" between each of the choices.

Assuming that consensus on the general ideas can be reached, the Trust
will submit a document describing this process in mid-September, 2009.  
I invite
interested parties to read and comment. This will be disseminated to  
the IETF Discuss and announce list, WG Chairs list, the old IPR WG  
List, the RFC Editor List and the IESG, IAB and IRSG lists. Please  
feel free to disseminate it to other interested parties, and please  
let me know if I left out a suitable list to alert.

Regards
Marshall Eubanks
(Continue reading)

Stephan Wenger | 17 Aug 17:29
Gravatar

Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)

Hi Marshall, all,

This is a good proposal.

Would it be possible to enhance the review periods (steps 5 and 6) from
30/14 days to something like 60/30 days, respectively?  Many people will
need to go through corporate counsel on matters like this, which can be time
consuming.  30 days is a quite typical vacation period in many European
countries.  And, for emergencies, there is the emergency procedure with 14
days review period (which I do not propose to adjust).

Regards,
Stephan

On 8/17/09 5:02 PM, "Marshall Eubanks" <tme <at> americafree.tv> wrote:

> Greetings;
> 
> During the last review of the Trust Legal Provisions (TLP),
> it became clear that there is no clear
> procedure for modifying the TLP.  The current TLP only states that a new
> version may be published for community review but not who can ask for
> a change,
> where announcements are sent, where the changes can be discussed and
> many
> other things.  As a consequence, there have been questions about why
> the IETF Trust is proposing changes to the TLP, the problems that the
> changes fix, and the consequences of the changes.
> 
> In order to solve this problem, we have drafted a conceptual procedure
(Continue reading)

Marshall Eubanks | 17 Aug 17:49
Picon

Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)


On Aug 17, 2009, at 11:25 AM, Marc Blanchet wrote:

> Marshall Eubanks a écrit :
>>
>> Emergencies.  An emergency is defined as "there is a problem with the
>>  TLP that is likely to be abused".  In these cases, the trust can  
>> publish
>>  a modified text for a 2 week review period, then modify the TLP.   
>> The
>>  Trust must explain the reason for the change.
>
> I have a hard time thinking of an emergency that can be fixed by a
> timely change in the TLP which would likely require a lot of heavy  
> legal
> advice and related work and coordination. Changes in policies may have
> important impacts over time that would probably require enough time to
> review. To me, the TLP should be a pretty stable document.
>
> However, I might think of an emergency for a immediate legal action,  
> but
> not sure about an emergency change in the TLP.
>
> I guess I need to be educated on the use case for the emergency track.
>

My personal feeling is that we won't really know until we have had a  
few, which hopefully will take
a very long time. But, it seems worthwhile to have some sort of "in  
case of emergency, break glass"
(Continue reading)

Marc Blanchet | 17 Aug 17:25
Picon
Favicon

Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)

Marshall Eubanks a écrit :
> 
> Emergencies.  An emergency is defined as "there is a problem with the
>   TLP that is likely to be abused".  In these cases, the trust can publish
>   a modified text for a 2 week review period, then modify the TLP.  The
>   Trust must explain the reason for the change.

I have a hard time thinking of an emergency that can be fixed by a
timely change in the TLP which would likely require a lot of heavy legal
advice and related work and coordination. Changes in policies may have
important impacts over time that would probably require enough time to
review. To me, the TLP should be a pretty stable document.

However, I might think of an emergency for a immediate legal action, but
not sure about an emergency change in the TLP.

I guess I need to be educated on the use case for the emergency track.

Marc.

--

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
Marc Blanchet | 17 Aug 17:56
Picon
Favicon

Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)

Marshall Eubanks a écrit :
> 
> On Aug 17, 2009, at 11:25 AM, Marc Blanchet wrote:
> 
>> Marshall Eubanks a écrit :
>>>
>>> Emergencies.  An emergency is defined as "there is a problem with the
>>>  TLP that is likely to be abused".  In these cases, the trust can
>>> publish
>>>  a modified text for a 2 week review period, then modify the TLP.  The
>>>  Trust must explain the reason for the change.
>>
>> I have a hard time thinking of an emergency that can be fixed by a
>> timely change in the TLP which would likely require a lot of heavy legal
>> advice and related work and coordination. Changes in policies may have
>> important impacts over time that would probably require enough time to
>> review. To me, the TLP should be a pretty stable document.
>>
>> However, I might think of an emergency for a immediate legal action, but
>> not sure about an emergency change in the TLP.
>>
>> I guess I need to be educated on the use case for the emergency track.
>>
> 
> My personal feeling is that we won't really know until we have had a
> few, which hopefully will take
> a very long time. But, it seems worthwhile to have some sort of "in case
> of emergency, break glass"
> procedure.

(Continue reading)


Gmane