Subject: FW: IETF copying conditions

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 17 Sep 2008 10:43:20 -0700

Jorge, I would prefer to let you answer Ted's counter-rant.

Please explain to him that neither you nor I are expected to make code
contributions in order to contribute to IETF, or to have our contributions
be respected. 

Then, please explain to him how the law of trademark and unfair business
practice deals properly with issues of third parties pretending that they
are publishing official IETF specifications. Please teach him that
distinguishing between text and code doesn't aid this purpose one whit.

Then, please remind him that intelligent comments--rants or otherwise--are
permitted on the IETF IPR WG. Fortunately for him, so too is sarcasm when
expressed with some talent.

Regards,

/Larry

> -----Original Message-----
> From: Ted Hardie [mailto:[email-masked]]
> Sent: Wednesday, September 17, 2008 10:31 AM
> To: [email-masked]; 'Simon Josefsson'
> Cc: 'Contreras, Jorge'; [email-masked]
> Subject: RE: IETF copying conditions
> 
> Forgive the top posting, but it seemed a shame to break up such
> a marvelous rant with in-line comments.  "terrible perversion of industry
> standards" I thought one of your better recent phrases; it paints with
> such a broad,  sticky brush.
> 
> Anyway, one aim at the back of this is preventing someone taking
> the IETF's standards, changing them, and then claiming that the
> new text is the normative version.  The tools for achieving that aim
> are few, and they mainly revolve around saying "you can't have/change
> this text".  As you know, we could argue that the right choice was
> to leave it "no re-use outside of IETF".   That would, unfortunately, mean
> that folks couldn't change or re-use any code in the documents; we've been
> down that road, and agreed that code should be re-usable and modifiable.
> The split is the result.  You may not like it, but the other choice
> is worse, and engineering is all about trade-offs.
> 
> You argue below that no contributor will ever sue for copyright
> infringement because text is copied.  I know of several cases
> where other SDOs have approached authors for inclusion of
> text in their standards; in some cases the authors have said yes, and
> in others no. If  text is copied into a competing spec,  without
> permission,  I think you will find yourself on the wrong side of the bet,
> "Nonsense!" or no.
> 
> In any case, the working group has settled on the intent of all
> of this long ago and the rough consensus has already been judged.
> The only question on the table is whether the current language
> meets the aims set, something which the lovely rant below
> seems to ignore.
> 
> By the way,  I keep looking forward to you producing some
> standards text or code in one of our technical documents, Larry,
> so I can have the obverse of whatever pleasure it is you get
> from watching engineers struggle with the law.  Please do let
> me know if you ever do produce something in that line.
> 
> 			thanks,
> 				Ted Hardie
> 
> 
> 
> At 9:53 AM -0700 9/17/08, Lawrence Rosen wrote:
> >Simon Josefsson wrote in a private note to me:
> >> We have discussed IETF copying conditions before.  Right now, the IETF
> >> lawyer doesn't feel my comments aren't qualified unless I am a lawyer
> >> with BSD license expertise, and I was hoping you could help here.
> >
> >I've been resisting joining this particular discussion again because I
> think
> >the IPR WG has decided to do something with which I firmly disagree, but
> I
> >don't see any value to keep nagging about it. I agree completely with
> >Simon's objections given in his email below.
> >
> >This entire notion that standards are separate collections of "text" and
> >"code" is a terrible perversion of the essential purpose of "industry
> >standards". It is silly to say that words in an IETF specification that
> tell
> >someone how or why to implement a standard can't be copied because
> someone
> >claims it is just text. Nonsense!
> >
> >I don't believe these distinctions make any legal or technical sense, nor
> do
> >they serve any appropriate purpose for those making contributions to
> >standards. These distinctions were imposed because some representatives
> of
> >some companies have always been reluctant to let others implement
> standards
> >freely. These people cannot identify one single reason, other than
> >proprietary advantage, that would justify withholding the right of the
> >public to copy anything at all from an IETF specification.
> >
> >One more point: I refuse to believe that anyone at IETF, who holds the
> >copyright, will ever sue for copyright infringement because someone
> copied
> >text rather than code. And the first time one of those companies that
> >submitted "text" in a contribution to IETF tries to sue for copyright
> >infringement, the hue and cry will drive them back into their cave.
> >
> >So for all purposes, I intend to treat any IETF specification, in its
> >entirety, as a BSD-licensed document, and I would recommend that anyone
> who
> >needs to implement that specification do the same regardless of the
> wording
> >in IETF policies. Sometimes, even lawyers take risks rather than obey the
> >letter of the "law." For obvious reasons, this email is not legal advice,
> >but feel free to copy it for anyone who wants a non-binding justification
> to
> >do what the IETF IPR WG has tried to prevent.
> >
> >/Larry
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Simon Josefsson [mailto:[email-masked]]
> >> Sent: Wednesday, September 17, 2008 2:35 AM
> >> To: Lawrence Rosen
> >> Subject: IETF copying conditions
> >>
> >> Hi Larry.
> >>
> >> We have discussed IETF copying conditions before.  Right now, the IETF
> >> lawyer doesn't feel my comments aren't qualified unless I am a lawyer
> >> with BSD license expertise, and I was hoping you could help here.
> >>
> >> The IETF Trust is now close to finalizing the legal provisions, see
> >> proposal:
> >>
> >> http://trustee.ietf.org/policyandprocedures.html
> >>
> >> I have given up on trying to make the IETF use open source friendly
> >> licensing of entire documents, but my campaign has resulted in an
> >> intention to license code-parts of documents under a BSD license.
> >>
> >> Regarding section 4 of the latest document linked, I have identified a
> >> potential problem with the wording, which says:
> >>
> >>         c.  License. When Code Components are copied, published,
> >>    displayed or distributed as part of a document that is intended to
> be
> >>    read or referenced by persons, and not for direct processing by a
> >>    computer, they are licensed under the terms set forth in Section 3
> of
> >>    these Legal Provisions. When Code Components are copied, published,
> >>    displayed or distributed for direct processing by a computer, they
> >>    are hereby licensed to each person who wishes to receive such a
> >>    license on the terms of the "BSD License", as follows:
> >>
> >> My complaint is that this doesn't work since Code often contains
> >> portions intended to be read by persons: for example comments.  I
> >> believe the above text practically makes it difficult to extract code
> >> from RFCs because you need to make sure you don't copy anything
> intended
> >> to be read by humans.  This is in contrast with the IETF consensus
> which
> >> actually says that entire Code-portions should be freely licensed.
> >>
> >> I would appreciate if you have any thoughts to add on this, and whether
> >> you agree that the above text is problematic.
> >>
> >> I have proposed to simplify the paragraph into:
> >>
> >>         c.  License. Code Components are hereby licensed to each person
> >>         who wishes to receive such a license on the terms of the "BSD
> >>         License", as follows:
> >>
> >> Your thoughts on this proposal would also be appreciated.
> >>
> >> I have posted my final comments on the IPR WG list in:
> >>
> >> http://permalink.gmane.org/gmane.ietf.ipr/5532
> >>
> >> (Btw, the second concern I brought up have been addressed
> successfully.)
> >>
> >> If you have the time to review this and comment, I would appreciate it!
> >> Let me know if I can be of further assistance.  It might be a simple
> >> idea to post to the list if you want to make a public comment.
> >> Otherwise I can forward your feedback to the IETF lawyer.
> >>
> >> Best Regards, and thanks in advance,
> >> Simon
> >
> >_______________________________________________
> >Ipr-wg mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/ipr-wg

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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 17 Sep 2008 11:03:20 -0700

At 10:43 AM -0700 9/17/08, Lawrence Rosen wrote:
>are publishing official IETF specifications.

Just to forestall Jorge spending some of his valuable time on this,
I note that I'm not confused about this point--I was talking about cases
where SDOs wished to re-publish (modified) IETF text within their own specs.
This does not mean that they that they write it down and say
"here is the text from RFC NNNN"; it means that they want to take
the text, change it, and re-publish it.

Allowing someone to say no to that is something the working group has
said it wants to retain. 

			regards,
				Ted

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 17 Sep 2008 11:18:41 -0700

> Allowing someone to say no to that is something the working group has

I don't believe you can point to a vote anywhere in the IPR WG on that exact
point. Instead, you and others on the committee moved the discussion into
the misleading topic of code vs. text, and pretended that there was some
difference important to you. 

Suppose you were to specifically ask whether IETF wants to prevent other
SDOs from re-publishing (modified) IETF text within their own specs? Do you
expect that the community here really wants to limit the use of IETF specs
in that way? Why on earth would a volunteer, cooperative standards
organization like IETF want to do that to other volunteer, cooperative SDOs?

/Larry

> Sent: Wednesday, September 17, 2008 11:03 AM
> To: [email-masked]; 'Contreras, Jorge'
> Cc: [email-masked]
> Subject: Re: FW: IETF copying conditions
>

---

From: "Powers Chuck-RXCP20" <[email-masked]>
Date: Wed, 17 Sep 2008 14:35:15 -0400

Market fragmentation comes to mind, just for one thing. I agree with Ted
(and the consensus of the group). I doesn't make sense for the IETF, as
a functioning standards group, to openly allow other SDOs (or anyone
else) to freely take and modify portions of their text, to integrate
into their own standards, and promote them as alternate solutions. That
opens the door to multiple, non-interoperable implementations, which is
pretty much in conflict with what the IETF stands for. If another SDO
wants to make a normative reference to an IETF standard, great, that is
in both of our best interests. But to say to an outside organization
"here take what we have written, modify it any way you want, and
republish it, even if the result is something that cannot coexist with
products based on our standards" seems, at best, ill-advised.

The IETF is a volunteer, consensus organization, and many of those
volunteers don't want to see their work undermined by another
organization that freely takes their work product, revises it to the
point of non-interoperability, and then promotes that solution instead
of the work product of the IETF. Let those folks go do their own work.

Regards, 
Chuck 
------------- 
Chuck Powers, 
Motorola, Inc 
phone: 512-427-7261
mobile: 512-576-0008

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lawrence Rosen
> Sent: Wednesday, September 17, 2008 1:19 PM
> To: [email-masked]
> Subject: RE: FW: IETF copying conditions
> 
> Ted Hardie wrote:
> > Just to forestall Jorge spending some of his valuable time 
> on this, I 
> > note that I'm not confused about this point--I was talking 
> about cases 
> > where SDOs wished to re-publish (modified) IETF text within 
> their own 
> > specs.
> > This does not mean that they that they write it down and 
> say "here is 
> > the text from RFC NNNN"; it means that they want to take the text, 
> > change it, and re-publish it.
> > 
> I don't believe you can point to a vote anywhere in the IPR 
> WG on that exact point. Instead, you and others on the 
> committee moved the discussion into the misleading topic of 
> code vs. text, and pretended that there was some difference 
> important to you. 
> 
> Suppose you were to specifically ask whether IETF wants to 
> prevent other SDOs from re-publishing (modified) IETF text 
> within their own specs? Do you expect that the community here 
> really wants to limit the use of IETF specs in that way? Why 
> on earth would a volunteer, cooperative standards 
> > >Then, please explain to him how the law of trademark and unfair 
> > >business practice deals properly with issues of third parties 
> > >pretending that they are publishing official IETF specifications.
> > 
> > Just to forestall Jorge spending some of his valuable time 
> on this, I 
> > note that I'm not confused about this point--I was talking 
> about cases 
> > where SDOs wished to re-publish (modified) IETF text within 
> their own 
> > specs.
> > This does not mean that they that they write it down and 
> say "here is 
> > the text from RFC NNNN"; it means that they want to take the text, 
> > change it, and re-publish it.
> >

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 17 Sep 2008 12:05:49 -0700

Larry, Chuck Powers is right on this as well. My response to your retort to 
Ted Hardie is below.

Todd Glassey
----- Original Message ----- 
From: "Lawrence Rosen" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 17, 2008 11:18 AM
Subject: RE: FW: IETF copying conditions

> difference important to you.

That's because the IPR WG is a sham IMHO. The law around the transfer of IP
is not somehting that the IETF gets to rewrite to suit itself.

> SDOs from re-publishing (modified) IETF text within their own specs?
If their outgoing licensing is not compatible with the existing IETF then
they cannot do this and that either has to be agreed upon as something that
can be lived with or a proper flow-through licenesing developed for that SDO
Practice Model.

> Do you
> in that way?

Counsel the question here is not what this community wants but rather what
the law allows. The IETF's processes of being a trailing edge SDO are what
define how it must react to IP that is submitted to it for publication.

> Why on earth would a volunteer, cooperative standards

Because the IETF doesnt own or control the IP moving through it unless the
purpose of the IETF has been formally changed.

The issues are simple, the IETF is a trailing-edge standards process which
is now trying to morph into a leading edge process without adhering to the
legal requirements for managing genesis of that IP. That said the IETF needs
to respect the IP rights of the real owners of the IP submitted by third
parties.

That means that the previous IP owners rights are what they are and the IETF
needs to respect that.

>> Allowing someone to say no to that is something the working group has

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.6.21/1676 - Release Date: 9/17/2008
9:33 AM

---

From: Ted Hardie <[email-masked]>
Date: Wed, 17 Sep 2008 13:09:17 -0700

>organization like IETF want to do that to other volunteer, cooperative SDOs?

First,  I think we're past the point of asking for consensus on the output
documents, which are clear on this point.  You're welcome to ask the
chairs to reconsider, but with the documents past Last Call, I don't think
see it as likely.

Second, not all SDOs are supported by volunteers, and quite a few of them are
not cooperative.  I'm sure if you take the time to look out at the landscape
a bit, you'll see a fair few that are national or international bodies whose toes
dip into the same waters as the IETF.    They may have very different views
on what makes a good network, and the interactions between them and the
IETF has in the past been rocky.  Try to picture one of them as the re-users
of the text, and you may see where some of our reactions are coming through.
The threat here is not theoretical.

The last and really major point is Chuck's--this makes interoperability
harder.  When there are three different things that look largely
similar but don't interoperate because of different interior choices,
things break.  To get past that in some current domains we see
gateways that have two different flavors of the same protocol
on either side of the gateway.  That's bad and anything we can
do to minimize it is worth it.  It's better for the end users, the developers,
and the Internet when things interoperate.

			regards,
				Ted Hardie

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 17 Sep 2008 14:02:14 -0700

Ted, none of your reasons, or Chuck's, requires the dumb solution of
distinguishing text from code in IETF specifications. 

I agree, though, that we're somewhat past that point. The only hope is that
the chairs will reconsider or, perhaps better still, that the community will
ignore the "text vs. code" distinction altogether and do what I would do:
Treat all IETF specifications as if they were available for copy and wait
for some bogeyman company to try to sue for copyright infringement. :-)

Certainly most engineers in the open source community around the world won't
worry about you suing them. I doubt if many of them will actually read or
try to understand these rules anyway. The standards world is moving towards
greater openness and freedom, and IETF will get there somehow.

/Larry

> Sent: Wednesday, September 17, 2008 1:09 PM
> To: [email-masked]; [email-masked]

---

From: "Contreras, Jorge" <[email-masked]>
Date: Wed, 17 Sep 2008 17:10:25 -0400

> Treat all IETF specifications as if they were available for 
> copy 

They are all available for copy.  Just not for modification.
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Sep 2008 09:15:09 +1200

>> expect that the community here really wants to limit the use of IETF specs

Yes, undoubtedly that was the WG consensus. We don't want to see other SDOs
publishing incompatible versions of our protocols, period. And this is
not paranoia; it's evidence-based, although I don't want to point the finger
at specific SDOs, since such matters are usually handled by courteous
bilateral discussions. Using copyright protection is clearly a last
resort.

>> organization like IETF want to do that to other volunteer, cooperative SDOs?

Becaus our primary mission is to make the Internet work better, which
requires interoperable protocols, which precludes incompatible versions.

   Brian

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 17 Sep 2008 14:27:23 -0700

> They are all available for copy.  Just not for modification.

Sorry, I meant "copy and modification." That must be allowed when the
modification to the text is required to describe the modified code. Or are
you suggesting that someone who changes the code can't document his changes?

/Larry

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Contreras, Jorge
> Sent: Wednesday, September 17, 2008 2:10 PM

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 17 Sep 2008 14:44:45 -0700

----- Original Message ----- 
From: "Lawrence Rosen" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 17, 2008 2:02 PM
Subject: RE: FW: IETF copying conditions

> distinguishing text from code in IETF specifications.

Sure it does - those code sections may come from other controlled IP sources 
which are referenced here in IETF document's for research. That CANNOT by 
that set of terms provide a derivative right to IETF's relying parties.

The IETF's submission process allows people who dont actually own or 
represent the legal interests of the actual IP owners to the IETF for 
publication. They may own the rights to their words as a literary work but 
as a technology description, no...

In those instances like the TELNET docuements for instance, the actual power 
of attorney for the real IP owners was never transferred to the IETF in any 
culpable form and yet the IETF is licnesing its use for any and all 
purposes. .

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 17 Sep 2008 14:43:52 -0700

I'm moving this to [email-masked]. There are important policy implications
here that the entire community should understand before we let the IPR WG
decide for us on a policy so opposite to open source and open standards!

I am also copying this separately to the Open Web Foundation (OWF) list,
which I believe may have some interest in ensuring that it can copy and
modify IETF specifications for its own standards any time it damn well
pleases.

/Larry

> requires interoperable protocols, which precludes incompatible versions.

*********************

Please note: There is an earlier set of emails on this thread in the
archives of the IPR WG.

/Larry

*********************

> Of Brian E Carpenter
> Sent: Wednesday, September 17, 2008 2:15 PM
> To: [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Sep 2008 15:18:45 -0700

>decide for us on a policy so opposite to open source and open standards!

Larry, I'm confused. What about the statement that "We don't want to 
see other SDOs publishing *incompatible* versions of our protocols, 
period" is the opposite of the policy of open standards (emphasis 
added)?

Which SDOs that you participate in want to see other SDOs publishing 
*incompatible* versions of their protocols?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 17 Sep 2008 15:42:32 -0700

> *incompatible* versions of their protocols?

Hi Paul, 

Of course none of the SDOs that I work with want to see incompatible
versions. But this turns the issue on its head. Open source and open
standards deal with the freedom to do things, even though we might
discourage people to take us up on that offer of freedom.

So with respect to IETF specifications, the open source and open standards
objective is that the world is *free* to make compatible or incompatible
versions of our specifications. (This is the philosophy that neither IETF
nor Microsoft nor IBM, nor anyone else, is going to be the absolute God of
acceptable software.) I'm sure that good people everywhere will cooperate to
ensure that all good versions of our specifications are compatible, and
cooperative people will be encouraged to remain compatible by virtue of the
quality of our work.

But if anyone, anywhere, for any reason, wants to take an IETF specification
and modify it, open source requires that he be free to do so.

The current proposed IPR policy seems to allow that for "code" but not for
"text" in our specifications. What a burden that imposes to protect people
from freedom!

/Larry  

> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Wednesday, September 17, 2008 3:19 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: [email-masked]
Date: Thu, 18 Sep 2008 16:23:00 -0400

Larry,

> and modify it, open source requires that he be free to do so.

I think "requires" is a stretch.  There are a large number of non-IETF
standards implemented in open source for which copyright does not permit
arbitrary modifications, so I think "requires" is incorrect.  Copyright
provisions that do not grant derivative works rights and have
distribution
terms far less permissive than IETF's are common in other standards
bodies,
some of whom rely on charging money for copies of standards to fund
their
budgets. IETF has chosen not to charge for standards for many good
reasons.

Encouraging people who want to modify standards to talk to the people
who
developed the standards is a "good idea", and to the extent that
copyright
terms encourage people to do so, that's beneficial.  An example of the
benefits of this sort of discussion is RFC 4595 "Use of IKEv2 in the
Fibre
Channel Security Association Management Protocol" (I'm an author).  When
I started working on this, my initial belief was that an IETF RFC and
use
of IANA-allocated values was highly unlikely (e.g., IKEv2 for FC does
not
run over IP) and I was pleasantly surprised that the IETF Security Area
wanted to see the FC values and usage documented in an RFC.

OTOH, of the various arguments made for use of RFC text, the one I'm
most
sympathetic to is documentation - code comments, manuals, online help,
etc.,
where the ability to selectively quote from the RFC that is implemented
can be very useful.  This would need to be controlled, as blanket
permission for arbitrary selective quoting can be dangerous - it's
fairly easy to change a standard to be non-interoperable via selective
quoting.  For an (amusing) extreme example from another domain, see:

http://www.legis.state.wi.us/senate/sen10/news/FrankensteinVeto.pdf

While I doubt that anyone would ever resort to something that bizarre in
quoting from an RFC, I hope the underlying concern is clear.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: Ian Jackson <[email-masked]>
Date: Thu, 18 Sep 2008 19:00:35 +0100

> *incompatible* versions of their protocols?

The Debian project has published a small (by IETF standards) but
significant body of work specifying the interoperation and behaviour
of the various parts of what they regard as a modern Unix system,
particularly as regards the behaviour of package management systems
and the interoperation between separately-maintained packages.

The Debian standards documents (the core of which I originally wrote
but which have been greatly expanded and enhanced and are now
maintained by others) are released under a licences which permit
modified redistribution with a definite expectation that derivative
systems might want to do things differently.

That a different system might do things differently would not be good
for Debian so we don't encourage it.  We would prefer to keep Debian
and its derivatives as close as possible so that we can share
development work (particularly, so that we can all benefit from each
others' improvements).

However, the whole point of Free Software (and thus the point of
Debian) is that people are free to modify it.  If that means that they
are free to cause it to run to incompatible standards, so be it.  And
that freedom needs to be practically exerciseable collectively as well
as individually, so must include the freedom to properly communicate
within their own project what they are doing.  So we do not use the
law to prevent our derivatives from using modified versions of our
standards documents if they regard it as necessary.

Debian is a not insignificant organisation.  There are around 1000
members with voting rights.  Many of Debian's choices both at a
technical and political level have been influential in the relevant
fields.

Ian.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 19 Sep 2008 12:24:41 -0700

>development work (particularly, so that we can all benefit from each

Thanks for your considered reply to the issues.  In the section above,
you hit on one of the crucial issues:  what's the cost of a fork? 

It's actually highly variable.  In many instances, a fork doesn't
actually create interoperability problems at all, but instead carries
two different code bases forward in different directions, while
still allowing bits and pieces from the two code bases to be passed
back and forth at will.  The cost there is low.  In other instances, it
does create two new systems, each of which continues to evolve
separately but without the ability to freely move code from one to
another.  Both instances may limit the benefit each group may have from
the other's efforts, but it is clearly the latter case which is the
most troubling.  

In the IETF, the lack of interoperability is
not simply expressed in the re-use of code, but in the compatibility
of the wire formats and thus the ability to pass messages among
the actors who share the net.  In the IETF, interoperability is one the
key measurements of  success; without it, no protocol is a success
in our terms.  There are things which must also happen, but it
is the foundation of all the protocol work that happens here. 
The contortions we engage to maximize that often look
strange, but they fall out of a very basic principle:

The Internet must not fork.

To remain "the Internet" and not simply an internet, we
must do everything we can to prevent it.  There are a host
of local optimizations which could be made in specific environments,
and there are extraordinary temptations at times to make
them and gateway at the border of those regions.  It's almost
always a mistake.  Every time we have broken the core
interoperablity of the network in order to achieve some
local optimization, the system as a whole has been hurt.
Sometimes so severely that we are still recovering. 

No one objects to the code implementing a protocol from being
changed, modified, or, yes, forked.  Maintaining a frankly
ugly distinction between "code" and "text" is an
expression of our willingness to see those modifications.
But our willingness to see the protocols drift into
a non-interoperable mess should approach zero.  It hurts
the net too much, by isolating those whom the net should
connect.

Speaking only for myself,
			regards,
				Ted Hardie

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 25 Sep 2008 07:22:14 +0200

> difference important to you. 
Larry, that is your claim.
I don't dispute the claim that we haven't taken a vote, because the IETF 
does not vote.
But I will assert two things:

- The discussion of permitting change to text was extensive and repeated.
- The consensus of the working group was the compromise position now 
documented.

I assert that if you want to claim that either of these two statements 
are false, YOU back it up with evidence. As it stands, you are making 
statements that I personally, as the WG chair who's tried to shepherd 
this process for the last 3 years, find to be crossing the border 
between uninformed speculation and assertions that I would have to take 
personal affront at.

Some breadcrumbs from the archives - both the meeting minutes, the 
ticket server and the email archives are online, and you should be able 
to find them easily to verify:

The issue tracker shows #1169: "Modified excerpts", with the first text 
"Should modified versions of excerpts from non-code text be permitted?".

https://rt.psg.com/Ticket/Display.html?id=1169

The resolution, as of November 13, 2007 (I was lame in my tracker 
updates), says "Resolved as of Chicago (not)".

The July 2007 minutes of the physical meeting in Chicago show:

Consensus in room that the other issues have been resolved: #1166,
1167, 1168, 1169, 1175, 1199, 1237, 1246, 1337, 1400

http://www.ietf.org/proceedings/07jul/minutes/ipr.txt

My archive search shows that this occurs in multiple messages to the list:
June 27, 2006, "Ticket status, June 27, 2006":

#1169 Modified excerpts
   Consensus that modifications to make use of code in implementations 
are OK.
   No consensus on modifications to non-code.
   Not clear if consensus exists on reuse of code for other purposes 
than standards implementation

March 27, 2007, "DRAFT minutes from Prague IPR meeting":

III - matching issues to resolutions
  Harald reviewed issues from issues list and the resolutions
.......
    1169 Modified excerpts
        Resolution: Permitted for code, not permitted for non-code

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 25 Sep 2008 09:11:07 +0200

Harald Alvestrand <[email-masked]> writes:

> I don't dispute the claim that we haven't taken a vote, because the
> IETF does not vote.
> are false, YOU back it up with evidence.

Your two assertions are not in contrast with what Larry wrote, if you
read it carefully, so I think you are talking past each other.

The problem in the WG has been that the discussions of separating text
and code licenses were managed, by the chairs, as discussions of whether
to permit changes to text.  That is not the same discussion.  By
treating it as a 'permit-changes-to-text?' discussion, you make an a
priori assumption that there is a difference between text and code that
is relevant in this context.  If you move the discussions like that,
you'll end up with different licenses, which results in unwarranted
complexity.  I believe this is what Larry refers to, and I agree with
that.

> ticket server and the email archives are online, and you should be
> able to find them easily to verify:
>
> The issue tracker shows #1169: "Modified excerpts", with the first
> text "Should modified versions of excerpts from non-code text be
> permitted?".
>

This is a fine example of were arguments against separating licenses for
code and text were regarded as a discussion of whether to allow changes
to text, see my original e-mail which is quoted in the tracker.  That
summary was missing the point.

> Consensus in room that the other issues have been resolved: #1166,

As far as I understood Larry, these issues are not related to what he
referred to.

/Simon

---

From: "Lawrence Rosen" <[email-masked]>
Date: Thu, 25 Sep 2008 10:13:55 -0700

Harald Alvestrand wrote;
> between uninformed speculation and assertions that I would have to take

Harald,

I certainly meant no insult to your efforts to shepherd an IPR group with a
*flawed charter* [1] to a conclusion with which I disagree. You and I
discussed this many times in-channel and back-channel, and you remember my
frustrations and my sympathy for your position then and now. 

Indeed, we just wasted another thread arguing about the nonsensical
distinction between code and text and again heard some people assert it is
somehow relevant to the goal of pushing the IETF brand and seeking
consistency on standards. 

The proposed IETF IPR policy allows the public to modify the code present in
IETF specifications but not to use that same specification to create
modified text to document that modified code! Does anyone here honestly
believe this is justified?

You admit: The working group took no vote. Nobody ever does in IETF. It is
thus possible for a small group of people who have the stomach to attend to
boring IPR discussions to come to an irrational conclusion. 

Since there was never a vote, I retain the right to repeat my concerns.
You'll notice I've not tried to dominate this thread, but I was invited to
comment once again--and I did.

-1.

/Larry

[1] Failure to address patents; failure to identify the goals for IETF of a
revised copyright policy; failure to weigh benefits and costs to the public
of various alternatives.

P.S. I moved this back to [email-masked]. Even though some people there find
these battles over legal issues boring and distracting, this policy is the
guts of why we're here. It should be the entire organization that debates
the charter and results of a policy working group, not the working group
itself.

> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Wednesday, September 24, 2008 10:22 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: "Powers Chuck-RXCP20" <[email-masked]>
Date: Thu, 25 Sep 2008 13:21:57 -0400

My answer to Larry's question - Yes.

Regards, 
Chuck 
------------- 
Chuck Powers, 
Motorola, Inc 
phone: 512-427-7261
mobile: 512-576-0008

> Sent: Thursday, September 25, 2008 12:14 PM
> To: 'Harald Alvestrand'; [email-masked]
> Cc: [email-masked]
> > between uninformed speculation and assertions that I would have to 
> > take personal affront at.
> 
> 
> Harald,
> 
> I certainly meant no insult to your efforts to shepherd an 
> IPR group with a *flawed charter* [1] to a conclusion with 
> which I disagree. You and I discussed this many times 
> in-channel and back-channel, and you remember my frustrations 
> and my sympathy for your position then and now. 
> 
> Indeed, we just wasted another thread arguing about the 
> nonsensical distinction between code and text and again heard 
> some people assert it is somehow relevant to the goal of 
> pushing the IETF brand and seeking consistency on standards. 
> 
> The proposed IETF IPR policy allows the public to modify the 
> code present in IETF specifications but not to use that same 
> specification to create modified text to document that 
> modified code! Does anyone here honestly believe this is justified?
> 
> You admit: The working group took no vote. Nobody ever does 
> in IETF. It is thus possible for a small group of people who 
> have the stomach to attend to boring IPR discussions to come 
> to an irrational conclusion. 
> 
> You'll notice I've not tried to dominate this thread, but I 
> was invited to comment once again--and I did.
> 
> -1.
> 
> /Larry
> 
> [1] Failure to address patents; failure to identify the goals 
> for IETF of a revised copyright policy; failure to weigh 
> benefits and costs to the public of various alternatives.
> 
> P.S. I moved this back to [email-masked]. Even though some 
> people there find these battles over legal issues boring and 
> distracting, this policy is the guts of why we're here. It 
> should be the entire organization that debates the charter 
> and results of a policy working group, not the working group itself.
> 
> 
> 
> 
> > >> I note that I'm not confused about this point--I was 
> talking about
> > cases
> > >> where SDOs wished to re-publish (modified) IETF text 
> within their 
> > >> own specs.
> say "here 
> > >> is the text from RFC NNNN"; it means that they want to take the 
> > >> text, change it, and re-publish it.
> > >>
> > >> Allowing someone to say no to that is something the 
> working group 
> > >> has said it wants to retain.
> > >>
> > >
> > > I don't believe you can point to a vote anywhere in the IPR WG on 
> > > that
> > exact
> > > point. Instead, you and others on the committee moved the 
> discussion
> > into
> > > the misleading topic of code vs. text, and pretended that 
> there was 
> > > some difference important to you.
> > between uninformed speculation and assertions that I would have to 
> > take personal affront at.
> > 
> > text "Should modified versions of excerpts from non-code 
> text be permitted?".
> > 
> >   Harald reviewed issues from issues list and the 
> resolutions .......
> >     1169 Modified excerpts

---

From: Ted Hardie <[email-masked]>
Date: Thu, 25 Sep 2008 10:40:24 -0700

At 10:13 AM -0700 9/25/08, Lawrence Rosen wrote:
><snip>

>believe this is justified?

I'll be the existence proof on this one:  I believe it is justified.  The
reasons for it have been discussed at length and a conclusion based
on rough consensus has been reached. 

>boring IPR discussions to come to an irrational conclusion.

That conclusion seems at this point to have been supported by the
rough consensus judged of the IETF Last Call and the deliberations of the
IESG. I agree that many folks run pounding from the room when these
discussions occur, but the rough consensus of those who care
seems to be how we do things in general around here.  I also
agree that the discussions are often boring, often frustrating,
and I believe everyone involved will be happier when the WG closes
down.

Rough consensus is not voting, and the ways it works are often
troublesome on matters of principle, because they don't admit
of the same kinds of compromise that engineering trade-offs
do.  But voting in an organization with no defined membership
would be far worse here, as the ballot-stuffing campaigns would
be damaging on even more levels.

			regards,
				Ted

---

From: "TS Glassey" <[email-masked]>
Date: Thu, 25 Sep 2008 10:30:20 -0700

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "Harald Alvestrand" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, September 25, 2008 12:11 AM
Subject: Re: FW: IETF copying conditions

> to permit changes to text.  That is not the same discussion.

Its funny to see you agreeing with Dean and I that the Management of the 
IPR-WG has been responsible for preventing the real issues from being 
discussed here. I agree, the Management has prevented me and others from 
trying to force them to specify what they actually intend to accomplish - 
they will talk about it at 400,000 meters but when you assk for detailed 
responses they just blow people off. Its why I believe it is VERY 
inappropriate to have a bunch of engineer's drafting a contract as a legally 
enforceable document.

The fact that neither of the Attorney's on this list will formally answer 
those specific questions (i.e. render an opinion that they can be held 
liable for) as Attorney's either creates yet another conflict of interest in 
that some of the parties represented here are with Counsel and others are 
not... See my point?

- as to what the IETF's intent is in its licensing process, and as to 
whether it would allow controlled IP's into the IETF process,  and to the 
issues of Patent Requirement's on derivatives and instances where an IETF 
technology referes to other externally introduced IP.

> By
> is relevant in this context.

It would depend on what that text said. If it was a verbal description of a 
psuedocode module then it would pertain to the CODE model licensing 
constrauints. If it was a couple of paragraphs about "The Three Bears and 
Goldilocks" then then it doesnt make sense to allow others to rewrite the 
artistic words of others.

> If you move the discussions like that,
> complexity.

No - not when the discussion is a negotiated agreement about what some 
protocol is supposed to do or how it performs in any given situation.

> I believe this is what Larry refers to, and I agree with
> that.

The biggest problem we have today is the refusal for this WG Chair and its 
key controlling member's  to draft a very specific set of terms and 
conditions that the document's are supposed to meet. That is to say a 
specific summary of the goals we are trying to accomplish...

What the IETF needs is accountability and a set of publicly disclosed and 
easy to understand participation rules, not some set of numerous and 
everchanging documents "so convoluted that a licensed attorney would have 
trouble drafting a workflow through the process" to understand what it 
actually does.

My point here is to simplfy and create a set of standards platforms that can 
be used by private individuals, academic, and commercial players equally and 
with the same results available for all. I also want to transfer the control 
of whether a protocol has reached maturity from the IESG to a pre-defined 
set of milestones so that the achievment of the status as an IETF Standard 
is more mechanical in nature and less subject to Human foibles or whims.

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.7.2/1689 - Release Date: 9/24/2008 
6:51 PM

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 25 Sep 2008 12:02:11 -0600

> on rough consensus has been reached. 

Ted explained to me off-list why he believes this policy is justified,
and I now understand why he believes that. I still think that the attack
(other SDOs palming off modified IETF specifications as canonical) is
not as threatening as others think it is (and in general I would prefer
to use less heavy-handed methods), but they have more experience than I
do with this particular attack, so for what it's worth I have decided to
defer to them on this matter.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/