John Leslie wrote: > I may not be the one to explain, but I _don't_ think that's what > the proposal calls for. I think it calls for inclusion of the > boilerplate I listed above, which simply disclaims knowledge of > _whether_ all the rights of 5378 are granted (and thus derivative > works "outside the IETF Standards Process" are not authorized by > the IETF Trust). I want derivative works "outside the IETF Standards Process" to be authorized by the IETF Trust and see no legal reason, at least in US law, why the IETF Trust can't authorize that without even mentioning the co-authors of those RFCs. The concern expressed in this thread is whether derivative works are authorized by the co-authors of those earlier RFCs. We need no statement (admission of guilt or otherwise) about that. Users of IETF RFCs should be comfortable that at least the IETF Trust authorizes such derivative works. Certainly the term "open industry standard" must mean that an RFC is a cooperative expressive and technical work by individuals and companies interested in a common result. We should accept the notion that IETF, and now the IETF Trust, as a public interest corporation that manages the expressive creative activities through which these joint works are written, is the joint owner of copyright in every RFC. As such, a license from the IETF Trust is all we need to create derivative works, without even asking the co-authors of those old (or new) documents. Does anyone here believe that the IETF Trust doesn't own a joint copyright interest in every RFC it publishes and can thus authorize derivative works of those RFCs? [1] /Larry [1] I intentionally avoid the argument, made in my previous emails here, that we don't even need the permission of the IETF Trust to copy and modify--when necessary for functional purposes--any industry standard specification. That's a bigger argument based on 17 USC 102(b), not one based on the Copyright Act definition of "joint work": "A 'joint work' is a work prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole. 17 USC 101. Lawrence Rosen Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com) 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243 Skype: LawrenceRosen > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of > John Leslie > Sent: Friday, January 09, 2009 10:15 AM > To: dcrocker@xxxxxxxx > Cc: IETF Discussion > Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your > reviewand comments on a proposed Work-Around to the Pre-5378 Problem > > Dave CROCKER <dhc2@xxxxxxxxxxxx> wrote: > > > > A number of the comments, so far, appear to hinge on a rather basic > > cost/benefit model that is clearly quite different from what the > proposal > > is based. I suspect that difference comes from a different sense of the > > problem, per John Klensin's posting. > > Agreed. > > > My reference to "legality" is based on a view of the proposal which sees > > it as having individual submitters essentially say "I am required to get > > permission and I have not gotten it". That's an admission of guilt... > > I don't read it that way. Refer to: > > http://trustee.ietf.org/docs/Draft-Update-to-IETF-Trust-Legal-Provisions- > 1-06-09.pdf > ] > ] 6. c. iii. > ] ... This document contains material from IETF Documents or IETF > ] Contributions published before November 10, 2008 and, to the > ] Contributor's knowledge, the person(s) controlling the copyright > ] in such material have not granted the IETF Trust the right to allow > ] modifications of such material outside the IETF Standards Process. > ] Without obtaining an adequate license from the person(s) controlling > ] the copyright, this document may not be modified outside the IETF > ] Standards Process, and derivative works of it may not be created > ] outside the IETF Standards Process, except to format it for > ] publication as an RFC and to translate it into languages other than > ] English. > > If you believe there is an admission of guilt there, please send > text. (But understand, lawyers have to sign off on any changes.) > > > And if you don't think that's what the proposal calls for, please > > explain, because I don't think my interpretation is all that creative. > > I may not be the one to explain, but I _don't_ think that's what > the proposal calls for. I think it calls for inclusion of the > boilerplate I listed above, which simply disclaims knowledge of > _whether_ all the rights of 5378 are granted (and thus derivative > works "outside the IETF Standards Process" are not authorized by > the IETF Trust). > > >> This situation has halted the progression of some Internet-Drafts and > >> interrupted the publication of some RFCs. > > > > This means that we have a crisis which is stopping productive work, > > yet the crisis appears to be caused by a faulty new requirement, > > rather than by the situation that the document seeks to correct. > > True... > > > In other words, remove the new requirement and we no longer have a > > crisis. We have an issue to pursue -- the same one that prompted > > the new requirement -- but no crisis. > > Alas, I must disagree. We have an IETF Consensus document (5378), > and that consensus must be overturned to get to where Dave claims > we are. In my experience, overturning consensus is hard. (That's > the _point_ of having a consensus process.) > > However wrong some of us (now) believe that consensus to be, we > should not expect to overturn it in 30 days -- whereas this quick > fix can be applied in 30 days. I strongly urge all of us to let > the quick fix go through without holding it hostage to overturning > the consensus of 5378. > > -- > John Leslie <john@xxxxxxx> > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf