Subject: Re: A simpler idea (was: Re: Fair use and case analysis)

From: John C Klensin <[email-masked]>
Date: Fri, 28 Apr 2006 16:15:24 -0400

--On Friday, 28 April, 2006 12:34 -0700 Ted Hardie
<[email-masked]> wrote:

> At 10:54 AM +0200 4/28/06, Simon Josefsson wrote:
>> 
>> Con:
>> 
>> * Some people are afraid of fake RFCs.  I don't think this is
>> a good enough argument, the costs of copyright transfers or
>>  regular updates of the IETF license are, I believe, larger
>>  than the risk of fake RFCs.
> 
> This is only part of the risk.  If we release specs into the
> wild with this license, there is not just risk that someone
> fakes RFC XXXX, there is a much larger risk that someone takes
> the text and uses it as the basis for a specification that
> does not interoperate with the IETF spec.  It moves us to a
> model, in other words, where forking is a generally permitted
> result.  Getting to consensus is hard work, and forking is
> relatively easy (especially if you start from a finished
> work).  I believe that this will result in a situation in
> which forking is a common result.

I agree with this and with most, of not all, of your logic.

However, let's assume that someone, for whatever reasonable or
stupid reason, wants to create a fork.   I think there are a few
relevant issues at that point; it is those issues that cause me
to believe we are on the wrong path in this WG:

(i) We can inconvenience them, I believe very only slightly, by
prohibiting their taking our text and hacking it up to describe
their modified protocol.  Personally, I think causing that
inconvenience is a good thing because, morally, I object to my
work on a standard that was intended to promote interoperability
being used to facilitate forking.  But I don't have any
delusions about the inconvenience being effective at stopping
something someone wants to do and nothing we do to protect the
text of a standard prevents any implementation of anything at
all.

(ii) We cannot prevent them from creating forks by any mechanism
involving copyright.  Copyright covers the form of expression.
At the cost of writing new text that describes the new plan the
fork-er is protected from any copyright-related license on the
text we might come up with.   The fork-er is equally protected
by supplying no documentation at all, or by incorporating our
text by reference (e.g., "this is just like RFC 9999 except that
paragraph 8.2 should now read '....'").  Copyrights on RFC text,
even if unambiguously valid, just don't offer us any protections
against those options. 

(iii) Someone creating a fork and then claiming that it is the
IETF spec, or conforming to it, is involved in a matter of
fraud, not copyrights.  If "we" (or any other injured party) are
willing to invest the resources, there are ways to deal with
fraud that are probably more effective and more clear than any
dancing around with copyrights and ownership of text.

(iv) If we are trying to make forking as inconvenient as
possible, we need to be very careful that we give permission to
copy tables and code (whatever those are) only for use in
conforming implementations of standards.  Whether that would be
enforceable in a predictable way is, I suspect, an open
question, but it would almost certainly give an attorney
advising a would-be fork-er some anxieties.

>... 
> If you want a simpler idea, it is this:  The IETF should not
> be working on *anything* for which Internet-scale
> interoperability is not a key goal. For those for which that
> is a goal, real standards (and avoidance of forking) is key.
> Anything which can survive the kind of forking I predicted
> above probably shouldn't be done here anyway.  Put the spec on
> a web page, or code on sourceforge, or take it to any number
> of other fora; the IETF does not have or need any monopoly on
> good code or specs.    But it does need a clear focus on
> interoperability.  I wish I was certain it still had it.

I'd need to spend a while thinking about edge cases --in
particular, the robustness principle has protected us against a
lot of small forks in the past but that doesn't make the
relevant standards less worthwhile--  but I think that, in
general, I agree with this.  But, for the cases in which
Internet-scale interoperability is key, we don't need to look
for legal means to prevent forking: those who fork won't
interoperate, and the marketplace will take care of them (or, if
we have gotten the specifications wrong, of us).

     john

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

---

From: Ted Hardie <[email-masked]>
Date: Fri, 28 Apr 2006 13:40:47 -0700

>we have gotten the specifications wrong, of us).

Unfortunately, the timescale at which the market decides
this sort of thing can create a lot of harm.  This is particularly
the case where the damage done by the interworking middleboxes
hides the brokenness to the end user.  Or, rather more
exactly, hides the cause of the brokenness to the end users
while still exposing to the consequences of the fragility.
Doing what we can to avoid that is a valuable use of our time.
That means our answer to "Can I modify your spec?" should be
"Sure, come here and help us all make sure it operates in
your environment well", not "Sure, and if it does not interoperate
with folks who followed the original, well, that'll sort itself out
in the long run."

2 cents from the peanut gallery,
				Ted

---

From: "todd glassey" <[email-masked]>
Date: Fri, 28 Apr 2006 14:12:42 -0700

----- Original Message ----- 
From: "Ted Hardie" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: "Simon Josefsson" <[email-masked]>; "Brian E Carpenter"
<[email-masked]>; <[email-masked]>; "Spencer Dawkins"
<[email-masked]>
Sent: Friday, April 28, 2006 1:40 PM
Subject: Re: A simpler idea (was: Re: Fair use and case analysis)

SNIP ---

> with folks who followed the original, well, that'll sort itself out

Which is easily done in the license to use the IP.

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Apr 2006 17:17:28 -0400

--On Friday, 28 April, 2006 13:40 -0700 Ted Hardie
<[email-masked]> wrote:

>>> above probably shouldn't be done here anyway.  Put the spec
>>> on a web page, or code on sourceforge, or take it to any
>>> number of other fora; the IETF does not have or need any
>>> monopoly on good code or specs.    But it does need a clear
>>> focus on interoperability.  I wish I was certain it still
>>> had it.
>> 
>> particular, the robustness principle has protected us against
>> a lot of small forks in the past but that doesn't make the
>> interoperate, and the marketplace will take care of them (or,
>> if we have gotten the specifications wrong, of us).
> 
> this sort of thing can create a lot of harm.  This is
> particularly the case where the damage done by the
> interworking middleboxes hides the brokenness to the end user.
> Or, rather more exactly, hides the cause of the brokenness to
> the end users while still exposing to the consequences of the
> fragility. Doing what we can to avoid that is a valuable use
> of our time. That means our answer to "Can I modify your
> spec?" should be "Sure, come here and help us all make sure it
> operates in your environment well", not "Sure, and if it does
> not interoperate with folks who followed the original, well,
> that'll sort itself out in the long run."

Again, we are in complete agreement.  I just don't see
fine-tuning copyright provisions as being an especially
effective mechanism for delivering the second message to those
who don't want to play/ interoperate.

     john