Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Lawrence Rosen wrote:

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.
Which there are serious concerns about whether the Trust ever owned that IP. I.e. that the transfer of the IP to the Trust is permanently flawed by the derivatively requirement's that all derivative works be licensed under the same rights requirements' are the originals are. 
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.
But the RFC is not an open license to use the IP for any and all purposes, i.e. that beyond publishing written copies of those IP's that the content can be used to create other IP's like Software Systems which implement that standard. 
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.
No we shouldn't Counsel. The Trust DOES NOT OWN ANYTHING that was licensed under RFC2026 unless a separate contract was executed by those authors authorizes that change in the original licensing.
The problem is that *** ANY *** derivative work which is done under a later filing but also includes component's or technology from one of those earlier filings those new filings must also track that earlier licensing. 
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. 
I disagree.

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]


yes.

/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.org [mailto:ietf-bounces at ietf.org] On Behalf Of
John Leslie
Sent: Friday, January 09, 2009 10:15 AM
To: dcrocker at bbiw.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.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.net>
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
------------------------------------------------------------------------


No virus found in this incoming message.
Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.4/1880 - Release Date: 1/7/2009 8:49 AM 



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.