Subject: #1166 Quotations from RFCs and I-Ds - suggested resolution

From: Harald Alvestrand <[email-masked]>
Date: Tue, 25 Apr 2006 13:31:34 +0200

Based on discussion in Dallas, I suggest that we resolve this:

The IPR WG desires that in outgoing rights, the IETF should allow anyone 
to publish excerpts of any length from all parts of published RFCs and 
Internet-drafts, with attribution as appropriate for the medium it is 
used in.

Examples of attributions are "RFC xxxx says", "Excerpt from RFC xxxx by 
Joe Bloggs" et cetera.

Note that this resolution of this issue does not touch the issue of 
modified versions at all.

Comments?

                     Harald

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 25 Apr 2006 07:51:03 -0500

Hi, Harald,

This is certainly the way I thought it worked, and the way I thought people 
who have been around longer thought it worked.

Thanks,

Spencer

> Internet-drafts, with attribution as appropriate for the medium it is used 
> in.
>

---

From: "todd glassey" <[email-masked]>
Date: Tue, 25 Apr 2006 06:36:28 -0700

Harald - If the totality of the scope of the Outgoing Rights are as you say,
that of republication and not "for any and all uses" as some of the previous
documents were slammed through under, then this would be acceptable,
assuming there is also somewhere something that says (1) what the IETF is
going to do with the IP, and (2) what happens to the IP and its ownership if
the IETF fails to keep its commitment(s) for any IP released into its care.

Todd

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Apr 2006 16:30:50 +0200

Harald Alvestrand <[email-masked]> writes:

> The IPR WG desires that in outgoing rights, the IETF should allow
> anyone to publish excerpts of any length from all parts of published
> RFCs and Internet-drafts, with attribution as appropriate for the
> medium it is used in.
>
> Examples of attributions are "RFC xxxx says", "Excerpt from RFC xxxx
> by Joe Bloggs" et cetera.
>

It seems fine, but lacking in detail.

I wish that we can address typographical and editorial changes here,
either be permitting them explicitly or to disallow them explicitly.

Like Spencer Dawkin says, I don't think there is any disagreement over
your simple permission grant above.  However the problem is in the
interpretation of what it means, so I believe it should not be
resolved with too brief text, or it will come up again later on.

This is also a "devil in the detail" that is causing problems in
practice, because it is unclear whether verbatim quoting rights give
me the right to make minor changes that may amount to a copyright
infringement if it is done enough times in a product.

Do you think that typographical/editorial modifications should be
permitted or not?

Some proposed paths to take:

1)

I'd argue to grant rights to re-format the text, in order to e.g.:

* remove page breaks

* re-flow the text to fit a particular column width

* add text to fit a particular circumstance.  For example, it is often
  useful to quote an RFC in a C++ source comment, which for longer
  quotes typically require that you prefix each line with '//'.

and to make editorial changes, in order to e.g.:

* fix typos

* improve ascii art in a real book

* in a small excerpt for e.g. a function API, incorporate changes from
  the RFC errate.  The reason is that it does not make sense to say,
  in the man page for foo():

    RFC 4711 says: The iteration count must be 0-256 exclusive.  An
    errata to RFC 4711 says: Change 0-256 to 0-256 inclusive.

  Instead, I think it should be permitted to say:

    RFC 4711 (with errata) says: The iteration count must be 0-256
    inclusive.

  Admittedly, this small example is short enough to not be a copyright
  infringement, but in the real world the changes may well be too
  large.

The text to grant these rights could be kept abstract and does not
have to discuss details.  One suggestion to start discussions:

"Modifications that are of typographical or editorial nature are
permitted.

"Examples of typographical changes include removal of page breaks,
re-flowing the text to fit a particular column width, and adding '//',
/* or */ markers when the excerpt is included in a source code.
Examples of editorial changes include fixing typos, improving ASCII
art, and applying updates from the RFC errata."

2)

Explicitly disallow this.  One suggestion to start discussions:

"Typographical and editorial changes are not permitted, only verbatim
extracts are allowed."

"Examples of typographical changes include removal of page breaks,
re-flowing the text to fit a particular column width, and adding '//',
/* or */ markers when the excerpt is included in a source code.
Examples of editorial changes include fixing typos, improving ASCII
art, and applying updates from the RFC errata."

3)

Something completely different.

Thanks,
Simon

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 25 Apr 2006 09:46:56 -0500

(oops!) Sorry, but Simon just triggered another devilish detail. Where do we 
do the corresponding punt for translated RFCs?

This would be (3) "something completely different", I guess.

Thanks,

Spencer

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 25 Apr 2006 19:03:44 +0200

>Do you think that typographical/editorial modifications should be
I think that is best addressed as a separate issue - #1169 has the title 
"Modified excerpts".

For now, I'd be happy to resolve this issue by saying "verbatim excerpts 
ARE permitted", and we'll keep the open issue on how much change we want 
to permit.

I've added your list of subissues to issue #1169 - it's a good list.

                             Harald

---

From: Ted Hardie <[email-masked]>
Date: Tue, 25 Apr 2006 10:30:40 -0700

>It seems fine, but lacking in detail.

Hi Simon,
	My basic take is that the issues you raise below are real,
but should be distinguished from this issue.  While I believe "re-format" is
inherently part of the "excerpts of any length" (because I can
concatentate excerpts from pages to get rid of line breaks, etc.),
I think it could be and perhaps should be explicitly included in the
resolution  to this issue.
	But let's take anything that says "fix", "improve", or "incorporate"
to a separate issue.  Those aren't nearly as clean, and before wrestling
with the devil in those details, I really want to say that we've agreed on
*something*.
			best regards,
				Ted Hardie

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Apr 2006 22:22:58 +0200

> concatentate excerpts from pages to get rid of line breaks, etc.),

There is a limit to that kind of technical obstruction of the letters
of the license allow though; for example, you could hardly excerpt
parts of sentences and concatenate them together and claim it is a
verbatim excerpt from the RFC.

When deciding whether a particular usage is consistent with the spirit
of a license, additional discussions and examples, like the ones I
provided, are useful to indicate the intention behind the license.

I tried to explore where we want that limit to be.

> with the devil in those details, I really want to say that we've agreed on

Right.  Moving my concern to #1169 seems fine.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Apr 2006 22:53:42 +0200

> I've added your list of subissues to issue #1169 - it's a good list.

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

The #1169 text now wholly mis-represent what I argue for, because what
you quoted me saying there was something I argued for in another
context...

In #1169, I would argue for granting rights to excerpts (and entire
documents) under a license that permit incorporation of the excerpt in
BSD and GPL licensed material.

Permitting only editorial and typographical changes is incompatible
with BSD/GPL.

Issue #1169 is one where I have given multiple examples for, e.g., the
getaddrinfo man page issue, and the GSS-API function description
issue.  It is one of the more important issues, and I don't want my
position mis-understood.

The examples I gave for #1166 were things to ponder whether they are
to be permitted by "verbatim copying" or not.

After re-reading #1169, I think my list doesn't make sense there, and
it mis-represent what I argue for, so please remove it, or at least
modify the surrounding text to make it clear that I don't argue for
those things in that context.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Apr 2006 23:17:34 +0200

Harald Alvestrand <[email-masked]> writes:

> I think that is best addressed as a separate issue - #1169 has the
> title "Modified excerpts".

The #1166 issue text is:

  The trust should permit quotations from RFCs and I-Ds, with
  permissions at least as liberal as US "fair use", and easy to figure
  out

I believe US "fair use" permit certain modifications, such as
re-formatting the excerpt to fit a specific context.  See:

http://www.copyright.gov/title17/92chap1.html#107

We've had no discussion on whether we want to permit more than what
was suggested as the minimum level, so it seems premature to close
this.

> For now, I'd be happy to resolve this issue by saying "verbatim
> excerpts ARE permitted", and we'll keep the open issue on how much
> change we want to permit.

I think deciding how much changes we want to permit for excerpts IS
the #1166 issue.

Sorry for not spotting this angle earlier.

Thanks,
Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 25 Apr 2006 23:35:30 +0200

Unfortunately RT doesn't permit removing comments (not in any method 
I've found, at least).

And I still think the issues you mentioned are worth considering in that 
context, even though they don't represent your main position.

Can you formulate what you want to have recorded? I can add that.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Apr 2006 23:39:23 +0200

Harald Alvestrand <[email-masked]> writes:

> And I still think the issues you mentioned are worth considering in
> that context, even though they don't represent your main position.
>

Quoting this from my last e-mail would capture the gist of it:

 In #1169, I would argue for granting rights to excerpts under a
 license that permit incorporation of the excerpt in BSD and GPL
 licensed material.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 25 Apr 2006 23:48:16 +0200

>  Permitting only editorial and typographical changes is incompatible
Added.

---

From: John C Klensin <[email-masked]>
Date: Tue, 25 Apr 2006 18:39:43 -0400

--On Tuesday, 25 April, 2006 07:51 -0500 Spencer Dawkins
<[email-masked]> wrote:

>> The IPR WG desires that in outgoing rights, the IETF should
>> allow anyone  to publish excerpts of any length from all
>> parts of published RFCs and  Internet-drafts, with
>> attribution as appropriate for the medium it is used  in.

> Hi, Harald,
> 
> This is certainly the way I thought it worked, and the way I
> thought people who have been around longer thought it worked.

Spencer,

I'm prepared to lose this one, although, if I do, I'm going to
press strongly for copyright transfers to the IETF so the policy
can be administered ("why that is relevant" is probably a
different thread, but hinges on when an excerpt isn't "just" an
excerpt).  However, as someone who has been around for a while,
this is not how I thought it worked... ever.  

The way I thought (and think) it worked/works is that one may
duplicate, distribute, reproduce and translate complete
documents under permission granted by the authors to everyone.
Any other use of the text itself, other than by the IETF as part
of the standards process or by individuals contributing to the
standards process, has formally required negotiation with the
authors.

best,
   john

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Apr 2006 13:49:43 +0200

> standards process, has formally required negotiation with the

Beyond "fair use" as interpreted in the jurisdiction concerned,
presumably.

    Brian

---

From: John C Klensin <[email-masked]>
Date: Thu, 27 Apr 2006 15:20:14 -0400

--On Thursday, 27 April, 2006 13:49 +0200 Brian E Carpenter
<[email-masked]> wrote:

>> Any other use of the text itself, other than by the IETF as
>> part of the standards process or by individuals contributing
>> to the standards process, has formally required negotiation
>> with the authors.
> 

Brian,

That question illustrates one reason this WG's discussions get
so frustrating (not your fault, and no frustration with you
personally over this).

Once upon a time, we didn't care much about these issues.  Any
excerpt, quotation, or republication that was carried out with
good intentions toward the network and without blatant profit
motives in the use of the text would simply never be challenged
by the authors (or anyone else), regardless of what "rights"
those authors had.  People who wanted to republish RFCs did so
in their entirety, as much to avoid leaving things out that
someone else might think important as to keep nervous publishers
happy.  

Things have evolved to the point that we are feeling a need to
pin down every possible case and detail.  The concept of
"documentation" has evolved from written, explanatory, prose to
help files and quick excerpts of argument definitions on which
one spends as little time as possible.   There are two problems
with these trends with regard to fair use and a whole series of
edge cases:

	(1) "Fair use", as I have understood it, isn't a rule,
	but, with the exception of a small number of enumerated
	cases, a principle.  If Alice does something with Bob's
	document, she is relying on an assumption that Bob will
	consider the use fair.  If Bob doesn't, then he goes off
	and persuades a judge to decide.  For most "fair use"
	cases, Alice has no guarantee that the use will be
	considered fair by that hypothetical judge until there
	is a decision.   So, for the purpose of Alice knowing
	what she can safely do, "fair use" is really not helpful
	(again, except for a series of very narrowly-defined
	situations).
	
	(2) Identification and solutions to all of the edge
	cases.  The thing this discussion over the last months
	or years has convinced me of is it that we can't get
	this right by anticipating all of the cases.  I think we
	have proven that we cannot identify all cases.  If,
	somehow, we can, I don't think we can agree on what
	should be done about each of them.  

So I'd like to suggest that we stop this and look at it from a
different point of view.  Our principles should be that (i) the
IETF gets the rights that it needs to develop (and revise and
update) standards.  I don't think there has every been any
disagreement about that one.  And (ii) if there are any rights
at all that we care to protect in RFC text, someone has to have
the authority and responsibility to enforce those rights.   That
"someone" has to be unambiguous, otherwise the ability to
enforce is likely to be so badly compromised as to be useless.
Most of these discussions seem to be about what the rights are
that we need to protect, about what permissions might be given
in support of (or without harming) those rights, etc.   We seem
to have lost sight of who might actually enforce any rules that
we make, and seem to be creating a situation in which no one
would have the will and ability to do so.

So I'd like to suggest that we pull back from this effort and
look at thing from the standpoint of two alternatives, again
given that IETF gets the rights it needs for
standards-development.

Option 1: We leave these questions with the authors, as they
have been forever.  We encourage authors to make explicit grants
of rights beyond what the IETF needs if they want to, but use
mechanisms more like our IPR (patent, etc.) rights provisions to
get those grants of rights from authors -- grants of rights to
those who would use the text other than for distribution or
translation in toto and for IETF-specific purposes.

Option 2: We ask authors to transfer copyright to the IETF
(IASA, Trust, etc.), reserving only their own rights (and those
of their companies where applicable) to excerpt, re-use, etc.
The efforts of this WG get diverted into formulation of
guidelines for the IAOC to use and apply to third-party
requests, but we drop the notion of trying to turn such guidance
into hard rules.  In return for the transfer of copyright, the
IASA agrees to defend that copyright as needed and, in
particular, to challenge uses that are considered inappropriate
under whatever guidelines exist at that point.

Otherwise, these discussions will just go on for more months and
will then produce a new document, and new boilerplate, etc.,
that we will discover has missed a case or two and needs to be
revised yet again.   I think it needs to stop.

regards,
      john

---

From: "todd glassey" <[email-masked]>
Date: Thu, 27 Apr 2006 13:16:44 -0700

John - forgive my devil's advocate response - but you are wrong about a
number of these points you made although the underlying idea of backing off
is a good one.  More inline below.

Todd
----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: <>; "Spencer Dawkins" <[email-masked]>
Sent: Thursday, April 27, 2006 12:20 PM
Subject: Fair use and case analysis (was: Re: #1166 Quotations from RFCs and
I-Ds - suggested resolution)

> > Beyond "fair use" as interpreted in the jurisdiction concerned,

OK So Copyrights control copying IP's based on:

Reproduction Right. The reproduction right is the right to copy, duplicate,
transcribe, or imitate the work in fixed form.
Modification Right. The modification right (also known as the derivative
works right) is the right to modify the work to create a new work. A new
work that is based on a preexisting work is known as a "derivative work."

Distribution Right. The distribution right is the right to distribute copies
of the work to the public by sale, rental, lease, or lending.

Public Performance Right. The public performance right is the right to
recite, play, dance, act, or show the work at public place or to transmit it
to the public. In the case of a motion picture or other audiovisual work,
showing the work's images in sequence is considered "performance." Some
types of works, such as sound recordings, do not have a public performance
right.

Public Display Right. The public display right is the right to show a copy
of the work directly or by means of a film, slide, or television image at a
public place or to transmit it to the public. In the case of a motion
picture or other audiovisual work, showing the work's images out of sequence
is considered "display."

> Once upon a time, we didn't care much about these issues.

I.e. The IETF nor its members cared much about whether their actions were
illegal or not - they just did them in the interest of the
One-World-Internet and in being the formal Name attached to 'that
particular' technology which paints the members of the IETF as criminals.

Is this really what you wanted to say? That the IETF's actions are based in
criminal copyright violations that stem back to the dawn of the IETF itself?

> Any
> those authors had.

So then you are confirming then by this public statement that the IETF broke
the law, right?

>  People who wanted to republish RFCs did so

And for which its VERY important to notice that the IETF did nothing -
meaning it abandoned its control of those IP's and breached the contract it
had with those IP's submitters, unless you can come up with some other set
of words to describe the IETF's blatant failure to protect its IP.

> pin down every possible case and detail.

You mean so the IETF is not sued over these issues right?

> The concept of
> one spends as little time as possible.

Actually the copyrightable media includes programs and any number of other
types of data including binary footprints as well. Multimedia took care of
that for us.

>There are two problems

Yes actually it is under Section 107 of the Copyright Act itself - here is
the hyperlink to it in the US Governments website per Fair Use....
http://www.copyright.gov/fls/fl102.html BUT  John - we went over all of this
several months ago the last time this argument was raised.

> consider the use fair.

Depends on how Alice got the work and what her relation  to Bob is.

> If Bob doesn't, then he goes off
> and persuades a judge to decide.

or files a criminal complaint with the FBI against ALICE for Infringement
and Fraud By Wire which in the IETF's Case most all infringements would take
the form of IMHO...

> For most "fair use"
> is a decision.

Uh, that's also untrue John...

> So, for the purpose of Alice knowing

You need to read the Fair Use statutes and the Research Exemption Statutes.

> should be done about each of them.

No, you are dead wrong here sir, the Cases are simple:

    1)    The media was submitted to the IETF for vetting within the
Standards Process and is wholly owned by the submitter. The submission
contains no other CR or other IP protections and so this one person may
convey the rights to republish the work to the IETF.

    2)    The media/work-product is submitted to the IETF for vetting within
the Standards Process and is not owned in any form by the submitter - who is
submitting "their words about the IP in question" to the IETF - this DOES
NOT MEAN THAT THE CORE IP IS THEN SUBMITTED TO THE IETF, but rather the
words of the person submitting that work-product.

This is ***the*** key failing in the IETF's current processes since they
take that once this submission is done, that the #2 Scenario gives the IETF
the same rights to the IP as that of the conveyance model of #1 does AND IT
DOESN'T!

This same rule also means that the IETF may not stop two submitters from
submitting the exact same words about an IP only one of them doesn't own the
IP, and one does...

BTW - Are you seeing the reality of the problem yet?

    3)    The media/work-product which is submitted to the IETF is owned by
a number of people including those participating in the IETF's WG's
themselves. So any issues therein are likely covered by the Research
Exclusion in the Copyright Code's Fair Use Doctrine.

However, again let me state about the conveyance of IP issues, that UNLESS
THAT WG has on file a release from that party's Sponsor in some form, they
cannot claim any ownership of any work that individual does, whether that
individual knows IP and Copyright law or not.

    4)    And then we get to the issues of how to include external IP which
has protections from other sources in IETF Work-Product because the use of
these materials may meet the Research Exceptions for the IETF but clearly
wouldn't for any end-users. Also these other IP owners may have no idea that
the IETF is republishing their work, whether they (those other IP owners)
may or may not want to concede or convey their copyrights to the IETF
itself. This has to be addressed by some form of "The IETF is using your IP,
is there a problem here?"...

> update) standards.

YES YES YES!

>  I don't think there has every been any
> disagreement about that one.

Sure there has - and the disagreement is what the IETF needs to have as its
rights to do that task...

> And (ii) if there are any rights
> the authority and responsibility to enforce those rights.

The IETF formally claiming rights to these documents has already done this.
The IETF's failure to do this to date has put the IETF in a position where
when it gets to court the first time (and its really only a matter of time
IMHO),  that the IETF may formally get told that it has abandoned all of the
IP it claimed sole ownership of including its templates.

> That

That someone is the IETF and its parent ISOC - what is ambiguous about that?
except possibly who is going to write the check.

> would have the will and ability to do so.

i.e. meaning that the IETF through the actions of the Editor's would tell
this WG to get stuffed...

> given that IETF gets the rights it needs for

I approve of this, BTW...

> translation in toto and for IETF-specific purposes.

I.e. to take from those people trying to generate reliable standards, their
ownership of that work product.

> of their companies where applicable) to excerpt, re-use, etc.

i.e. to give that IP to the IETF free and clear - which has an issue of
valuation to it something this IETF isnt competent to address.

> into hard rules.

OK

> In return for the transfer of copyright, the

Roll another one - Do you know what a six month stint in the Federal Court
would cost over a CR infringement case? The IETF has no money to pay for
this type of defense nor has it ever defended anything it printed that the
copyright was violated on... so again - since it never defended those
materials before - it cant really start now eh?

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 28 Apr 2006 09:38:41 +0200

John,

not disagreeing with the need to step back, but I think I'm disagreeing 
with what the direction of "back" is....

> the authority and responsibility to enforce those rights.
I came at this discussion from a different angle.....

(1) the IETF needs to be reasonably sure that nobody will ever be able 
to use copyright successfully to prevent the IETF from creating the 
standards it wants to create, based on the input that it gets.

(2) The implementors who need to use IETF standards and other documents 
need to be reasonably sure that if they do [things in the set of X], 
nobody will ever try to use copyright in the IETF documents to prevent 
them from doing that.

If you think that this is all about protecting the participant, and not 
caring at all about protecting the rights holder, you have exactly 
captured my personal viewpoint... I know that there are other viewpoints 
in the WG, and you have some of them....

I believe the group currently has two issues on the table:

- What are the boundaries of the [things in the set of X]?
- What are the legal mechanisms that we should use to ensure that things 
are the way we want them to be?

I believe what people do with documents will fall into three classes 
from a "moral" standpoint, and 3 classes from a "legal" standpoint, 
which are NOT consistent:

Morally:

A - OK
B - Reprehensible (fake RFCs, patenting other people's inventions, 
stealing ideas without attribution)
C - Grey area

Legally:

1 - OK
2 - Any reasonable judge would find them illegal
3 - Gray zone, it will depend on the details of the case and the force 
with which arguments are applied.

I believe that a successful outcome of the WG will be one where a 
reasonable subset of things in A are clearly in group 1.
I don't believe that we can put group B into group 2 - the tools and the 
problem don't fit cleanly together.

The thing that started up this round was the observation that there are 
quite a few things that people think are in moral group A (OK to do) 
that seem to be in legal group 3 (we're not sure what would happen), 
unless the people wanting to do them go around to everyone who could be 
considered to have some copyright claim on parts of the RFC (or their 
heirs, assignees, employers under work-for-hire, or....) and ask their 
permission.
And that seems to cause pain in various quarters.

> would have the will and ability to do so.
I have a hard time seeing the IETF in that position.........
> translation in toto and for IETF-specific purposes.
That is no change from the present - and solves none of the problems....
> under whatever guidelines exist at that point.
Which has its own set of problems. I still don't see that the absence of 
a viable third position (more rights licensed with permission to 
sublicense, Trust adminsters sublicensing) has been demonstrated.

I think we've already dropped the notion of this WG making hard rules 
(despite people repeatedly bringing up the "enforcement" issue).
The issue we have been discussing wrt "outgoing rights" is STILL that we 
don't know what that guideline should be.
> revised yet again.   I think it needs to stop.
Yep.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 Apr 2006 10:54:15 +0200

> revised yet again.   I think it needs to stop.

I agree revising the license over and over again is bad.

A simpler alternative to your approach is to ask IETF contributors to
release their entire work under a permissive license, such as the
revised BSD license or the RFC 3492 license.  This is what I've been
arguing for all along.

Pro:

* No copyright transfer is necessary.

* All practical use is permitted, today and in the future.  We don't
  need to revise the license when we find a new corner case.  The
  revised BSD license has proven useful for many years for many
  purposes, and as far as I know, no corner cases are known.  It is
  also compatible with all even marginally popular license that I know
  of.  Even though RFC 3492 is more recent, I think it is good enough.

Con:

* Some people are afraid of fake RFCs.  I don't think this is a good
  enough argument, the costs of copyright transfers or regular updates
  of the IETF license are, I believe, larger than the risk of fake
  RFCs.

* Some RFCs can't be released with this license, for example things
  received from other SDO's.  I believe this is a marginal example,
  enough to argue that they can be handled as an exception to the
  rule.

The RFC 3492 license is:

   Regarding this entire document or any portion of it (including the
   pseudocode and C code), the author makes no guarantees and is not
   responsible for any damage resulting from its use.  The author grants
   irrevocable permission to anyone to use, modify, and distribute it in
   any way that does not diminish the rights of anyone else to use,
   modify, and distribute it, provided that redistributed derivative
   works do not contain misleading author or version information.
   Derivative works need not be licensed under similar terms.

The revised BSD license is:

   Copyright (c) <YEAR>, <OWNER>
   All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions
   are met:

    * Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.

    * Redistributions in binary form must reproduce the above
      copyright notice, this list of conditions and the following
      disclaimer in the documentation and/or other materials provided
      with the distribution.

    * Neither the name of the <ORGANIZATION> nor the names of its
      contributors may be used to endorse or promote products derived
      from this software without specific prior written permission.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
   FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
   COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
   INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
   (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
   SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
   HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
   STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
   ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
   OF THE POSSIBILITY OF SUCH DAMAGE.

Thanks,
Simon

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Apr 2006 10:58:38 -0400

--On Friday, 28 April, 2006 09:38 +0200 Harald Alvestrand
<[email-masked]> wrote:

> John,
> 
> not disagreeing with the need to step back, but I think I'm
> disagreeing with what the direction of "back" is....
>... 
> If you think that this is all about protecting the
> participant, and not caring at all about protecting the rights
> holder, you have exactly captured my personal viewpoint... I
> know that there are other viewpoints in the WG, and you have
> some of them....

If one cares only about protecting the participant, and not
about the rights holder, you are in a bit of a contradiction,
because the participant often _is_ the rights-holder.

Ignoring that, if you care only about protecting the
participant, then Simon is correct and what one needs is a
BSD-like license that gives any participant or other
recipient/user of an RFC the right to do anything they like with
it.

Anything one does that try to be more finely-tuned involves
trying to protect the rights of rights-holders.  The
rights-holders in this sense include the IETF and its
presumptive "right" to not be misquoted, to not have the
contents of its standards misrepresented, and to not have its
work cited without attribution.  All of those are bound to the
notion of rights-holder --i.e., someone having rights to
restrict document usage that they would like protected-- and not
to participants or others wanting to use those documents for
their own purposes.

> - What are the legal mechanisms that we should use to ensure
> that things are the way we want them to be?
> 
> I believe what people do with documents will fall into three
> classes from a "moral" standpoint, and 3 classes from a
> "legal" standpoint, which are NOT consistent:
> 
> Morally:
> 
> A - OK
> B - Reprehensible (fake RFCs, patenting other people's
> inventions, stealing ideas without attribution)
> C - Grey area
> 
> Legally:
> 
> 1 - OK
> 3 - Gray zone, it will depend on the details of the case and
> the force with which arguments are applied.
> 
> I believe that a successful outcome of the WG will be one
> where a reasonable subset of things in A are clearly in group
> 1.

And I think the discussion we are having is likely to create
sufficient hair-splitting to move even some things that we might
now consider to clearly fall into the "moral A, legal 1" case to
accidentally fall into "legal 3".  That is the worst possible
outcome, both from the standpoint of document handling and from
the standpoint of our needing to continually re-tune things and,
also continually, have to deal with the problem of documents
produced at different points in time, under different rules.

So, without disagreeing with your categories, I believe that the
character of the discussions has suggested that we can't do
things this way and that there are only three rational
possibilities:

	(x) We stick with where we are today (or were before we
	started trying to find-tune this), i.e., the author
	grants unlimited rights to use the material to the IETF
	and grants everyone else rights to copy in toto.  If
	necessary, we figure out a way to identify code segments
	and similar materials that must be incorporated into
	implementations to build conforming implementations and
	construct a mechanism to be sure that use of them is
	unambiguously permitted.    If that is necessary, I'd
	recommend a small committee to work with the lawyers to
	produce a specific proposal that meets those needs, not
	an attempt to engineer that result by a large committee
	of amateurs.
	
	(y) We simply release everything on the grounds that
	this is hopeless and we don't care about rights-holders
	and/or that trying to use copyright to protect against
	the things in group B is hopeless (I think we agree on
	that hopelessness).  See above.
	
	(z) We either transfer copyright, at an appropriate
	point, to the IETF (or assure that the IETF owns the
	copyrights in the first place) or transfer _unlimited_
	rights to the IETF to manage permissions (see caveat
	below).  Then "the IETF" sets blanket policies that
	cover as much of your "A" group as possible and develops
	ways to handle group "B".   If they get it wrong, they
	tune as needed, without having to go back to authors, or
	the great-grandchild of this WG, for specific
	authorization.

There is also a possibility that I do not consider rational:

	(w) We try to define another specific set of rules.
	Either because we discover a case we don't like, or
	because circumstances change and consensus with it, or
	because whatever is written and approved turns out to
	not get enough of moral group (A) into legal group (1),
	we have to revisit the topic, with a WG, regularly.  And
	each time we do that, we have to address the question of
	what to do about documents released before _that_
	incarnation of the WG did its work.

Where I think we get into trouble is defining a set of rules
that will last for all time or, given recent experience, even
more than six months or a year.  If we conclude that we can't
develop rules that accurately reflect a stable consensus, then
either we pick option (y) or we need to decide whether the
tuning process requires the authors/non-IETF rights-holders or
whether the IETF wants to be able to tune via an administrative
process.

> The thing that started up this round was the observation that
> there are quite a few things that people think are in moral
> group A (OK to do) that seem to be in legal group 3 (we're not
> sure what would happen), unless the people wanting to do them
> go around to everyone who could be considered to have some
> copyright claim on parts of the RFC (or their heirs,
> assignees, employers under work-for-hire, or....) and ask
> their permission.

That is an argument against option (x).  It is not an argument
against either (y) or (z).  I think the "observation" you cite
is more proof that (w) is impractical and probably irrational.
And it certainly does not demonstrate that we can write a set of
rules this time that get things right without, again, ending up
confronted with one of those three options.

Yet we seen to be on a path to yet another incarnation of option
(w) and it is that, and only that, which I'm arguing we should
avoid.

       john

---

From: Ted Hardie <[email-masked]>
Date: Fri, 28 Apr 2006 12:34:24 -0700

>  of the IETF license are, I believe, larger than the risk of fake

This is only part of the risk.  If we release specs into the wild with
this license, there is not just risk that someone fakes RFC XXXX,
there is a much larger risk that someone takes the text and uses
it as the basis for a specification that does not interoperate
with the IETF spec.  It moves us to a model, in other words, where
forking is a generally permitted result.  Getting to consensus
is hard work, and forking is relatively easy (especially if you start
from a finished work).  I believe that this will result in a situation
in which forking is a common result.

We have seen this happen in many ways over the past five years,
especially in cases in which other SDOs wish to take IETF protocols
and tweak them slightly to fit architectures which preserve
specific business models.  After those tweaks, traffic flows commonly
have to go into back-to-back user agents to transition between
the Internet protocol and the tweaked protocol.  This introduces
fragility, delay, and points of control.  Avoiding those situations by
focusing on interoperability has taken hard work, but there have been
some successes.  I fear that this license would make it harder to
succeed at those same efforts in the future.

If you want a simpler idea, it is this:  The IETF should not be working on
*anything* for which Internet-scale interoperability is not a key goal.
For those for which that is a goal, real standards (and avoidance of forking)
is key.  Anything which can survive the kind of forking I predicted above probably
shouldn't be done here anyway.  Put the spec on a web page, or code on
sourceforge, or take it to any number of other fora; the IETF does not have or
need any monopoly on good code or specs.    But it does need a clear focus on
interoperability.  I wish I was certain it still had it.

				regards,	
					Ted Hardie

PS.  I am not speaking for anyone else in the text above, including but not limited to
other owners of dachshunds,  the IESG, the State of California or its residents,
or my employer.

---

From: Don Armstrong <[email-masked]>
Date: Fri, 28 Apr 2006 13:12:20 -0700

On Fri, 28 Apr 2006, Ted Hardie wrote:
> >  enough argument, the costs of copyright transfers or regular
> >  updates of the IETF license are, I believe, larger than the risk
> >  of fake RFCs.
> 
> This is only part of the risk. If we release specs into the wild
> with this license, there is not just risk that someone fakes RFC
> XXXX, there is a much larger risk that someone takes the text and
> uses it as the basis for a specification that does not interoperate
> with the IETF spec.

Unfortunatly, there's no way to prevent that now. All that can be done
is to raise the barrier to breaking interoperability by making it more
difficult to discuss the specification. In the current setup, people
will just take the specification, decide what they want to change,
change it, and then release a reference implementation that embraces
and extends the specification in such a way as to make it
uninteroperable if that's what they want. Because they never release
the modified specification (they don't want interoperability, after
all, so releasing it is not something that they would do even if they
could) or do any of the other things reserved to the copyright holder,
the license that the RFC is under is merely academic.

> After those tweaks, traffic flows commonly have to go into
> back-to-back user agents to transition between the Internet protocol
> and the tweaked protocol. This introduces fragility, delay, and
> points of control.

This is definetly bad, but I don't see how we can prevent this by
licensing. If people don't want interoperability, they're going to
break interoperability regardless of how the IETF licenses RFCs. [One
could even argue that making the IETF specifications more difficult to
disseminate and include in technical documentation would make it more
likely to break interoperability.]

That said, I don't know what to do about people who accidentally break
interoperability... but presuming we require that people indicate that
the RFC has been modified and removes any of the "This is an Official
IETF RFC" boilerplate and publicize the fact that only valid IETF RFCs
have the official boilerplate, I don't really have any sympathy for
those who don't notice that they're following a modified RFC.[1]

Don Armstrong

1: Hell, I have little sympathy for those who don't bother to check
that the RFC that they're reading is bit for bit identical with the
published RFC distributed by the IETF.
-- 
Do not handicap your children by making their lives easy.
 -- Robert Heinlein _Time Enough For Love_ p251

http://www.donarmstrong.com              http://rzlab.ucr.edu

---

From: "todd glassey" <[email-masked]>
Date: Fri, 28 Apr 2006 13:30:38 -0700

I disagree that Fake RFC's are an issue to the extent that Ted is painting
them as, my feeling is that this community is way to small and well
connected for a fake RFC to exist for long and too vitriolic to allow anyone
to get away with that type of offense against the IETF.

And my feeling is that if there was a real issue with Forking as Ted raised,
it would be easy to stop that by just going back to the ideas of the early
IETF... You simply dont allow people the license to produce things that by
their very nature do not interoperate with IETF standards... and for RFC's
you do this by making it a no-no to use a RFC as anything other than a
"Request For Comments". To do this the license would specify the specific
uses that the document in question could be used for rather than the way it
is today.

This limiting of use  is easily done with a simple use license that says
that the only allowable use for a RFC is for the solicitation of comments in
an IETF Standards Initiative and that any deriviatives must either insure
interoperability as part of advancing the standard or that a waiver is
issued for the interoperaability requirement by the WG doing the vetting of
the IP, and that as part of that if any protocol is implemented as part of
qualifying this IETF Initiative that it MUST meet the interoperability
standards that are the foundation of the IETF's processes.

Likewise my feeling is that the same is true for Don's response as well, if
the license on the RFC is restricted to being used specifically in the
advancement of the IETF's Standards Process rather than "anything and
everything anyone wants" then this will become a non-issue.

---

However... there is also another concern in the breadth of the license
statements, and it is particular to what rights the IETF is giving away to
people that allow them to build IP of their own based on IETF publications.
Remember that the previous convo's were all about "republishing to foster or
advance a standards initiative", and outside of that there is/are no
right(s) on the table that allow derivative implementation of the physical
IP as a stack or protocol per se.

Todd Glassey

----- Original Message ----- 
From: "Ted Hardie" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>; "John C Klensin"
<[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>; <[email-masked]>; "Spencer
Dawkins" <[email-masked]>
Sent: Friday, April 28, 2006 12:34 PM
Subject: Re: A simpler idea (was: Re: Fair use and case analysis)