ietf
[Top] [All Lists]

RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem

2009-01-09 14:10:13
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(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
John Leslie
Sent: Friday, January 09, 2009 10:15 AM
To: dcrocker(_at_)bbiw(_dot_)net
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(_at_)dcrocker(_dot_)net> 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(_at_)jlc(_dot_)net>
_______________________________________________
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

<Prev in Thread] Current Thread [Next in Thread>