Subject: Harm caused by Simon's proposal

From: Sam Hartman <[email-masked]>
Date: Tue, 08 Nov 2005 21:04:37 -0500

Hi.  Many folks believe that Simon's proposal goes too far.

I believe that any harm caused by Simon's proposal is already inherent
in the current system.

So, I'd like to propose a challenge.  Describe how a bad actor could
use Simon's proposed license to harm the IETF.  I'll explain how the
same bad actor could harm the Internet in the same way today without
Simon's proposal.

I think doing so will help us understand his proposal and whether
there is really anything we gain with the current more restrictive
licenses.

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 08 Nov 2005 21:19:03 -0500

It seems to me that there are (at least) two different kinds of concerns.

A bad actor case is someone who deliberately modifies an RFC to 
misrepresent its intend.  Our current remedies for this are admittedly 
weak.  We have legal recourse, but that isn't very helpful.

I am actually more concerned by the accidental actor.  Currently, we tell 
people not to modify the RFC.  So someone who means well will not do so.
Under the proposed rules, we would tell people to feel free to modify the 
RFC as they need / want to.
That seems to me to encourage people to make incompatible or misleading 
changes.

Yours,
Joel M. Halpern

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 Nov 2005 21:28:51 -0500

>>>>> "Joel" == Joel M Halpern <[email-masked]> writes:

    Joel> I am actually more concerned by the accidental actor.
    Joel> Currently, we tell people not to modify the RFC.  So someone
    Joel> who means well will not do so.  Under the proposed rules, we
    Joel> would tell people to feel free to modify the RFC as they
    Joel> need / want to.  That seems to me to encourage people to
    Joel> make incompatible or misleading changes.

Simon requires they label their changes as modified/do not represent
them as our document.  Within the open source community we have strong
evidence that people tend to respect such changes and tend to actually
label modified work as modified.

Also, keep in mind that interoperability is guaranteed not by all
using the same standards document but by all writing code that works
together.  Nothing in our process prevents me from making accidental
or intended changes that damage interoperability of protocols.  The
only limits are on my attempts to document these changes should I
choose to do so.

I agree it would be unfortunate if someone took our RFC and changed
the document without clearly labeling the change.  I just don't see
that as very likely based on what I've seen in other arenas.  I also
think that Simon's proposal gives us adequate protection in that they
must label their work.

--Sam

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 Nov 2005 18:29:56 -0800

>there is really anything we gain with the current more restrictive

A bad actor can harm the Internet in many ways, and ignoring the
licenses and going on about that harm is clearly one option
open to the real bad hats.  That's not the point of the exercise.

The point is to provide the rights needed to ensure that people
can use specifications to implement the standards they specify,
to promote those specifications, and elucidate them. 

But it is  also about preserving community-agreed standards.  Groups of
people  came together to develop and agree to them, and the change
control of those specifications were given to the IETF as part of that effort.
Abandoning change control at the point of publication would be
a truly strange result for an organization aimed at promoting
interoperability, especially one in which iterative publication
of specifications is so central.   I think the "with modification"
phrase in Simon's proposal could be read as the IETF abandoning
change control on its standards.  That goes to far for me.

As a result, I disagree with his language.

			regards,
				Ted Hardie

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 Nov 2005 21:34:03 -0500

>>>>> "Joel" == Joel M Halpern <[email-masked]> writes:

    Joel> It seems to me that there are (at least) two different kinds
    Joel> of concerns.  A bad actor case is someone who deliberately
    Joel> modifies an RFC to misrepresent its intend.  Our current
    Joel> remedies for this are admittedly weak.  We have legal
    Joel> recourse, but that isn't very helpful.

Note that one class of bad actor people in this wg seem to worry about
is someone who wants to change (and document) a protocol but who
doesn't want to bring their changes through our process.  For example
they might want to change SIP, MPLS or some other technology to meet
their needs in a way that destroys interoperability.

I consider that to be a bad actor in this context.

I think that today, such people are able to change and deploy changed
protocols.  What they cannot do is describe their changes easily.
They can either do a clean-room redocumentation of the protocol--using
their words to describe something based on our protocol or they can
describe only the changes.

Either of these methods is likely to create a protocol with more
confusing documentation than if people could use clearly labeled
derivative works.

Another thing to consider.  If such a bad actor does do a
documentation of the protocol in their own words, they can still make
claims like "based on RFC 4107" or uses IETF technology at the core.
So even some of the marketing distinctions we'd like to make are hard
to make against a determined bad actor in the current model.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 Nov 2005 21:37:43 -0500

>>>>> "Ted" == Ted Hardie <[email-masked]> writes:

    Ted> A bad actor can harm the Internet in many ways, and ignoring
    Ted> the licenses and going on about that harm is clearly one
    Ted> option open to the real bad hats.  That's not the point of
    Ted> the exercise.

I agree; that was not my point at all.  I'm only interested in
thinking about bad actors who follow our rules but do things we
dislike anyway.

I've discussed how one could go about changing a protocol we deploy
while respecting our licenses in another post.

--Sam

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Nov 2005 20:12:57 +0100

(AD hat off)

Ted Hardie wrote:

>  ...  I think the "with modification"

s/could be/would be/

It is in my view an open invitation to any other SDO that doesn't
like something we've done to produce an incompatible variant.

I can think of several SDOs and specific technologies where this
could be a real risk, but it's probably better not to name them.

I understand and sympathise with the cases that Simon describes, so
I think we need to understand the "field of use" idea better.

I also think we need a better understanding of a remark that Jorge
made about our ability to produce the desired results by license
terms rather than by boilerplate in the RFC text. If I'm not mistaken,
once the IETF Trust acquires the expected rights from ISOC, the
Trust could issue licenses that *expand* the rights granted by
the historical boilerplates, at least back to RFC 2220.

    Brian

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Nov 2005 14:23:46 -0500

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:

    Brian> (AD hat off)
    Brian> Ted Hardie wrote:

    >> ...  I think the "with modification" phrase in Simon's proposal
    >> could be read as the IETF abandoning change control on its
    >> standards.  That goes to far for me.

    Brian> s/could be/would be/

Then let's think of wording that clearly indicates that people should
not modify things even though they are permitted.

    Brian> It is in my view an open invitation to any other SDO that
    Brian> doesn't like something we've done to produce an
    Brian> incompatible variant.

I think they already have that invitation.  Do you really believe that
writing one of our documents in their own words is actually beyond the capability of one of these SDOs?

If you agree with me that the other SDOs could rewrite our document in
their own words then copyright is not a legal barrier to them doing
so.  Our license may be a practical barrier; that's worth discussing.
However I suspect that our license is more of a barrier because it
expresses our intent and because it is consistent with other messages
we send.

I have high confidence that we could write a license grant that
legally meant the same thing as Simon's grant but that clearly sent a
strong message to other SDOs.

--Sam

---

From: "Stephan Wenger" <[email-masked]>
Date: Wed, 9 Nov 2005 11:39:38 -0800

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian E Carpenter

> like something we've done to produce an incompatible variant.

Other SDOs do that all the time anyway.  Currently, they normally produce
diff documents (called, for example, "Guidelines", or "Technical
Specifications"), which are not necessarily as readable as a full spec would
be, but break interoperability with the RFC they refer to, nevertheless.
It's natural: a very targeted solution can take shortcuts (e.g. to ease
implementation effort, remove unnecessary overhead, remove restrictions that
do not apply for the application in question), which an IETF RFC can not.  

I'm personally unclear what's better: allow derivative IETF work, to make
other SDOs specs more readable, and move the industry forward as a whole
(this, of course, could be debated as well), or try to enforce
interoperability by the (IMHO) perhaps inappropriate means of copyright.

My two cents,
Stephan

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Nov 2005 21:05:41 +0100

Sam,

> strong message to other SDOs.

I believe I agree with that. That's why I found Jorge's comment
interesting.

   Brian

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Nov 2005 05:14:13 +0100

Ted Hardie <[email-masked]> writes:

> But it is also about preserving community-agreed standards.  Groups
> of people came together to develop and agree to them, and the change
> control of those specifications were given to the IETF as part of
> that effort.  Abandoning change control at the point of publication
> would be a truly strange result for an organization aimed at
> promoting interoperability, especially one in which iterative
> publication of specifications is so central.  I think the "with
> modification" phrase in Simon's proposal could be read as the IETF
> abandoning change control on its standards.  That goes to far for
> me.

I'm not sure if this will change your opinion, but as a thought
experiment, compare the IETF with Debian or FreeBSD.

The Debian/FreeBSD projects generate a fair amount of technical
documentation.  These are often developed in an open community.  The
iterative development model is central to the free software community
as well.  Those communities permit "with modification"; in fact that
license text is the vehicle that drive those communities forward.

Consequently, I disagree that it is strange for an organization with
these goals and principles to reject a "with modification" license.
There are organizations with similar principles, and similar
participation from big commercial vendors, that have realized the
"with modification" philosophy works.

Some communities have accepted the "with modification" philosophy, and
while there certainly are unofficial forks, and controversies
surrounding them, my impression is that they are not causing any harm
in the long run.  Compare OpenBSD.  That was enabled by a license that
permitted someone to take existing work and improve it.  Today,
OpenBSD contribute to a better working Internet, and is not harmful.

Thanks,
Simon