----- Original Message ----- From: "Theodore Tso" <tytso@xxxxxxx> 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. 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@xxxxxxx> > > 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.kumar@xxxxxxxxxxxxxxxxxx> > 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.kumar@xxxxxxxxxxxxxxxxxx> > Signed-off-by: Mingming Cao <cmm@xxxxxxxxxx> > Signed-off-by: "Theodore Ts'o" <tytso@xxxxxxx> > > - Ted > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf