Re: #1273 How do we usefully define "excerpt"?

["todd glassey" <todd.glassey at worldnet.att.net>]

OK how about a simple solution here - lets ask the question "Why would you
allow people to make derivatives of the IP without noticing them as the
IETF's?" - my answer is that you wouldnt. So how about we create registered
and unregistered derivatives which is how you get to use the IETF's TM in
print outside of the standards process.

This way you just say "this protocol is an unregistered derivative of
RFCxxxx's version WabaWaba" if you want to publish the protocol and note its
origin without giving anything back to the IETF.

That way - you dont allow the use of the IETF's TM on it unless it becomes a
registered derivative. And this way all the IETF has to do is bill people
for the registration fee, right? That was what the Trust wanted to do eh?

T.

----- Original Message ----- 
From: "John C Klensin" <john-ietf at jck.com>
To: "Simon Josefsson" <jas at extundo.com>
Cc: "Ted Hardie" <hardie at qualcomm.com>; "Brian E Carpenter"
<brc at zurich.ibm.com>; "Tom Petch" <nwnetworks at dial.pipex.com>;
<ipr-wg at ietf.org>
Sent: Tuesday, May 02, 2006 2:54 PM
Subject: Re: #1273 How do we usefully define "excerpt"?


>
>
> --On Tuesday, 02 May, 2006 21:17 +0200 Simon Josefsson
> <jas at extundo.com> wrote:
>
> > John C Klensin <john-ietf at jck.com> writes:
> >
> >>> I think the discussion so far has convinced me that the
> >>> appropriate way to handle this is to make the correction in
> >>> commentary, e.g. "This is specified in the RFC as  BAR =
> >>> numchar, but I believe that BAR = 1*numchar was meant, and I
> >>> have implemented accordingly" .  I would obviously suggest
> >>> putting in an erratum for the RFC as well.
> >>
> >> Of course, such commentary is of the nature of a critical
> >> review and does not raise any of the same copyright issues as
> >> incorporating the original text in modified form.
> >
> > Are you referring to US copyright "fair use"?  That doesn't
> > hold universally...  granting the same, explicit, rights to
> > everyone appear preferable.
>
> No, I wasn't.  I was referring to the ability of anyone, at any
> time, to say "This is an implementation of RFC nnnn, except that
> section 666 of that RFC says 'BAR=numchar'.  That appears to be
> incorrect and this implementation handles BAR as 1*numchar
> instead."
>
> As I understand it, that would not violate copyright laws
> anywhere.   To do so would require giving the author of the RFC
> ownership of particular words, such as "BAR" and "numchar" and
> that just doesn't happen absent trademarks.
>
> One of the places where we apparently disagree is that I don't
> believe it is ever _necessary_ to quote extensively from the
> text of an RFC to implement the specification in one.  Inclusion
> by reference (citation) works except when the material to be
> excerpted  is material that cannot be expressed in any other way
> without changing its meaning -- code snippets, mapping or
> similar tables, header material, or the like -- and that
> material is not supposed to be copyrightable.    Now we agree
> that it would be undesirable to leave that material (at least)
> in a situation in which one would need to take a chance,
> implement, and then ask a judge.  But that is why I favor
> clearly identifying it.
>
> I also agree with Tom (and I think Ted): the right way to
> "correct" SSL-> SSH is to say "He said SSL but I am sure he
> meant SSH", not by making the character substitution.   The
> difference between the two is substantive: the former alerts the
> reader that there has been a change and that there might be a
> difference of opinion about its correctness.  The second doesn't
> give the reader a clue that she is expected to go back, find the
> original document, and compare it with the excerpted or derived
> one  to see what changes have been made under the guise of
> correcting apparent typographical errors.
>
> What I don't know is how to resolve this: I think we understand
> each other's positions fairly well and I don't think our
> approaching the issue from different perspectives and then
> essentially repeating ourselves is going to convince either each
> other or, at this point, anyone else.
>
>       john
>
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wg at ietf.org
> https://www1.ietf.org/mailman/listinfo/ipr-wg


_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg