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

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

(sorry, hit "send" a line too early)

--On Friday, 28 April, 2006 13:40 -0700 Ted Hardie
<hardie at qualcomm.com> wrote:

> At 4:15 PM -0400 4/28/06, John C Klensin wrote:
>> 
>> > 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).
> 
> 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."

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.

However... 

If we want to pursue that path as far as we can, the thing to do
is probably to get competent legal advice about how to write a
copyright license that permits any use consistent with the
development or deployment of good faith efforts at
standards-conforming implementations and bans anything else...
and whether such a license would be, in any useful sense,
enforceable and by whom.

     john


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