Re: RFC 5378 "contributions"

On Jan 16, 2009, at 4:54 AM, Tom.Petch wrote:

> ----- Original Message -----
> From: "Theodore Tso" <tytso(_at_)mit(_dot_)edu>
> Sent: Friday, January 16, 2009 1:23 AM
>
> > On Thu, Jan 15, 2009 at 11:50:46AM -0500, Marshall Eubanks wrote:
> > > Consider the threat model here.
> > >
> > > This threat applies ONLY to material that the Trust licenses to
> > > third parties (such as, say, the IEEE) for inclusion and
> > > modification in their standards. (Just reprinting or translating an
> > > RFC is not at issue.)
> > So this licensing to third parties is not automatic; which makes  
> > sense
> > in terms of letting the IESG to have a control point before allowing
> > another standards body to take over a standard (or try to take over a
> > standard).
> Well, no. To me, RFC5378 asks that future Contributions include an  
> unrestricted
> right to produce derivative works (previously restricted to within  
> the IETF)
> which right is given to the IETF Trust.  RFC5377 guides the IETF  
> Trust as to
> when this right should be given to third parties but it is the IETF  
> Trust that
> decides.  I see no role for the IESG.
Note that the IETF Trustees include (RFC4071)

o  One member appointed by the IESG;
o The IETF Chair (ex officio);
so the Trust certainly has a IESG representation.

Regards
Marshall

is IETF Chair

> We have put our trust in the IETF Trust,
> to produce legends and to exercise grants; that is what I see us as  
> having
> signed up to when we endorsed RFC5377.
>
> eg s.3 "the legal authority for determining and granting users
>   rights to copy material in RFCs and other IETF Contributions rests
>   with the Trustees for the IETF Trust"
>
> Tom Petch
>
> > However, that presumably wouldn't be tree for allowing text or code  
> > to
> > be used in implementations, open source or otherwise --- I assume
> > that wouldn't require prior permission first, right?
> >
> > > If the Trust does NOT license your material to third parties, then  
> > > there
> > > is no infringement, no one with standing to sue, and no risk to  
> > > authors.
> > > It may be necessary for the Trust to state that they will not  
> > > assume 5378
> > > to be in place for this purpose until there is a replacement. (In  
> > > that
> > > case, if the IEEE or some other body wants to take over an RFC and  
> > > modify
> > > it, they will have to get explicit permission from all authors until
> > > there is a replacement for 5378 in place, just as they did before  
> > > 5378 as
> > > put into place.) My understanding is that the Trust is responsible  
> > > for
> > > these licenses, and so they could just (in their best judgement)  
> > > refuse
> > > to issue them without further conditions.
> > So there probably isn't much risk for a standards bodies wanting to
> > take over a MIB, for example, But what about someone using pseudo- 
> > code
> > from a RFC where the RFC editor is required to make an assertion that
> > he/she had all of the rights, and the code or pseudo code was
> > contributed by a third party who copied the code from some Microsoft
> > source they had access to while they were a graduate student?
> >
> > > Or (and this is my opinion), maybe the authors should only warrant
> > > _their work_ as being subject to such licenses, and put the burden  
> > > on
> > > the Trust to obtain any necessary approvals from other parties, only
> > > alerting the Trust to the extent they know of such prior  
> > > authorship. My
> > > understanding is that this would require a 5378bis.
> > That I think is the key; each person can only warrant what they
> > themselves have authored.  Something that might be worth looking at  
> > is
> > the Developer's Certification of Origin, which is how Linux Kernel
> > developers deal with contributions for the Linux Kernel.  Anything
> > which gets incoproated into the kernel must have a Signed-off-by,  
> > like
> > this:
> >
> > Signed-off-by: "Theodore Ts'o" <tytso(_at_)mit(_dot_)edu>
> >
> > What this mean is an explicit assertion of the following:
> >
> > Developer's Certificate of Origin 1.1
> >
> > By making a contribution to this project, I certify that:
> >
> >        (a) The contribution was created in whole or in part by me  
> > and I
> >            have the right to submit it under the open source license
> >            indicated in the file; or
> >
> >        (b) The contribution is based upon previous work that, to  
> > the best
> >            of my knowledge, is covered under an appropriate open  
> > source
> >            license and I have the right under that license to  
> > submit that
> >            work with modifications, whether created in whole or in  
> > part
> >            by me, under the same open source license (unless I am
> >            permitted to submit under a different license), as  
> > indicated
> >            in the file; or
> >
> >        (c) The contribution was provided directly to me by some other
> >            person who certified (a), (b) or (c) and I have not  
> > modified
> >            it.
> >
> > (d) I understand and agree that this project and the contribution
> >    are public and that a record of the contribution (including all
> >    personal information I submit with it, including my sign-off) is
> >    maintained indefinitely and may be redistributed consistent with
> >    this project or the open source license(s) involved.
> >
> > This would obviously have to be modified for the IETF's purpose, but
> > what's nice about it is that each Linux Kernel Developer is only
> > making assertions about things which he or she has personally has
> > control over, and by using the Signed-off-by chain, it's possible to
> > see the handoffs as the patch was passed up the chain from one
> > developer to another, i.e:
> >
> > commit 166348dd37a4baacfb6fe495954b56f56b116f0c
> > Author: Aneesh Kumar K.V 
> > <aneesh(_dot_)kumar(_at_)linux(_dot_)vnet(_dot_)ibm(_dot_)com>
> > Date:   Mon Sep 8 23:08:40 2008 -0400
> >
> >    ext4: Don't add the inode to journal handle until after the  
> > block is
> allocated
> >    Make sure we don't add the inode to the journal handle until  
> > after the
> >    block allocation, so that a journal commit will not include the  
> > inode in
> >    case of block allocation failure.
> >
> >    Signed-off-by: Aneesh Kumar K.V 
> > <aneesh(_dot_)kumar(_at_)linux(_dot_)vnet(_dot_)ibm(_dot_)com>
> >    Signed-off-by: Mingming Cao <cmm(_at_)us(_dot_)ibm(_dot_)com>
> >    Signed-off-by: "Theodore Ts'o" <tytso(_at_)mit(_dot_)edu>
> >
> > - Ted
> > _______________________________________________
> > Ietf mailing list
> > Ietf(_at_)ietf(_dot_)org
> > https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf