Subject: #1175 Code vs text - second attempt at resolution

From: Harald Alvestrand <[email-masked]>
Date: Sun, 04 Jun 2006 00:43:37 +0200

In our list of open issues, we have this issue:

> If there are different rights granted to participants for working with 
> code than with non-code, it
> has to be possible for users to tell which is which. Suggestions include:
> - Defining it by type (C code, ABNF, MIBs...)
> - Defining it by marker (<code>/</code>)
> - Defining it by separate submission (file alongside draft)
> If there are no such differences, the point is moot.

The discussion from my previous attempt at a resolution had 4 
participants, which is a bit too few for comfort. Mainly, it seems to 
have indicated that the resolution should say less - and clearly 
illustrates that defining "pseudocode" is even harder than defining "code".

Second attempt:
--------------------------------------------------------------------
If a distinction needs to be drawn between code and non-code in IETF
documents, the community desires that:

- Specifications in formal languages, including C code, ABNF, MIBs,
ASN.1 and so on, are clearly "code".
- Tables such as the character lists in IDNA are to be regarded as
"code" too.
- Prose, including "pseudocode" that does not claim any level of
formality, is not "code" for the purposes of this resolution. This 
resolution does not say anything about the IETF's desires regarding 
"pseudocode", one way or another.
- The IETF Trust should maintain specific guidance on what will be
regarded as "code", including guidance on how to mark "code" in
documents where doubt could exist; this guidance is expected to change
more often than the IETF IPR rules (as enshrined in BCPs), if needed.
-------------------------------------------------------------------
I think this communicates a desire of the community that it will be
clear how to apply for the 95% case, which should be good enough to put 
text into our draft.

Comments?

                         Harald

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

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

---

From: "todd glassey" <[email-masked]>
Date: Sun, 4 Jun 2006 07:22:30 -0700

Harald - this code thing and identifying it are pretty simple - 'CODE is
anything that represents an Algorithm or Formulae or any identifiable
sub-component thereof" - which makes the constraints of what is and isn't
code really easy to define.

CODE includes, but is not limited to:
------------------------------------
Any Algorithm (or Formulae) or components thereof,  represented in ANY form,
including written descriptions of the work-flow or process steps.
Particularly:
            a)    anything written in any of the formally standardized
"PROGRAMMING LANGUAGES" including any and all High-Level Programming
Languages - C, Fortran, Pascal, Lisp, Java, Cobol/Snobol/Fastbol/RPG/RPGII,
or Native Assembler's and the like;

This of course also includes any data objectes from the above whether in
Machine Code/Binary,  Source,  or Intermediary-PCode;  Other programming
languages covered in this description include BASIC and the other
interpreted languages like FORTH for instance

            b)    Configuration Files content for any and all components
which would qualify under a) as a program or program-fragment (here is where
your MIB's and other Configuration Tables get covered...)

            c)    Any recognized Pseudo-coding model or standard including
the any and all frameworks defined as a part of another process. ABNF and
the other flowcharting process including but not limited to:

    ci)    State Diagrams, Mind Mapping Diagrams, Cause and Effect Diagrams,
SDL, TQM Diagrams
    cii)    And simple Workflow Diagrams - whether described in words or
drawn in any form.

            d)    Any matehematical formulae represented in formal notation
of any variety would also fit under this descrioption

Likewise, the same is true for Cross-Functional diagramming, and any other
form of representing an algorithm or formula/formulae in any form. The key
issue is "the representation of an algorithm in any form, or a defined
component of said algorithms.

The question is whether CODE by its very nature requires separate releases
from the others submitted, and I of course think it does.

Todd Glassey

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 04 Jun 2006 11:09:59 -0400

I disagree.  I think Harald's formulation works for what we need.  I 
think your proposed formulation would essentially remove all 
ptentially useful distinction between code and text.

Yours,
Joel M. Halpern

---

From: "todd glassey" <[email-masked]>
Date: Sun, 4 Jun 2006 08:52:49 -0700

Joel - What would a court say? Hmmmm - Lets see what the EU says?
http://dataright.haifa.ac.il/db-definition.htm

"Firstly, the materials incorporated into the database have to be
'independent'. This presumably means that each of the items included in the
database should be known and recognised. Secondly, the materials have to be
arranged in a systematic or methodical way. Thirdly, the materials are
individually accessible by electronic and other means. This last attribute
is closely related to the 'independent' attribute."

OK - #1 - each entry into the DB is published as a stand-alone work and then
included into the data base itself. #2 is addressed by the content ownership
rights to the IP submitted, and thirdly that the list is sortable - thanks
to Google and others this also is met... So the IETF's collection of
documents as would any stand-alone subset in a WG Archive under Note-Well
would meet the definitions of the EU's directive.

So then the collection of RFC's and I-D's are DB's under the EU's
definition... and also controlled separately from the content rights
therein. Anyone take this into account? How about when a WG Mailing List is
also reduced to being defined as a DB...

Todd Glassey

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 5 Jun 2006 08:45:18 -0400

Hi,

I suggest that a contributor that wishes to ensure that their
"pseudocode" can be copied with the same constraints as code would be
could explicitly mark the section with <code></code> markers.
Pseudocode that is not explicitly surrounded by <code> markers could
be declared (by IPR-WG document) to be non-code for purposes of
copyright.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> -----Original Message-----
> From: Harald Alvestrand [mailto:[email-masked]] 
> Sent: Saturday, June 03, 2006 6:44 PM
> To: [email-masked]

---

From: "todd glassey" <[email-masked]>
Date: Mon, 5 Jun 2006 06:11:06 -0700

Why? For what purpose? To make the IETF's definitions more out of alignment
with the rest of the IPR world??? - As to Code - all that matters is the
patent protection capabilities - and to not destroy people's patent
capabilities by participating with the IETF - unless that is the goal here.

That said - then the real diagramming - whether specific to CODE or DRAWINGS
should conform to US and Euro Patent Documentation/Diagramming Standards,
the IETF's publishing rights are orthogonal & of little impact to all other
concerns.

The reasoning is that if someone cannot protect the uniqueness of their
invention without destroying those rights within the IETF, then there is no
reason to deal with the IETF and in fact the IETF becomes a threat to many
corporate entities IMHO.

Todd Glassey

---

From: "Lawrence Rosen" <[email-masked]>
Date: Mon, 5 Jun 2006 16:13:55 -0700

You start your question by saying "If a distinction needs to be drawn
between code and non-code in IETF documents...." 

I believe this entire exercise of separating code from text is a silly waste
of time. Other then the "I don't want to and so I won't" excuse some have
given for refusing to treat all contributions as "code," can anyone think of
a reason why the burden of distinguishing between the two is worth the cost?

Let's please just say that any contributions made to an IETF standard can be
copied or modified by anyone who reads it. Why not? What possible rights in
a copyrighted contribution does any contributor *need* to reserve? For what
earthly purpose?

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)
Stanford University, Lecturer in Law
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242  *  fax: 707-485-1243
Author of "Open Source Licensing: Software Freedom and 
                Intellectual Property Law" (Prentice Hall 2004)

> Sent: Saturday, June 03, 2006 3:44 PM
> To: [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Mon, 5 Jun 2006 16:41:19 -0700

>a copyrighted contribution does any contributor *need* to reserve? For what

Oh look, it's a road we've been down before.  The scenery is nice down this
particular lane, isn't it?  Pretty!

First, let's not conflate the right to copy with the right to modify *again*, okay?

Second, there are reasons a contributor might not want you to modify his words
(since they are the perfect expression of his intent, after all), but would
allow you to modify his code (since *its* perfection might have to fit into
whatever compiler or environment you have to deal with). 

Third, I don't care whether they *need* to reserve that right; some *want* to,
and this being a volunteer organization where contributors can re-allocate
their time on other things means we should pay attention to it unless it does
us real harm.  I personally don't think we should be asking for more rights than
we need to do our work, since I believe that principle of parsimony allows and
encourages the widest possible participation.  Losing participants *is* real
harm, and as someone who has to arm-twist on many fronts, I don't think
we can afford it.  If people *want* to grant more rights, I think we should
make it is easy for them to do so, but that is a far cry from saying that they
*have* to.

Hoping we can get back off Memory Lane,
					Ted Hardie

---

From: "Lawrence Rosen" <[email-masked]>
Date: Mon, 5 Jun 2006 21:46:54 -0700

Ted,

This is "memory lane" for me too. I remember some folks at the W3C Patent
Policy Working Group saying (1) "We don't want to..." and (2) "We'll quit if
you make us." As I recall, they didn't lose any actual members to that
threat either. 

So now, if you would please give me the opportunity of repeating that I DO
WANT THE RIGHT TO MODIFY! Stop being parsimonious (and gleeful about it!)
and stop telling me that you simply don't want to give that right to me, and
start explaining what it is about your copyrighted contributions to public
IETF working groups that are so precious that modifications by third parties
will damage your company. Because if all you've got is a spiteful refusal to
play the game as open source licenses need it to be played, perhaps we ought
not to accept such stingy grants.

To tie this point back to the original post, if IETF ensures that all
contributions to working groups become publicly available for copying and
modification, then we don't need to worry about what's code and what's text.
Overcome that important benefit with some reasons why your company's
contributions need greater copyright protections.

/Larry

Lawrence Rosen

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Monday, June 05, 2006 4:41 PM
> To: [email-masked]; 'Harald Alvestrand'; [email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 06 Jun 2006 07:37:06 +0200

Larry,

much as I sympathize with where you want to go, I have to acknowledge 
that we currently do NOT have such a consensus.

There's absolutely no doubt in anyone's mind that you and Simon want the 
right to modify anything and everything contributed to the IETF. But I 
fail to see anything resembling a consensus on that in the WG.

I do believe, however, that we have a strong consensus that:
- people expect the code they put into RFCs and I-Ds to be used for 
implementation of the standards
- people know that in order to use this code, they often have to modify it
- and that's OK

That wasn't obvious when we started on this trip either. But I think all 
participants have concluded that by now, given the many examples of 
reasonable need to modify even for the most narrowly scoped rights 
grants for use of code.

But - until I get a working definition of "code", I can't even STATE 
that this consensus exists, because someone inevitably comes along and 
says "but you can't say that this applies for code, because you don't 
have a definition of what code is".

So I'm trying to build agreement on a vocabulary we can use to express 
what we agree on, so that we can STOP wasting time on THAT.

But if we can't even get one step further on that road - we do have a 
problem.

                          Harald

---

From: Don Armstrong <[email-masked]>
Date: Mon, 5 Jun 2006 23:14:10 -0700

On Tue, 06 Jun 2006, Harald Alvestrand wrote:
> that this consensus exists, because someone inevitably comes along
> and says "but you can't say that this applies for code, because you
> don't have a definition of what code is".

Unfortunatly, defining what code is is an extreemly difficult problem.
We had a similar issue in Debian with people who felt that
documentation required a different set of freedoms than sourcecode. To
date no one has come up with a reasonable definition that adequately
separates code from non-code.

About the only thing that I can even begin to suggest is "a work which
was written with the intention of being readable by a deterministic
parser"; unfortunatly, I can easily sit here and argue that the words
that am writing were also written to be read by a deterministic
parser.

To shift gears, perhaps inexcusably: Can we consider two separate
states? 

1. Where at least the code can be modified and redistributed and the
2. Where all parts of the work can be modified and redistributed?

Contributors to RFCs given the ability to differentiate between these
two states; rights granted to the IETF to release under either state
given that no change will be made for N years without assent of the
rightholders, save for the preparation of derived standards documents
by the IETF?

Don Armstrong
 
-- 
UF: What's your favourite coffee blend?
PD: Dark Crude with heavy water. You are understandink? "If geiger
    counter does not click, the coffee, she is just not thick."

http://www.donarmstrong.com              http://rzlab.ucr.edu
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 6 Jun 2006 01:27:51 -0700

I'm sorry, Harald, but I cannot be motivated to seek consensus on such an
important point with people who base their position on a "principle of
parsimony." [1] What possible justification is there to withhold copyright
permissions that some of us feel are necessary based on a consensus to allow
stinginess? 

I've listened closely to this discussion and tried to understand why some
companies refuse to release for public benefit and free use otherwise public
writings that they contribute toward the achievement of an industry
standard. Their petulance isn't the basis for a well-reasoned policy, and I
for one cannot see how we can reach consensus around such an intellectually
shallow position. 

/Larry

[1] Parsimony: 1. Great frugality or unwillingness to spend money. (Encarta
Dictionary 2006.) 

Lawrence Rosen

> Sent: Monday, June 05, 2006 10:37 PM
> To: [email-masked]
> Cc: 'Ted Hardie'; [email-masked]

---

From: Scott W Brim <[email-masked]>
Date: Tue, 06 Jun 2006 06:33:58 -0400

> have a definition of what code is".

What happened to the idea that the contributor(s) themselves can
explicitly say what's "code"?

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 06 Jun 2006 12:42:38 +0200

> explicitly say what's "code"?
Nice for new stuff. Not nice for old stuff, and stuff where the writer 
is copying from old stuff.

I don't want a revised MIB module to be "non-code" just because someone 
forgot to put in a "code" marker.

The words
> documents where doubt could exist
were intended to point at the possibility of "code" markers. Should we 
say more explicitly that markers are allowed, but not necessary for the 
obvious cases? Or do you think we should say something else?

              Harald

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Jun 2006 08:11:39 -0700

At 9:46 PM -0700 6/5/06, Lawrence Rosen wrote:
>WANT THE RIGHT TO MODIFY!

Opportunity given.  I'll even accept that you can SHOUT about it, if you want to.

But since we're concerned about the rights being granted *by the people
doing the work*, not the rights desired *by the people who might consume it*,
I consider it kind of off topic.

> Stop being parsimonious (and gleeful about it!)

exhaustion with repetition != glee

Good luck getting off your own memory lane, and moving forward.

					Ted Hardie

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 6 Jun 2006 15:08:22 +0200

The trouble I am having is in seeing this as a distinct issue.  It reminds me of
Telco lawyers who argued that user directories had to be ISO layer three
(because that is where the Telco's monopoly ended).

Likewise here, I see the debate as between those who want freedom to extract and
modify to suit their ends and those who do not want the results of their efforts
to be changed unilaterally.  So if we define two sets of rights, one greater
than the other, then the argument will shift to what is code, with people
arguing before the IETF Trust that this is or is not code because that then ties
in with the rights they want.

So, I do not like the term code - it is too loaded, will lead to too many
arguments along the lines of 'of course this is what the IPR WG meant when they
used the term code'.  Rather, we need two (or more) sets of rights relating to
extraction and modification (which is where I believe the disagreement lies)
with neutral terms for them - rights limited and rights less limited, A and B,
etc

Tom Petch

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 6 Jun 2006 08:42:09 -0700

Ted Hardie wrote:
> Characterizing the decision of volunteers to release only the *necessary*
> rights for the standards as petulance certainly helps establish that you 
> aren't working for consensus.

1) I characterize the right to modify as a *necessary* right for open
source. What efforts are you making to achieve consensus with this essential
aspect of open source development?

2) You have *still* not given any intelligible reason why copyrighted works
that are publicly contributed to IETF need to be restricted from
modification. What aspect of Qualcomm's copyrighted works do you seek to
protect that could possibly justify burdening each working group to separate
"text" from "code" in IETF specifications?

/Larry
 
Lawrence Rosen

> Sent: Tuesday, June 06, 2006 8:16 AM
> To: [email-masked]; 'Harald Alvestrand'
> Cc: [email-masked]
> At 1:27 AM -0700 6/6/06, Lawrence Rosen wrote:
> That was answered in my previous note, which references parsimony in its
> scientific meaning:
> 
> 2: economy in the use of means to an end;  (Merriam-Webster Online
> Dictionary) .
> 
> Characterizing the decision of volunteers to release only the *necessary*
> rights
> for the standards as petulance certainly helps establish that you aren't
> working
> for consensus.
> 				Ted Hardie

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 6 Jun 2006 08:46:33 -0700

Ted Hardie wrote:
> doing the work*, not the rights desired *by the people who might consume
> it*, I consider it kind of off topic.

Did this working group stop worrying about IETF's customers? Or is this
comment yet another example that we've allowed the owners of copyrighted
works to dominate the policies of a public benefit organization?

Not off-topic; this is *the* topic.

/Larry

Lawrence Rosen

> Sent: Tuesday, June 06, 2006 8:12 AM

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 6 Jun 2006 09:15:53 -0700

David Harrington wrote:
> The products we produce for our customers are standards.

OK.

> Our customers want interoperability.

OK.

> Our contributors contribute to help achieve standards of
> interoperability, for the public benefit.

Good.

> Some contributors choose not to contribute their technologies for
> purposes other than standardization.

Again I ask, why is that necessary for those contributors? What value do the
contributors gain from that that can compensate for the added cost to IETF
of this "code vs text" effort? Or is it merely petulance?

> Only some customers want free specifications they are allowed to
> modify as they wish.

Those are customers I empathize with. They exist. They are more and more
important in the world of software.

/Larry

Lawrence Rosen

> From: David B Harrington [mailto:[email-masked]]
> Sent: Tuesday, June 06, 2006 9:05 AM
> To: [email-masked]; 'Ted Hardie'; 'Harald Alvestrand'; ipr-
> [email-masked]
> > From: Lawrence Rosen [mailto:[email-masked]]
> I disagree.
> The products we produce for our customers are standards.
> Our customers want interoperability.
> Our contributors contribute to help achieve standards of
> interoperability, for the public benefit.
> Some contributors choose not to contribute their technologies for
> purposes other than standardization.
> 
> Only some customers want free specifications they are allowed to
> modify as they wish.
> 
> David Harrington
> [email-masked]
> [email-masked]
> [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Jun 2006 08:15:53 -0700

2: economy in the use of means to an end;  (Merriam-Webster Online Dictionary) .

>for one cannot see how we can reach consensus around such an intellectually

Characterizing the decision of volunteers to release only the *necessary* rights
for the standards as petulance certainly helps establish that you aren't working
for consensus. 
				Ted Hardie

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 6 Jun 2006 12:05:27 -0400

I disagree.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Jun 2006 10:42:04 -0700

At 8:42 AM -0700 6/6/06, Lawrence Rosen wrote:
>What aspect of Qualcomm's copyrighted works do you seek to

I have never spoken on this list for Qualcomm, and you are outside
the bounds of IETF culture to impute a corporate motive to my
contribution.  I am not speaking for Qualcomm, the IESG, the
Episcopal Church or anyone else with whom I happen to have
an affiliation. 

I also don't think this is nearly as burdensome as you do.  Drafting
a description of code that is valid for all IETF documents may be a
daunting task, but I think it will be pretty obvious to most folks
writing a document which bits could be passed to a compiler or an
interpreter and which could not.  You can invent or imagine corner
cases, but I strongly suspect that it will be straightforward in
most cases we deal with.

I think Simon's recent effort in draft-josefsson-rfc3548bis-04.txt is
instructive.  It was not much work for him to identify the bits
for which he was author and could grant additional rights (see
his section 15); I think it took two rounds of email to do it.  Note that
he didn't need to know what was code to do that; he only needed
to know which bits were not ISOC's. 

He also knew going in that section 11.1 and 11.2 were code and, maybe
more importantly, were code for which different copying conditions should
apply.  Marking them as such with some token or well-understood phrase would
have not added much to the burden of publication. The real hassle was that
adding the notices related to his copying conditions and the code's
open source license requires IAB approval  of a variance to 3978.  Getting that
sorted out is a bigger burden than we need, and I'm glad Simon has
proposed a way forward from it.

				Ted Hardie

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 6 Jun 2006 12:11:46 -0700

> cases, but I strongly suspect that it will be straightforward in

And in which world is it useful or economically practical to rewrite from
scratch the *text* that surrounds *code* whenever the *code* is modified?
Why should the *text* and the *code* be treated differently in IETF
documents? What economic or other interests does it serve to distinguish the
two? What is the cost of including such mind-numbing distinctions in our
already obscure standard-setting process?

> instructive.  It was not much work for him to identify the bits
<snip> 
> Getting that

I'm also grateful for Simon's efforts. I just think we should take not only
steps forward but also occasionally steps back, in this case back from the
abyss of silly distinctions between *text* and *code* in published industry
standard specifications to which we all contribute. 

/Larry

Lawrence Rosen

> Sent: Tuesday, June 06, 2006 10:42 AM

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 07 Jun 2006 17:02:25 +0200

I agree with Larry here.  The distinction between code and text is not
a terribly fruitful one.  The distinction was not in RFC 2026, as far
as I can tell.  I believe we should take a step back here.

Generally, the code vs text issue had little to do with the concerns I
discussed in draft-josefsson-ipr-rules-update, review the problems at:
http://josefsson.org/bcp78broken/

However, closing this issue seems like a good move now.  What we are
seeing here is wasted time on solving something that we did not first
establish whether it is relevant to what this WG has been chartered to
do.

I do fear that the process will be to close all issues without
discussing the principles guiding the decisions behind each current
and future issue.

/Simon

---

From: "todd glassey" <[email-masked]>
Date: Wed, 7 Jun 2006 08:31:38 -0700

You mean like maintaining value in the IETF brand and Process?

Todd

---

From: Thomas Narten <[email-masked]>
Date: Thu, 08 Jun 2006 09:20:01 -0400

> Again I ask, why is that necessary for those contributors?

This question misses the point. We've had this discussion, and there
are folk that have this opinion. You (or I) may not like the answer
that has been given, but that doesn't make it "wrong" or "invalid" or
one that trying to reopen (with no new arguments to bring to the
discusion) is likely to change. And for better or worse, it is "IETF"
consensus we are after here, not the consensus of some other or larger
group.

What I've observed is that the main desire of this group seems to be
to produce open standards (emphasis on _standards_). Open source
clearly plays a role in this space, but is one of many constiuencies,
and is by no means the only one.

Thomas

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 08 Jun 2006 17:41:42 +0200

Thomas Narten <[email-masked]> writes:

> discusion) is likely to change.

Do those with that opinion participate in this WG?  I wish they would
give their justification

> And for better or worse, it is "IETF" consensus we are after here,
> not the consensus of some other or larger group.
>

It seems that this argument runs both ways.  Those who do no wish to
contribute their work under licenses that can be re-used by free
software developers play a role in open standards, but is one of many
constituencies, and is by no means the only one.

I don't see why the voices from people arguing for "closed" standards
should have more weight than those who argue for "open" standards.

Perhaps one way forward would be to write a document that explain what
RFC authors can do to help free software developers use their
documents.  For example, what additional license grant they can put in
their documents.  Does anyone think such a document would belong in
this WG?

Thanks,
Simon

---

From: "todd glassey" <[email-masked]>
Date: Thu, 8 Jun 2006 09:59:53 -0700

Simon - one of the core problems with this WG is that it seems to think it
can redesign and deploy global IP law and that is pure merde. The IETF is
constrained by any number of legal frameworks based on those of its
participants and whatever solutions it comes up with here in IPR must meet
the requirements of all of them... Unless that is, that the IETF is going to
create a contract specifiying "choice of law" with its participants.

This is the problem of how this WG is operating. So what are the answers  -
Simple just answer the following:

    1)     As I  remarked - a stake in the ground in regard to what IP
rights are necessary to participate in the IETF's Standards Process - So
lets answer the question - what rights does the IETF itself need to advance
a standard through its processes. What rights are mechanically used and what
are not???

    2)    In addition to that - the IETF seems to want additional rights to
the IP beyond what are needed in the Standards process - and those
specifically have value - which is something that the Submitter should have
the option of granting one would think, so how do we judge that value is and
what is it that the IETF is trading for this extra value???

    3)    The patent and publishing rights are tied inextricably to each
other. There is no way to publish without altering or effecting the IP
protection capabilities under US and Foreign Patent Laws - and this is
totally intentionally ignored to date in ***all*** ietf operations and
control documents. That must change - there are liabilities of which the
IETF is aware of and intentionally ignoring, and this head-in-the-sand
posture will not protect it or the participants and their sponsors when one
of these matters does wind up in court.

There are more issues - but these are a good start.

Todd Glassey

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 8 Jun 2006 13:12:54 -0400

> From: Simon Josefsson [mailto:[email-masked]] 
> 
Yes. I hold that view and I participate in this WG.

When I author a document, I am willing to grant copyrights to the IETF
for standards work.
But I do not choose to give the IETF the right to decide for me
whether other people should also be granted such rights for purposes
other than standards work.
If somebody wants me to grant them copy-rights to do open source work,
I am likely to say yes. But before I agree to anything, I will want to
see what the work is I am granting those rights for. And if I disagree
with what the work is for, then I want to have my authors' rights to
say no, you cannot copy this for a purpose unrelated to developing
industry standards.

It is as simple as that.

> constituencies, and is by no means the only one.

That is correct; and open source developers can ask authors to grant
them rights to reuse their documents, and the authors have a choice of
saying yes or no. They are not all compelled to say yes because an
IETF IPR WG document says they have to say yes.

> should have more weight than those who argue for "open" standards.

They don't.
But authors have more legal right to their own work than non-authors
do.
 
> their documents.  Does anyone think such a document would belong in

I do not. It is not an IETF concern. 
It is an issue between the potential-consumer and the author(s) that
produced it. 

Such a document certainly could be written as an Informational draft
from an individual, though.
And because I believe open source is generally a good thing, I
encourage you to do so.
David Harrington
[email-masked] 
[email-masked]
[email-masked]

---

From: "Lawrence Rosen" <[email-masked]>
Date: Thu, 8 Jun 2006 11:03:28 -0700

> 1) ... what rights does the IETF itself need to advance
> a standard through its processes. 

Copyright and patent. (Maybe take advantage of trademark.)

> 2) ... so how do we judge that value is and

Listen to the discussion, Todd, and learn what others think.

> 3) ... The patent and publishing rights are tied inextricably to each
> other. There is no way to publish without altering or effecting the IP...

Not really true, Todd. So please let this group get on with designing the
*copyright* procedures of IETF without confusing it with *patent* rights.

To be perfectly clear, I have advocated that the *copyright* in
contributions be licensed to IETF and its customers for all purposes
mentioned under copyright law. I can see no value to a contributor
publishing his contribution to IETF and the world and then telling people
that they can't freely use it for all purposes. What's the point? What's the
need for any restrictions? (I'm listening for people on this list to justify
their withholding such rights from IETF and its customers, so that this WG
can fairly weigh the benefits and the burdens of whatever *copyright* rules
IETF adopts.)

As for patents, patent licenses can be limited to the practice of a specific
standard without affecting either copyright rights in the specification
itself, or the freedom of recipients to modify the specification to
implement non-patent-infringing or licensed derivative works. When properly
written, such limitations are at least consistent with open source licenses
(although not appreciated by many open source developers). So let's please
keep the patent discussion separate from the copyright discussion.

/Larry

Lawrence Rosen

> From: todd glassey [mailto:[email-masked]]
> Sent: Thursday, June 08, 2006 10:00 AM
> To: Simon Josefsson; Thomas Narten
> Cc: [email-masked]; [email-masked]

---

From: Don Armstrong <[email-masked]>
Date: Thu, 8 Jun 2006 12:09:36 -0700

On Thu, 08 Jun 2006, David B Harrington wrote:
> When I author a document, I am willing to grant copyrights to the
> IETF for standards work. But I do not choose to give the IETF the
> right to decide for me whether other people should also be granted
> such rights for purposes other than standards work. 

Just to back up slightly, if you give IETF the copyright, you've given
IETF the right to do whatever the IETF wants with a work. For the
sake of discussion, I'll assume that you meant a restricted copyright
license of some sort.

> If somebody wants me to grant them copy-rights to do open source
> work, I am likely to say yes. But before I agree to anything, I will
> want to see what the work is I am granting those rights for. And if
> I disagree with what the work is for, then I want to have my
> authors' rights to say no, you cannot copy this for a purpose
> unrelated to developing industry standards.

I'm still a bit confused: wouldn't anything that was published as an
IETF standard necessarily be involved in industry standards or the
development thereof?

If there are parts of such a document that when derived stop being
related to standards development perhaps they don't belong in the
standards document in the first place?

[It could also be that as a Free Software developer I am unable to
understand the mindset of authors who wish to control their works in
this way; I want my works to escape and people to be able to build
upon them and continue to do so.]

Don Armstrong

-- 
"...Yet terrible as UNIX addiction is, there are worse fates. If UNIX
is the heroin of operating systems, then VMS is barbiturate addiction, the
Mac is MDMA, and MS-DOS is sniffing glue. (Windows is filling your sinuses
with lucite and letting it set.) You owe the Oracle a twelve-step program."
 --The Usenet Oracle

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 8 Jun 2006 15:42:09 -0400

Hi Don,

I believe you are correct; as an author I would only grant a rstricted
license for copying, as specified in RFC3979 (and RFC3980?).

Here's my mindset.
Assume I with others worked long and hard to develop a very detailed
specification, possibly even with code, and we submitted it to the
IETF, and the IETF through normal processes considered it adequate to
be declared a standard. So the specification gets published in an IETF
document.

Now assume somebody disagreed with the WG, and did not work with the
WG maybe because they had IPR in the space they didn't want to
disclose. So they take the IETF document, implement the detailed
specifications, saving them hours upon hours of having to do their own
designs. Then they change a small portion of the design to their
liking and then they market it as an alternative to the standard.
Assume they have no desire whatsoever to fold those changes back to
the standards community.

I do not see much reason why I as an author should want to contribute
my work to somebody who obviously has no desire to help the community
or to work on improving industry standards and interoperability; they
care only about themselves and their bottom line. I want to be able to
say "no, you cannot do that!", or at least to put them into a position
where they realize they could be subject to a legal challenge.

That's my mindset.

It seems to me it is also the mindset of an awful lot of open source
developers who use licenses like the GNU license to ensure that others
cannot use their work unless they also contribute their work back to
the community.

dbh

> From: Don Armstrong [mailto:[email-masked]] 
> Sent: Thursday, June 08, 2006 3:10 PM
> To: [email-masked]

---

From: "todd glassey" <[email-masked]>
Date: Thu, 8 Jun 2006 13:23:59 -0700

David/Don
what about IP that the IETF doesnt and wont own... Is that IP that is to be
excluded from the IETF's Standards Process?

---

From: "Lawrence Rosen" <[email-masked]>
Date: Thu, 8 Jun 2006 13:55:30 -0700

> Assume they have no desire whatsoever to fold those changes back to

What is it about your *copyright* license that you think prevents that from
happening today? 

The only thing copyright might cause to happen is that they have to spend
more time creating from scratch the *expressive* content of the IETF
specification, assuming anyone can distinguish expression from idea. Big
deal! Think that will stop anyone from doing the evil you describe?

I share your concern over the problem, but please don't burden open source
with an ineffective solution to the problem. 

/Larry

Lawrence Rosen

> To: 'Don Armstrong'; [email-masked]
<snip>

---

From: "todd glassey" <[email-masked]>
Date: Thu, 8 Jun 2006 16:33:09 -0700

Larry congrats on getting listed on what I call the "Stand-Up" page on the
SLS (Stanford Law School) website... Notice that most of the others there
either have Stanford.EDU or their firms names attached to them or they are
recognizable names in the Silicon Valley world... and then there you are.
You know - people like Judge Flies-Away for instance who is one of the
cornerstones of Native American Law here in the West.

You know Larry there was a Farm Days Mock-Trial Presentation a couple of
years ago with the Supremes sitting Justice Sandra Day Oconner and a couple
of other no-names like California Supreme's sitting Chief Justice RM George
(SLS 64 by the way) , and the University's President Dr. K. This all
happened in Memorial Auditorium in the Memorial Hall compex for those
familiar with Stanford. It was incredible - they argued a case the US
Supreme Curt had argued pertaining to civil rights in the 50's.

Very powerful session - and that's what Stanford is really all about IMHO.
Or like the Internet and Society's E Rader who wrote the petition for the
CARP Stay for Day360 - Yow Ms R!... Or the I&S's Associate Director Ms. G
who fought the battle over disclosure and the CFAA before the 9th Circuit.

The school is a wealth of powerhouses - hell  they have Dean Kathleen
Sulivan on staff or Paul G. Mr. Copyright himself - (isnt he still at
MoFo?)... or any number of the others.  So yeah - I do think SLS is hot -
but I would appreciate it if you didnt need to ram it down our throats - If
you were a visiting fellow at the Hoover Institute it would be different,
but your not - at least yet.

---

My responses to your ludicrous retorts is inline below including the one
where we define "what it is to the ability to patent an IP that the
publication of an ID or RFC does".

----- Original Message ----- 
From: "Lawrence Rosen" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 08, 2006 11:03 AM
Subject: RE: #1175 Code vs text - second attempt at resolution

> Copyright and patent. (Maybe take advantage of trademark.)

Which means that there can be no retained rights in the IETF process in your
mind. The IETF MUST own all component rights so that the Trust can sell
licenses for them, right Counsel?
> Listen to the discussion, Todd, and learn what others think.

Which means what??? - that the IPR WG gets to renegotiate standing law and
precedent... you need to roll yourself another one partner...

FWIW - I have listened and there are many people here who seem to think they
can rewrite the law... its pretty funny too to watch the only two attorneys
who still participate here - you and Jorge, try to jocky their own
initiatives into position without answering ***ANY*** of the big questions
or saying anything they can be held accountable for.

So let me do some analysis on what it is you seem to want to accomplish -
correct me if I am wrong. You, based on everything I feel you have tried to
stop from happening here, seem to have a specific interest in creating a way
to globally standardize Open Source Products, and since I am a capitalist I
will assume its for one reason - that being to increase their marketing
value in competing with commercial products, or I could be wrong and you
could be a SW Marxist rising from the grave to try and claim the world owns
it all...  I hear Karl screaming from the Grave already.

Please correct me if I am wrong.

> Not really true, Todd.

OK so its not technically the RIGHTS - its the time clocks for the ability
to file patents, which are started with the IETF's formal publicaiton of an
I-D for instance.  That is a fact is it not Counsel? The publication of any
undisclosed IP in a standards disclosure process, like an I-D for instance
starts those time clocks running... or in Japan prevents any filings, and
this is because those publications are counted as prior art, an that's that.
Poof - Done - End of story.

Or would you like to formally go on the record - but I dont think you are
self-destructive enough to do that now are you Counsel?

> So please let this group get on with designing the

So let me ask this Mr. Stanford Lecturer... why didnt you just correct my
mis-speak and notice its not technically "the rights" - but the the time
clocks which control "the abilty  to file for patent protection" that are
affected by the IETF's publication???

Wouldnt have gotten any mileage out of that now would ya?

> mentioned under copyright law.

yeah I bet...  So... what has this to do with anything I was saying?

By the way you used some alarming language here - so define it for me will
ya?

"Customers" - who are they? In order for there to be customers they have to
be buying something - and that brings the issue of valuation back... and
contracts.

"Contribution's???"  - Counsel - you are stuck on the term CONTRIBUTION and
that is not what is happening here. Otherwise if it is the IETF owes a wad
of back taxes since it isn't a 501.3c at this time. Customer's buy and dont
contribute.

What is happening in the IETF's standards process is that people are
exchanging their copyright's against a particular document, and not anything
further than the republication rights to the documnent. And they formally
transfer these rights without a signature (which is questionable) to the
IETF for a chance to vet 'a protocol proposal' in an IETF WG.

The republication rights are the cost of that participation then, and this
then is clearly not a gift no matter what the delusional language appears in
the documents.

> I can see no value to a contributor
> that they can't freely use it for all purposes.

Here again - Why is it a "contribution to the WORLD" - where did they come
from? Does participating in the IETF's process mean giving away all rights
to the IP?

So we are clear on this, that means you advocate, and it is your aim here
that all technologies should belong to the world and not to private parties,
is that right???

> What's the point? What's the

Oh I dont know - To allow for privatized IP to be brought into the IETF
which it cannot be now. To create a standards process that allows for
standards to be created without having to give the property away in the
process.

> implement non-patent-infringing or licensed derivative works.

This is true - but the issue is that the patentability of any IP is
partially tied to timely filings and that means that the First Publication
Date issues must be controlled.

> When properly

So are you giving this as formal legal advice???

> > the requirements of all of them... Unless that is, that the IETF is
going
> > to

---

From: Ted Hardie <[email-masked]>
Date: Thu, 8 Jun 2006 17:00:20 -0700

>with an ineffective solution to the problem.

This seems a wee bit inconsistent.  It is no trouble for the evildoer to recreate and modify
the expressive content of the IETF specification and get on with their rampage,
but it is too much trouble for the open-source white hat to do it?

Remember, we all agree that the white hat can copy the spec, translate it, and
excerpt it; that discussion has already reach consensus it.  It's *only* the case
where change is at issue that we're talking about it.  As an author, David is saying
"I want change control for uses outside the standards process"; he wants to
hold on to the right to determine who uses the work when it is not the IETF.

I personally think David's reasoning is reasonable; he doesn't want his time and effort
going to a competing effort.  In situations where forking is bad for the Internet this
is pretty sensible stuff.  But whether we agree or not on that point, I hope we agree
that it is his decision at this point.   If we change the rules of the game so that he
*must* agree to any use, then we risk losing him as a participant.  That's a real
cost to a volunteer organization. 
				Ted Hardie

---

From: Don Armstrong <[email-masked]>
Date: Thu, 8 Jun 2006 20:42:48 -0700

On Thu, 08 Jun 2006, David B Harrington wrote:
> specifications, saving them hours upon hours of having to do their
> own designs. Then they change a small portion of the design to their

This actually happens all the time in the Free Software world: it's
called forking. As painful as it may be to see someone take your work
and do something to it that you don't like, in the end it ends up
making the community better because of it. [Forks that don't make the
community better tend to die off because they are technically bad, not
because someone threatens them legally.]

I've no problem with IETF licensing standards so that those deriving
the standard have to license their work in a manner that allows their
works to be folded back into the standards community. [I don't know if
everyone else would agree to that, though.]

Don Armstrong

-- 
I now know how retro SCOs OSes are. Riotous, riotous stuff. How they
had the ya-yas to declare Linux an infant OS in need of their IP is
beyond me. Upcoming features? PAM. files larger than 2 gigs. NFS over
TCP. The 80's called, they want their features back.
 -- Compactable Dave http://www3.sympatico.ca/dcarpeneto/sco.html

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 08 Jun 2006 23:57:14 -0400

There is indeed a strong argument that for many open software 
coponents, forking, and the resulting exploration of alternatives, is 
beneficial.
There is a strong argument that for many sets of standards, competing 
alternatives are also useful.

However, the point of the IETF is to develop interoperable 
standards.  It is not to encourage experimentation and the 
development of alternatives.  For example, one of the often-cited 
undesirable approaches of other standards bodies is to put every 
option in that anyone wants.  (Note: it is irrelevant whether this 
actually happens elsewhere.  I have certainly seen people trying to 
do it at the IETF.)  Such an approach tends to prevent 
interoperability, since one often ends up with multiple 
implementations with different, inconsistent, sets of options.

Put bluntly, forking standards is in my opinion a very bad thing.  TO 
the degree that this discussion is about enabling forking, that would 
be a strong reason in my view for prohibiting modifications.  At 
least that way we are not encouraging forking.  [We can not and 
should not prevent implementors from doing whatever they want.  But 
they should not be doing so in the name of the standard.  And the 
standard structure should not encourage non-interoperable implementations.]

Yours,
Joel M. Halpern

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 09 Jun 2006 10:41:12 +0200

> When I author a document, I am willing to grant copyrights to the IETF

For standard works to be useful, implementations are required, and
you'd help get interoperable implementations by releasing rights to
the document.  This is especially important when the document contains
source code or data tables.

I don't see why you would be interested in standardizing something but
not be interested helping others to implement your standard.

> other than standards work.

The current draft in this WG would give the IETF that right, if I
understand it correctly.

> It is an issue between the potential-consumer and the author(s) that

I'm less convinced here.  The document would affect what goes into
RFCs, and thus in some sense could be considered an IETF matter.  But
it may be that the current IPR WG charter doesn't cover this work, and
if so, I won't pursue it within this WG.  The document would surely
benefit from review from this WG, though.

> And because I believe open source is generally a good thing, I

The idea of producing such a document has come up a few times before,
and it seems like one way to make some progress on this issue.

When I have asked RFC authors whether they are willing to release some
rights to their document, I've so far ended up these states:

 1) The authors didn't believe he had the rights anymore, and cited
    the ISOC copyright in the document and said the ISOC owned the
    document now.  IIRC, this was for the IDNA documents.

 2) The authors agreed to release (parts of) the document under a free
    license.  This was for most authors of the Kerberos ASN.1 schema,
    and maybe (I don't remember) also the GSS-API header.

 3) The authors changed the copying conditions in the document before
    it was published.  This was for the SHA-2 document.

 4) It was difficult (i.e., time-consuming) to chase down the current
    address of the author, or the author never responded.  This was
    for two authors on the Kerberos ASN.1 schema.

What is interesting here is that no author so far explicitly
disagreed, and said they didn't want to release the document under a
free license.

Thus, a document that explain the reasons for releasing additional
rights to documents, and suggested license text to do so, appear to be
useful.  If for nothing else, to point at when I contact RFC authors
in the future.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 09 Jun 2006 10:58:39 +0200

> where they realize they could be subject to a legal challenge.

I believe the IETF permissions allow them to take your RFC, change a
few words to their liking, and then post it as an Internet Draft.
Given how many companies and organizations refer to I-D's as "IETF
standard" today, they would now have a document that says what they
want, and you couldn't stop them.

> cannot use their work unless they also contribute their work back to

This is incorrect.

First a technicality: The GPL permits you to use (even modified)
copies of GPL'd works without contributing them back to the community.
It is only when you distribute a copy that you have to give a copy of
the (modified) source code to the person you are distributing the work
to.  You don't have to publish it on the Internet.

Second, I don't see how the mindset is similar.  You appear to want to
control the _purpose_ other people will be using your work for.  The
GPL doesn't restrict the purpose derived works can be used for, it
actually does the opposite, it enables derived works to be usable for
_any_ purpose.

/Simon

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Jun 2006 07:39:43 -0400

Folks,

I just had the "opportunity" to read this almost this entire
thread for the last four days at once.  Some summary
observations:

(1) The topic has, as usual, strayed from the "code vs text"
question to the question of why any right-thinking person would
ever both participate in a standards process and want some
restrictions placed on use of his or her words.   In the process
of that shift, it has been suggested that standards with such
restrictions are not open standards at all.

(2) I do not believe that a single new idea has been introduced
into the conversation.  To a considerable extent, I believe that
people are repeating the same arguments over and over again in
the hope that will somehow convince people who, at this point,
either understand the positions with which they disagree
perfectly well or who aren't listening.

(3) Possibly as a side-effect of (2), we are engaged in
reasoning involving a rhetorical device similar to "please
explain what you hope to accomplish by that restriction.  If you
can't convince me your goal would be effective, it doesn't count
and, if you can, I'll just ignore you and repeat the question
again".  That characterization doesn't apply to every such
instance of such question or the people asking them, but it is
occurring often enough to have become part of the problem.

(4) For those who claim it is difficult or impossible to
implement anything without the right to fork, two observations.
The first is that some people here clearly disagree with you.
Perhaps they are delusional that copyright is of any use
whatsoever in preventing or impeding the behavior they don't
like, but being delusional has, so far, not been an impediment
to IETF participation as long as the delusions don't impact
one's technical work.  Curiously, if they are wrong and
copyright offers no protection against forking or misuse of
standards, text, or forms of expression, I think that would make
this discussion a waste of time.   Second, standards published
by ISO, ANSI, DIN, etc., are protected by much more restrictive
copyright assertions than those of the IETF.  There is evidence
that implementation of some of them have been impeded by the
cost of the standards, but I don't believe there is any evidence
that implementation has impeded by the existence of those
restrictive copyrights.    Hmm.  Perhaps we could fund the IETF
by getting people to donate devices that have become offensive
because they conform to standards that are covered by
copyrighted documents that do not permit the use of their text
for any purpose anyone desires.  

      john

---

From: "todd glassey" <[email-masked]>
Date: Fri, 9 Jun 2006 05:34:32 -0700

Don - nice try - Forking in the design of the standard that the code is
derived from DOES NOT produce the effect you and many others have
represented it will, and the damage that forking inside the processes at the
top of the pyramid creates chaos and not a chaor of genesis, but a chaos or
"no I want it this way" which the IETF is so famous for its ludicrous.

Todd

---

From: "todd glassey" <[email-masked]>
Date: Fri, 9 Jun 2006 06:24:16 -0700

John -

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: <[email-masked]>
Sent: Friday, June 09, 2006 4:39 AM
Subject: RE: #1175 Code vs text - second attempt at resolution

> restrictions placed on use of his or her words.

Not Quite John - This isnt about rehashing old areas - its about answering
critical precursory questions which policy and process of the IETF dont...
So... the questions are simple

    1)    Does the IETF intend that by participating in its process - that
any and all IP submitted to it will become openly available at some
predefined licensing model

    2)    Does the IETF intend through its own actions of through those of
the Trust, to charge for the use of any of this IP - since that will change
everything and force IP valuation issues to be resolved and taxable value
issues resolved as well since the IETF is not a 501.3c at this time nor was
any of the IP that has been sibmitted to the IETF to date been accounted for
as such.

> In the process

And that the IETF's oversight is ineffective or non-existent...

> into the conversation.

How about this then - 23 Engineers were laid off of Coastek based entirely
on a Venture Capital firms pulling the rug out from under it when PKIX
refused to hear a second, and competitve Time Stamping proposal. Why this is
imporant is that this was at the time when the first I-D's were filed for
what would later become RFC3161, and which the management of PKIX
intentionally prevented from even being considered.

This is proof of the failing of the IETF process, its methods and its
oversight and if you have any doubt of this - I can point you to any and all
of those 23 people who wound up looking for work becuase the IETF wasnt as
it claimed, fair and open, and more importantly - its has no effective
operating controls.

> To a considerable extent, I believe that

John NO WE ARE NOT - You folks refuse to answer key questions becuase you
and many others know those answers are not what the commercial or subsidized
particiupants want to hear. The only ones these words are threats to are
those that have made their jobs on the mismanagement of the IETF and who
would be threatened by any sane person's reciew of these preposterous
statements of yours which try to make anyone who disagrees with your
commentary a fool or just patently wrong.

This is typical BS from a Technologist - "Please dont ask me to make sense,
I know my logic is broken but its how I hide from the truth" - Get a clue
John.
> one's technical work.

The problem is this retort is delusional... The facts are that the IETF's
release specifically covers REPUBLICATION and ANY AND ALL OTHER USES, and
most of the IETF's participants have no idea that they "just gave it all
away" according to the words on the submission models of today.

I am absolutely positive by the way when you rev IPR Policy Documents and
change the engagement rules that no updated contractual agreements by those
on the other side of the participants is/are ever collected or codified...
meaning this is all a crock - since the person attending and participating
clearly doesnt have an enduring power of attorney from their sponsers and
that is what this language requires and assumes.

> Curiously, if they are wrong and
> copyright assertions than those of the IETF.

Funny thing that eh? - and the IP conveyance models are rock solid too so no
one relying on the ANSI standards has to worry about where their IP came
from - the same is not true for the IETF.

>  There is evidence
> cost of the standards,

Such as?

> but I don't believe there is any evidence
> restrictive copyrights.

I agree.

>   Hmm.  Perhaps we could fund the IETF

---

From: "todd glassey" <[email-masked]>
Date: Fri, 9 Jun 2006 06:25:53 -0700

Simon - Nice political answer... Basiscally wrong but policically correct
words.

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "David B Harrington" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, June 09, 2006 1:58 AM
Subject: Re: #1175 Code vs text - second attempt at resolution

SNIP -

> want, and you couldn't stop them.

yes thet do - and this is the failing of the release language in the I-D.
The I-D's should ONLY be usable within the IETF's Standards Process - any
other use steals thunder of the IETF's process.

> > cannot use their work unless they also contribute their work back to

No Simon - you are wrong... Not in a mass distribution sense its not -  For
the Red Hats of the world you may be right,  but lets see Oracle make the
DBMS system Open Sourced... The facts of the matter are that Open Source SW
makes up a fraction - a reasonable sized fraction - but a fraction none the
less, of the total software marketspace. Designing a process which favors it
will leave the bulk of the marketspace unaddressed.

> to.  You don't have to publish it on the Internet.

Except that the GPL License does not deal with licenses that are more
restrictive, so the GPL license would either set aside internally
contributed releases or would be legally ineffective since it sought to
grant rights it didnt have to grant.

> control the _purpose_ other people will be using your work for.

yes...

> The

Which means that the owners of the IP lose control of it. The cannot license
the IP or control the markets the IP is entered into.

---

From: "todd glassey" <[email-masked]>
Date: Fri, 9 Jun 2006 06:53:07 -0700

Simon - I disagree with much of what you used as justification for this
submission briefing type document idea - but the idea itself is good and
this content SHOULD be added to the submission release for when a document
is submitted to the IETF -

In fact, Rosen-San  for all the bashing you and I do here on this list - I
think you personally should write this guidance document - it should contain
instructions for filing these IP's with the IETF, and a set of statements
about Open Source and possibly links to the OSI policy and FAQ for more
information.

As the OSI's ex-General Counsel there is probably no one better to write the
piece about open source submissions to the IETF and what they ential and
require.

More commentary inline below.

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "David B Harrington" <[email-masked]>
Cc: "'Thomas Narten'" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Friday, June 09, 2006 1:41 AM
Subject: Re: #1175 Code vs text - second attempt at resolution

> not be interested helping others to implement your standard.

And that is the problem here ... Your views are restricted to a process that
honors  that all this property is the worlds - and its not. At least not
yet.

> The current draft in this WG would give the IETF that right, if I

yes ad this is a VEY important statement since it implies that there are
contractual changes in the IETF's process and engagement policies that it is
not getting arrpoval from before unilaterally altering contracts it has in
place with hundreds if not thousands of particpants.

The IETF's current submission model from my workflow analysis not only
transfers copyrights by patent rights as well through the unconstrained use
of the "Any and All Uses" language which is not limited or roped-in by the
addition of  "any and all publication uses for the Standards Process
Development"

> >> their documents.  Does anyone think such a document would belong in

yes - it clearly is an IPR disclosure and so its home is here. But this
should be part of the submissions boiler plate not a separate document.

> RFCs, and thus in some sense could be considered an IETF matter.

If its in the release boiler plate it does

> But

If you had asked me about the ACTS I-D I would have told you the IETF cannot
control its Copyright - that belongs to NIST and is done so under the
Federal Use rules for government developed IP's.

> disagreed, and said they didn't want to release the document under a

Hmmm - Asking the right question of the wrong person gets you the wrong
answer...

The AUTHORS were speaking for themselves and NOT their Sponsers and that is
the disconnect - ask those same questions of the General Counsel's of the
Participant's Sponsers and YOU WILL GET THE ANSWER YOU ARE FEARING MOST.

> useful.  If for nothing else, to point at when I contact RFC authors

I would agree - and it should be a part of the release contract for
submission of media for publishing.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 12 Jun 2006 13:09:01 +0200

Hi Joel.  You make a good argument against forking standards, and I
totally agree.  If two companies claim to implement "OpenPGP" but they
use different specifications for the protocol, we'd get nowhere.

However, I fail to see what it has to do with enabling modifications
of documents.  It seems to me that you assert that "modifications"
enable the situation where we have two different documents that
describe OpenPGP, and then jump to the conclusions that
"modifications" is bad because two different documents describing
OpenPGP is bad.

I don't follow your logic.  I can write a document that claim to be a
description of the OpenPGP protocol today, without infringing on the
copying conditions of RFC 2440 (I simply rewrite it). [1]  So
disallowing "modifications", per se, doesn't appear to solve your
problem here.

I think that some aspects of your "problem" are useful to the IETF.
Forking standards is also how standards evolve.  Take for example
DNSSEC.  The current DNSSEC standard (RFC 4033++) is not remotely
compatible with the old DNSSEC standard (RFC 2535++), but it builds on
the old documents.  It is not unreasonable to imagine that the new
version evolved from the old when someone took the old document and
changed somethings and circulated it BEFORE sending it to the IETF.

Is it not the IETF itself that is important, it is the work done under
the IETF umbrella that's important.

/Simon

[1] OpenPGP happens to also be a trademark, but that is not relevant
to this discussion.  Actually, it would be possible to write a
"Description of OpenPGP" without infringing on the OpenPGP trademark.
A trademark only becomes a problem if you claim to "be" OpenPGP.

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

> However, the point of the IETF is to develop interoperable standards.
> It is not to encourage experimentation and the development of
> alternatives.  For example, one of the often-cited undesirable
> approaches of other standards bodies is to put every option in that
> anyone wants.  (Note: it is irrelevant whether this actually happens
> elsewhere.  I have certainly seen people trying to do it at the IETF.)
> Such an approach tends to prevent interoperability, since one often
> ends up with multiple implementations with different, inconsistent,
> sets of options.
>
> be a strong reason in my view for prohibiting modifications.  At least
> that way we are not encouraging forking.  [We can not and should not
> prevent implementors from doing whatever they want.  But they should
> not be doing so in the name of the standard.  And the standard
> structure should not encourage non-interoperable implementations.]
>
> Yours,
> Joel M. Halpern
>

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 12 Jun 2006 13:25:46 +0200

> rightholders, save for the preparation of derived standards documents

I think this may be a good compromise, especially if we move this
decision to RFC authors rather than the IETF and the IETF Trust.  It
may be simpler to influence RFC authors to grant additional rights.

While we are waiting for this WG to produce something useful that
covers all IETF contributions, we can explore ideas in parallel.

/Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 12 Jun 2006 09:20:54 -0400

I would agree that what you have asked for is not the ability to fork 
standards.  That was raised by someone else.

I do think that allowing modification of the text of standards does 
make it easier and more likely that standards will fork.

And I have not seen a case made that I find persuasive as to the 
benefits to the community as a whole of allowing modification of the 
text of standards documents.  You have made a persuasive case that we 
need to allow both the inclusion and the modification of code from 
our standards.  In particular, we need to allow the inclusion of such 
code.  And to include such code, we need to permit modification.  And 
bug fixing is also necessary.

In contrast, I do not see that folks need to include text segments 
from the standards in order to build interoperable, maintainable 
packages that use those standards.  I don't mind their including 
unmodified text.  But if anything that is included must be 
modifiable, then don't use the words from the standard in the product.

Yours,
Joel M. Halpern

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 12 Jun 2006 15:45:30 +0200

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

> need to allow both the inclusion and the modification of code from our
> standards.  In particular, we need to allow the inclusion of such

Several of my original issues was regarding text, not code.  I have
not supported the distinction between text and code at all.  Two
examples (see #1 and #5 on <http://josefsson.org/bcp78broken/>):

* The simplest case is the ability to include quotes from RFCs into
  modifiable free source code.

* The ability to include text from standards into documentation, such
  as the getaddrinfo man page, which both Sun and FreeBSD has done
  (thus violating the IETF copying conditions).  I'm using excerpts
  from RFCs to describe SASL and Kerberos protocols in my products.

Both of these are already in widespread use, and I also believe they
ability to use documents this way helps to promote the IETF's stated
goal, so I find them persuasive.

What is it about these examples that aren't persuasive?

> packages that use those standards.

I do see that need.  People are already doing this in "running code"
for many widely deployed protocols in free implementations, thus
demonstrating the need.

> I don't mind their including unmodified text. But if anything that
> is included must be modifiable, then don't use the words from the
> standard in the product.

To me, the consequence of that appear to be to harm free software
products, and to put them at a disadvantage.  I claim harming free
software harms the interoperability of IETF protocols.  Thus, I think
the IETF community should help free software implementations of IETF
protocols.

Thanks,
Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 12 Jun 2006 10:07:42 -0400

There seem (and I will say I may be misunderstanding you) to be two 
issues that result in this being less than persuasive for me:

1) The fact that "this is being done" is not equivalen to "this needs 
to be done."  It is equivalent to ~this was an easy shortcut~ as far 
as I can tell.  Product documentation is not the IETFs job.

2) The fact that Open soruce products can not use documentation from 
the IETF doesn't seem unfair to me:
2a) They can choose not to use it, and still produce products
2b) or they can fin d a way to use the documentation that is 
consistent with the source of the documentation.
Note for example that if one was implementing an algorithm from a 
text book, one could normally use the algorithm and code, but not the 
descriptive text.  That doesn't mean that open source is 
disadvantaged in using algorithms from text books.

Yours,
Joel M. Halpern

---

From: Ted Hardie <[email-masked]>
Date: Mon, 12 Jun 2006 11:44:43 -0700

>  modifiable free source code.

This is not a modification.

>  from RFCs to describe SASL and Kerberos protocols in my products.

This is not a modification.

>What is it about these examples that aren't persuasive?

They don't answer the question asked--why does someone need
to *modify* the text in the standard in order to make this use.
I support extracts, as well as the existing rights to reproduce as
a whole and translate. 

I would prefer the original text be included (there are often
terms of art that make things wonky when omitted or changed).
And commentary is always permitted.  Let's say you are building
something related 3258, and you want to talk about zone
file delivery.  If you quote Section 2.2:

   In order to minimize the risk of man-in-the-middle attacks, zone
   files should be delivered to the administrative interface of the
   servers participating in the mesh.  Secure file transfer methods and
   strong authentication should be used for all transfers. 

Then go on to say: "For this package, this means you should use
sftp to the admin interface after having verified the host's fingerprint
out-of-band", you get both the general point across and the finer-grained
"what to do in this instance".

If you modify it to say:

  In order to minimize the risk of man-in-the-middle attacks, zone
   files should be delivered using sftp to the administrative interface
   after having verified the host's fingerprint out of band.

You are substituting your technical judgement about what meets
the requirements for the reader's, without providing them the
context to judge for themselves.  You also run the risk that someone
taking your code and text and building their own implementation
doesn't realize that something other than sftp will work if it meets
the requirements.

>the IETF community should help free software implementations of IETF

And how does requesting the free software folks always include the
text of the original standard harm them?  They can comment on it
in ways that change the implementation e.g.  "RFC 3258, section 2.5 requires
an AS and BGP, but I have implemented this using inter-domain MPLS
instead".  Especially if they can use excerpts freely, how does using
commentary on the text create harm?

					Ted Hardie

---

From: "todd glassey" <[email-masked]>
Date: Mon, 12 Jun 2006 10:09:54 -0700

Simon - you are using the term contribution as though you understood that
gifts of value - especially those of Intellectual Property have to be
accounted for.
----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 12, 2006 4:25 AM
Subject: Re: #1175 Code vs text - second attempt at resolution

> > 1. Where at least the code can be modified and redistributed and the

Don, all,
The redistribution of the code beyond the standard work has nothing to do
wiht the standards process. Are you trying to make any and all IETF
initiatives such so that the world comes to own and have free access to the
IP codified in them and if not what rights can people retain.

> > 2. Where all parts of the work can be modified and redistributed?

Inside the standards process or externally to it?

> > rightholders, save for the preparation of derived standards documents

How about termination of the rights. In all IP transfers the IP transfer can
be rescinded for cause. Fraud in the inducement for instance, or any number
of other actions would invalidate the IETF's stance as the owner of IP...
especially based on the total lack of oversight to deal with the shenaniganz
that happen day in and out in the WG's as peer-approved and peer-controlled
organizations.

---

From: Don Armstrong <[email-masked]>
Date: Mon, 12 Jun 2006 12:42:24 -0700

On Mon, 12 Jun 2006, Ted Hardie wrote:

[,,.]

> text of the original standard harm them?

A request[1] is no problem; the issue comes in when it's actually
required that we only include the original standard. This means that
we can't actually include the original standard at all because it
conflicts with the philosophical underpinnings of Free Software (and
more importantly for those who don't share those views, the licenses
under which large portions of Free Software are released under.)

In this way the Free Software implementations, which are often popular
implementations to fork from and produced derivative works, are able
at most to paraphrase the standards, leading to the undesirable
situtation you mentioned in the elided section.

> They can comment on it in ways that change the implementation e.g.
> "RFC 3258, section 2.5 requires an AS and BGP, but I have
> implemented this using inter-domain MPLS instead".

Quoting like this is always allowed no matter what the licensing says;
I've been hoping to convince people in the IETF to allow the changes
that have been discussed previously so that works that implement the
standards can include the standards themselves.

[And lest someone complains that I'm repeating arguments, I just want
to make clear that the end state for Debian that actually changes
anything in regards to Debian's ability to include RFCs in the main
part of the distribution is pretty well fixed; I'm trying to explain
where that point is, and why comming to that point may be desirable
for other people.]

Don Armstrong

1: Interestingly, if it was worded as a request, the original standard
would almost certainly be included unmodified; it's when the request
becomes a requirement that we can't include it at all.
-- 
Sentenced to two years hard labor (for sodomy), Oscar Wilde stood
handcuffed in driving rain waiting for transport to prison.  "If this
is the way Queen Victoria treats her prisoners," he remarked, "she
doesn't deserve to have any."

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 12 Jun 2006 15:53:39 -0400

It sounds to me more like a Debian problem than an IETF problem.

dbh 

> Sent: Monday, June 12, 2006 3:42 PM
> To: [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Mon, 12 Jun 2006 14:17:00 -0700

>under which large portions of Free Software are released under.)

Can you clarify what you mean by "we only include the original
standard" above?  That is, if you said "we include at least the (salient bits of
the original) standard", do you believe you have the same conflict?

				Ted

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 13 Jun 2006 15:06:15 +0200

> This is not a modification.

To be able to incorporate text into free source code, the license on
the text must be compatible, and permit modifications.

Alternatively, the quote could be licensed under a separate license,
but this would complicate license matters.  Since I see 1) no major
reason to require this complication, and 2) it furthers the IETF's
goal if everyone, including free software, can implement IETF
standards as easy and accurate as possible, I conclude from 1) and 2)
that permitting modifications of IETF standards is a good thing.

Note that this alternative is not possible with RFC 3978 today; RFC
3978 doesn't permit third parties to republish excerpts of RFCs.  So
unless you propose another alternative (there are more alternatives, I
can think of some more myself), changes to the IETF license appear to
be needed anyway.

> This is not a modification.

This is similar as the case above; documentation for free software is
typically also free.

> to *modify* the text in the standard in order to make this use.

I hope the explanation above answers this.

> doesn't realize that something other than sftp will work if it meets

Right.  I agree.

Note that what you describe appear to be legal even without the right
to make modifications -- the second paragraph doesn't look like a
copyright infringement on the first paragraph from the RFC to me.  So
I don't see the direct relevance here.

If the modified text was more similar, and would be a copyright
infringement, I see your point.  However, the IETF can't forbid people
to give poor advice, or give the advice without telling them entire
story.  The IETF can, and I believe this is what it should do, publish
good standards so that everyone who is interested can go to them and
read them and decide what they think for themselves.

> commentary on the text create harm?

They would be forced to use two licenses for the material, one that is
non-free and incompatible with their own license, and manage the
complexities that results from multiple licenses in a product, or
avoid using material from the RFC completely.

This isn't specific for the free software community, companies have
the same problem too.  Compare the Sun getaddrinfo example.  As far as
I can tell, the IETF license didn't permit them to take the
getaddrinfo text from the RFC, modify it and put it into a man page.
So they would have to acquire the same rights that I argue we should
grant to everyone.

Since I believe what Sun did here is a Good Thing, and helped the IETF
community get getaddrinfo deployed faster, I think it should be made
the rule.

(Of course, there are many other examples of the same thing, including
products that I'm directly concerned with.  I'm using the Sun example
to avoid sounding like what I'm talking about only relates to my own
implementations.)

Thanks,
Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 13 Jun 2006 09:34:10 -0400

I believe we have already agreed that we want to permit unmodified extracts.
The fact that the last revision of the rules does seem to 
(unintentionally) prohibit that is not the issue under discussion.

The issue is whether to permit modification of extracts.

I understand that allowing only unmodified extracts would somewhat 
complicate the case where open source software using the common 
licenses wants to use RFC Text as documentation.

[The following is probably repetitive.  I apologies if people feel 
they have read it before.  I am afraid that Simon, I, and others are 
largely going around in circles.]

But, as I said before, providing folks with easily usable 
documentation is not the IETFs goal.  Certainly, high quality 
interoperable implementations of our protocols are the point.  And 
one can argue that good documentation is an important part of good 
implementations.
But for the most part RFCs don't even make good 
documentation.  (There are a few exceptions.)
And if folks are willing to preserve the text unmodified, they are 
welcome to use it anyway.

Yours,
Joel

---

From: Graham Murray <[email-masked]>
Date: Tue, 13 Jun 2006 15:28:19 +0100

> under which large portions of Free Software are released under.)

The extract from the standard text is commentary on the code, not
actual 'source representation of executable code'. It is there purely
as guidance for the person reading or wanting to modify the source
code. So does it have to be included in the actual source code, which
the Free Software licences such as GPL allow to be modified? Could it,
or even should it, not form part of the program/application
documentation which need not be subject to the same 'modification
allowed' conditions. Could the documentation author not include the
provision that the extracts from the standard must be kept verbatim
even if changes to other parts of the documentation are allowed (to
keep it in step with any changes made to the source) and not violate
the conditions of the Free Software licence?