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
<hardiequalcomm.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-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

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-ietfjck.com] 
> Sent: Friday, April 28, 2006 6:08 PM
> To: Ted Hardie
> Cc: Simon Josefsson; Brian E Carpenter; ipr-wgietf.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
> <hardiequalcomm.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-wgietf.org
> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
> 


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