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

From: Simon Josefsson <[email-masked]>
Date: Tue, 02 May 2006 12:02:47 +0200

"Tom Petch" <[email-masked]> writes:

>> > * Fix spelling typos
>>
>> Opinion: OK, as is translation from English
>>
> Disagree, your fixing a typo is my change of meaning; even a change of
> punctuation can change the meaning.

Changing the meaning isn't fixing a typo.  If fixing a typo changes
the meaning of the protocol, it is no longer a "good-faith" typo fix.

There may be edge cases, but I'd say that if a "typo fix" leads to
even minor technical differences, it isn't a "typo fix" anymore, but
must be treated as a "modification".

(Of course, I argue that modifications should be permitted as well,
but that is another discussion.)

Regards,
Simon

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 May 2006 10:55:03 -0700

At 12:02 PM +0200 5/2/06, Simon Josefsson wrote:
>"There may be edge cases, but I'd say that if a "typo fix" leads to

The problems really come in when the individual doesn't fully understand
what is being specified and fixes it to something they do understand.  In
one recent exchange with a technical editor, for example,  "uuencoded" got
fixed to "unencoded".  I presume that the editor did not know what
uuencoded meant, and did know what unencoded meant; the paragraph
made sense with "unencoded" in that slot, but that wasn't what was intended.

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.

For typos like "there implementation", insert a "sic" if you can't stand leaving
it, and be done.

Two cents from the peanut gallery,
				Ted

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 May 2006 14:00:06 -0400

--On Tuesday, 02 May, 2006 10:55 -0700 Ted Hardie
<[email-masked]> wrote:

>> "There may be edge cases, but I'd say that if a "typo fix"
>> leads to even minor technical differences, it isn't a "typo
>> fix" anymore, but must be treated as a "modification".
> 
> The problems really come in when the individual doesn't fully
> understand what is being specified and fixes it to something
> they do understand.  In one recent exchange with a technical
> editor, for example,  "uuencoded" got fixed to "unencoded".  I
> presume that the editor did not know what uuencoded meant, and
> did know what unencoded meant; the paragraph made sense with
> "unencoded" in that slot, but that wasn't what was intended.
> 
> 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

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.

> For typos like "there implementation", insert a "sic" if you
> can't stand leaving it, and be done.

Agreed, fwiw.
    john

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 02 May 2006 21:17:53 +0200

> 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.

For brief excerpts, such as a 2-3 sentence function API documentation,
I would disagree that the above is the appropriate solution.

/Simon

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 2 May 2006 20:34:26 +0200

----- Original Message -----
From: "Simon Josefsson" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 02, 2006 12:02 PM
Subject: Re: #1273 How do we usefully define "excerpt"?

> the meaning of the protocol, it is no longer a "good-faith" typo fix.

I repeat, your typo can be my change of meaning,

I saw posts recently along the lines of

A ...SSL....
B ... you mean SSH
A ... no I don't

A had made reference to public keys; B 'knew' that public keys were associated
with SSH while SSL went with certificates so obviously this was a typo; no it
wasn't, B's knowledge was not as great as it might have been.  There are plenty
of Bs around, which is why you should not correct typos.

Tom Petch

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 02 May 2006 22:22:40 +0200

> I saw posts recently along the lines of

Perhaps A meant TLS...

> of Bs around, which is why you should not correct typos.

I see your point, however I still wouldn't agree that changing 'SSL'
to 'SSH' within a document is a typo fix.  If such a change were made
in good faith, and they are willing to correct their mistake, I don't
see this as a major problem.  If the change was not made in good
faith, or if they aren't willing to correct it, then we're in another
boat...

Thanks,
Simon

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 May 2006 17:54:34 -0400

--On Tuesday, 02 May, 2006 21:17 +0200 Simon Josefsson
<[email-masked]> wrote:

>> Of course, such commentary is of the nature of a critical
>> review and does not raise any of the same copyright issues as
> 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

---

From: "todd glassey" <[email-masked]>
Date: Tue, 2 May 2006 15:58:11 -0700

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" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>
Cc: "Ted Hardie" <[email-masked]>; "Brian E Carpenter"
<[email-masked]>; "Tom Petch" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, May 02, 2006 2:54 PM
Subject: Re: #1273 How do we usefully define "excerpt"?