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

[John C Klensin <john-ietf at jck.com>]

--On Friday, 28 April, 2006 12:34 -0700 Ted Hardie
<hardie at qualcomm.com> 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
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg