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

["David B Harrington" <dbharrington at comcast.net>]

Hi,

While I believe it is important to try to constrain the use of RFCs
for activities that are supportive of interoperability and standard,
we need to make sure we don't make it illegal to create running code
that is a variation of an existing standard; that's how standards get
improved.

The IETF depends on running code, but the IETF does not develop
running code, so we need to be sure other people can develop running
code that can later be brought to the IETF as a contributions to the
standards process. And it is an economic reality that most running
code gets developed as a proprietary product feature that vendors can
sell to recoup their research and development costs. I don't want to
see us write text here that discourages vendors from doing this.

I think the existing approach seems to work fine, and has worked fine
for years, and wonder why is this WG trying to change this? Is there a
known problem we are trying to solve?

I am aware that some free software licenses don't like our license; I
think thos licenses should be changed to permit official industry
standards, but that's just my perspective.

dbh

> -----Original Message-----
> From: John C Klensin [mailto:john-ietf at jck.com] 
> Sent: Friday, April 28, 2006 6:08 PM
> To: Ted Hardie
> Cc: Simon Josefsson; Brian E Carpenter; ipr-wg at ietf.org; 
> Spencer Dawkins
> Subject: Re: A simpler idea (was: Re: Fair use and case analysis)
> 
> 
> (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
> 


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