Subject: Re: draft-ietf-ipr-rules-update-00.txt

From: [email-masked] (Scott Bradner)
Date: Wed, 5 Oct 2005 08:33:21 -0400 (EDT)

Simon sez in another message

  now I'm in the position where I find no
  legal text whatsoever from the IETF that permit me to use the RFCs in
  my products.  The current permissions only grant rights to the
  IETF/ISOC; not to me nor my customers.

that is a misunderstanding
1/ 3rd parties may republish RFCs any time they want
2/ 3rd parties may extract RFCs for inclusion in documentation, help 
   pages etc

but this ID (and current rules) do not say that someone can take a RFC, 
modify it and republish it unless its done within the IETF standards process
or unless the IETF has given speciifc permission to do so
(note, as was mentioned during the last discussio, it may not be
a bright line between publishing extracts linked together by new text
and publishing a modified RFC)

Pekka sez:
  In any case, the suggested revised section 3.3 (a) (C) does not
  specify who makes that case-by-case judgment/consensus call. That seems
  like an important detail which need to be specified.

I thought about that - I think its the IESG but can see cases where the
IAB might be the right body so wanted to leave it open until I 
saw some consensus - opinions?

Scott

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

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Oct 2005 17:28:40 +0200

> 2/ 3rd parties may extract RFCs for inclusion in documentation, help 

Again, please quote where BCP 78 give me these rights.  I believe it
does not give me these rights.

> and publishing a modified RFC)

True.  And free software typically need the rights to be able to
modify the included documentation and help pages.  That is why the
rights to be able to that should be granted to everyone by the IETF.

Thanks,
Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 05 Oct 2005 21:22:05 -0400

Why?
I realize that the normal rights granted for free software give anyone the 
right to do anything with the software.
But there is no reason one can not write free software where specific parts 
have exceptions.
So why do you "need" this right?
Yours,
Joel

---

From: Pekka Savola <[email-masked]>
Date: Thu, 6 Oct 2005 10:42:52 +0300 (EEST)

> saw some consensus - opinions?

Just a thought: is the IETF administrative director an option?  As 
(s)he has considerable oversight, I guess the decision would get 
reviewed in the appropriate places as need be.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 06 Oct 2005 12:52:57 +0200

> So why do you "need" this right?

In general, free software that contain a non-free part is no longer
free software.  But that is a play of words, so let's focus on what my
day-to-day needs are:

I need to be able to rewrite paragraphs from the RFC to better fit my
manual, or to fix typos, or to fix real bugs in the RFC.  I need to
incorporate part of the RFC in online help, source code comments, etc,
and I want to be able to modify those parts of someone reports a
problem with that part.

Consider if we find a security problem with the large tables that is
part of Internationalized Domain Names (see RFC 3454), then to fix
that security problem I need the right to modify the tables imported
from the RFC and release a new version.  That release should come with
full documentation, and the best way to achieve full documentation
would be to make a copy of the old RFC and modify the faulty lines,
while at the same time making it clear that I'm not implementing the
IETF RFC.  Because my implementation of IDNA is part of libc in most
Linux distributions, the impact of any security bug would be major.  A
security fix for my library cannot wait x weeks until IETF can publish
an updated RFC.  This is just an example, similar concerns hold for
all my products that implement various RFCs.

Thanks,
Simon

---

From: Pekka Savola <[email-masked]>
Date: Thu, 6 Oct 2005 14:18:57 +0300 (EEST)

This may be partially a terminology issue..

On Thu, 6 Oct 2005, Simon Josefsson wrote:
> manual, or to fix typos, or to fix real bugs in the RFC.

I'd sympathy to this if it was worded differently:

    I want to be able to incomporate parts of RFCs in documentation of
    my product.  I want to be able to modify that documentation.
    I have no need to call my part of the documentation an "RFC", and
    specifically I have no need describe modified parts as having been
    taken from an RFC.  My documentation should not be considered as a
    normative description of a protocol, and I'd have no objection to
   stating that as a disclaimer.

The key point AFAICS in "no deriv. works" is that someone can't just 
take our documentation, modify it as seen fit, and publish it as an 
"RFC" or something else.

You're still free to incorporate parts of the documents (to the degree 
copyright law allows in any case).  You could probably even try to fix 
bugs in that documentation as long as it's clear to everyone that your 
version is not trying to be a normative specification.

How could we achieve what you want without opening the door too much 
to the outsiders who would want to make modified copies of all the 
RFCs (for example)?

I'm having trouble figuring out why one would want to take (with 
modificaiton permission) larger extracts than allowed by the regular 
copyright laws.  Most software distributors have their own description 
of the protocol which they can modify at will, and may ship unmodified 
TXT copies of RFCs with a disclaimer or just refer to them.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 06 Oct 2005 13:42:35 +0200

>    stating that as a disclaimer.

This reflect one part of what I need, but I wasn't able to explain it
properly.  Your elaboration reflect what I was thinking.

I have no wish to claim my work is the RFC, but I do need to be able
to re-use contents of the RFC, and be able to modify that work.

> take our documentation, modify it as seen fit, and publish it as an 

To me, "no derivative works" means that I can't take (even parts of)
an RFC and publish that under a free license, which I would need for
my documentation or source code comments.

> copyright law allows in any case).

I'm clearly exceeding the amount permitted by copyright laws.  For
example, in my GSS-API implementation, the manual contain function
descriptions which are copied from the RFC:

http://josefsson.org/gss/manual/gss.html#Context_002dLevel-Routines

That is pretty verbatim from the RFC, although the markup was modified
to work with the online documentation system I'm using.

The current IETF copying permission appear to require me to rewrite
those descriptions.  In doing that, I am certain I will make mistakes.
I believe it would be in the interest of interoperability, and the
goals of the IETF, to allow me to use the RFC text in my manual.  And
the manual should be possible to modify by my users.

> You could probably even try to fix bugs in that documentation as
> long as it's clear to everyone that your version is not trying to be
> a normative specification.

I have no wish to say that my manual is a normative specification.

I believe handling that problem should be done by other mechanisms.
One mechanism is to sue anyone who uses the IETF or ISOC's name to
claim their work is the official version.  Using that approach would
also work against people who did not copy anything from any RFC, but
just wrote an entire protocol specification themselves, and then claim
it is the work of IETF/ISOC.

> to the outsiders who would want to make modified copies of all the 

That is a good question.

> TXT copies of RFCs with a disclaimer or just refer to them.

I hope that my example above convinced you that there is a need to
borrow larger extracts.

Cheers,
Simon

---

From: Ted Hardie <[email-masked]>
Date: Thu, 6 Oct 2005 09:28:31 -0700

At 12:52 PM +0200 10/6/05, Simon Josefsson wrote:
>manual,

To do this you need to understand the RFC; you don't really need
special rights to the RFC itself.

> or to fix typos,

To do this, file an erratum with the RFC editor, then reference the
corrected text.

>or to fix real bugs in the RFC.

Again, this is a "file an erratum" situation.  If others disagree that these
are bugs, you'll also likely discover it this way, which is useful.

> I need to

Incorporating RFCs into online help and source code comments is one
case.  Having the ability to modify an RFC's normative behavior is
a very different case.  Conflating the two into a single request is
really hurting your case here.  I totally support the first use case,
and I'm eager to get any problems resolved.  The second case
I think requires a different approach.

>IETF RFC.

You have the right now ("distribution is unlimited") to copy the RFC.
Publishing that text with your commentary ("This design choice breaks
on the following platform and causes a security problem.  I have routed
around the problem in the following way, which I believe is on-the-wire
interoperable") is fine.  Your text is no longer the RFC; it is a critique of
the RFC.  Hopefully it would be input to a change in the RFC, either by erratum
or by update.  But it is clearly within your rights now, even if you don't
request any update.

Modifying the RFC's text to say something else is not fine.  That moves out
of the realm of commentary to writing a new specification.  If you're going to
do that, you need to drop all pretence that it is an IETF spec, and make it a
Josefsson spec, as you will be its sole author.

> Because my implementation of IDNA is part of libc in most

But fixing the bug and not doing the extra work to get the community
on board with change means some implementations do one thing and
some another.  Even if both are interoperable after change one, you've
started a drift process that can easily run into problems.   Filing an
erratum, then asking for an updated RFC gives you both the initial
speed you need and then the permanent record you need.

Going off and creating the Josefsson document series is, of course, your
sole right.  But if you do that, you can stop worrying about what this
venue says about your rules.  It won't be an IETF document any more.

			regards,
				Ted Hardie

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 06 Oct 2005 18:50:06 +0200

> special rights to the RFC itself.

I do need special rights to the RFC to be able to incorporate large
parts of the RFC and then change some things.  To be specific, the
GSS-API spec talk about "implementations" or "the protocol", to make
that text read in any readable way in my documentation, I want to be
able to change "implementations" to "this implemention" or "GNU GSS".

> To do this, file an erratum with the RFC editor, then reference the

I don't think that results in usable online help.  Online help has to
be focused on conveying information as fast as possible to the reader.
Having one paragraph say one thing, because I can't modify the text,
and then have another pointing out where the previous paragraph isn't
applicable doesn't fly.

> are bugs, you'll also likely discover it this way, which is useful.

I suppose you mean a I-D and not a RFC errata here?  Waiting x weeks
for the IETF to publish an updated RFC to fix a security bug is not an
option.

> I think requires a different approach.

The reason I conflate the two issues is that I see no way to write a
license to give me third parties the right to do one thing but not the
other.  If you can come up with a proposal to address only the first
problem, I would support it and my concerns would be fixed.  Lacking
such proposals from this WG, I'll state what license would work for
me, and let the WG sort out the details.  Hopefully that process will
lead to some real changes of BCP78.

> You have the right now ("distribution is unlimited") to copy the RFC.

I don't buy that, because that text is not part of the copying
conditions.  Solving this is easy though, just update BCP78 to give
third parties the right to copy and distribute RFCs.

> or by update.  But it is clearly within your rights now, even if you don't

Agreed.

> Josefsson spec, as you will be its sole author.

My intention is not to modify the original RFC.  The distinction is
subtle, since I need many rights, most of them are the same rights as
anyone who would want to be able to modify the original RFC.

> venue says about your rules.  It won't be an IETF document any more.

Right, and doing anything of the kind isn't what I'm talking about.

Thanks,
Simon

---

From: Pekka Savola <[email-masked]>
Date: Thu, 6 Oct 2005 20:00:56 +0300 (EEST)

On Thu, 6 Oct 2005, Simon Josefsson wrote:
> I'm clearly exceeding the amount permitted by copyright laws.

Just for clarity, what I was saying is that whether or not copying is 
allowed, I'm allowed to write in my hypothetical documentation:

"RFC xxxx describes the functions as follows:

   Routine                         Function
    -------                         --------
    gss_init_sec_context            Initiate a security context with
                                    a peer application.
    gss_accept_sec_context          Accept a security context
                                    initiated by a peer application.
    gss_delete_sec_context          Discard a security context.
    gss_process_context_token       Process a token on a security
                                    context from a peer application.
    gss_context_time                Determine for how long a context
                                    will remain valid.
    gss_inquire_context             Obtain information about a
                                    security context.
    gss_wrap_size_limit             Determine token-size limit for
                                    gss_wrap on a context.
    gss_export_sec_context          Transfer a security context to
                                    another process.
    gss_import_sec_context          Import a transferred context.

We note that gss_export_sec_context actually does more than just 
transfers the security context, ...."

Similar could apply to longer extracts especially if the right to 
redistribute (unmodified) copies is granted, but you'd probably need 
to make the edits/clarifications/etc. as diffs after an extract.

> For

Would doing at least a part of this be a logically equivalent to the 
case of MIB modules?  I agree that documents describing APIs 
are a bit of special case.

Note that if you needed to modify a part of it, you could maybe insert 
a note after a quote from the RFC stating which parts you believe are 
not relevant.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 6 Oct 2005 10:23:12 -0700

>for the IETF to publish an updated RFC to fix a security bug is not an

No, I mean an erratum, as in; http://www.rfc-editor.org/errata.html .
>other. 
>If you can come up with a proposal to address only the first
problem, I would support it and my concerns would be fixed.

Why would something like "The authors hereby grant a license to
excerpt text and figures from this specification, provided the text
or figures are  appropriately referenced and not modified in any
way not already permitted" not work for one and not two?  The
existing permissions already permit translation, so that is not changed
by this.  This grant would allow you to excerpt any amount of text
or figures, but would not allow you to change the sense of the text.

			regards,
				Ted Hardie

---

From: "Lawrence Rosen" <[email-masked]>
Date: Thu, 6 Oct 2005 11:54:29 -0700

I support Simon's efforts. That said, I also find parts of the current IETF
policy unenforceable as a matter of copyright law:

   "In no case does copyright protection for an original work of authorship
   extend to any idea, procedure, process, system, method of operation,
   concept, principle, or discovery, regardless of the form in which it
   is described, explained, illustrated, or embodied in such work."
   17 U.S.C. 102(b).

I can think of no better example of such a situation than a specification
for a software standard.

To the extent that an IETF specification contains code or specific
procedures that must be followed to be compatible, I fail to see how that is
copyrightable expression. This principle of copyright law has been around
since Baker v. Selden was decided by the U.S. Supreme Court more than a
century ago, and it has been affirmed in the era of computer software many
times since. 

It would probably be infringement for someone to copy an entire IETF
specification, or perhaps even to copy the words that surround the normative
rules, but nobody can claim copyright protection to prevent the normative
rules from being implemented (and that implementation described) by copying
them.

It would be a gross perversion of the constitutional and statutory copyright
and patent scheme if IETF -- or any other standards organization -- could
prevent the implementation or improvement of a published specification by
necessarily copying them and/or creating derivative works, in the absence of
a patent.

Here's some of what the Court said in Baker v. Selden:

   "Charles Selden, by his books, explained and described a peculiar
   system of book-keeping, and illustrated his method by means of 
   ruled lines and blank columns, with proper headings on a page, 
   or on successive pages. Now, whilst no one has a right to print 
   or publish his book, or any material part thereof, as a book 
   intended to convey instruction in the art, any person may 
   practise and use the art itself which he has described and 
   illustrated therein. The use of the art is a totally different
   thing from a publication of the book explaining it. The copyright 
   of a book on book-keeping cannot secure the exclusive right to
   make, sell, and use account-books prepared upon the plan set 
   forth in such book. Whether the art might or might not have 
   been patented, is a question which is not before us. It was not 
   patented, and is open and free to the use of the public. And, 
   of course, in using the art, the ruled lines and headings of 
   accounts must necessarily be used as incident to it.
   101 U.S. 99, 104 (1879).

While there are many reasons not to apply Baker v. Selden as if it were a
bright-line rule, the IETF policy does not properly acknowledge the effects
of the long line of cases that followed Baker in which the courts enunciated
the doctrine of merger ["copyright protection is denied to expression that
is inseparable from the ideas, processes or facts underlying the
expression"] and the doctrine of scenes a faire ["copyright protection is
denied to elements of a program that are dictated by external factors, such
as compatibility requirements and industry-wide programming practices"].

/Larry 

Lawrence Rosen
Rosenlaw & Einschlag, technology law offices (www.rosenlaw.com)
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) 
   [Available also at www.rosenlaw.com/oslbook.htm]

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 07 Oct 2005 09:48:49 +0200

> No, I mean an erratum, as in; http://www.rfc-editor.org/errata.html .

I've sent updates there that were ignored for several weeks, so the
situation is similar.  Also, do an RFC Editor errata submission count
as an IETF contribution?  It isn't included in BCP78 as far as I can
tell.  So there is no license that permit me to send updated
paragraphs to the RFC editor either, if I exceed the amount of text
permitted by normal copyright laws.

> or figures, but would not allow you to change the sense of the text.

It doesn't allow me to change the text at all.  Which I need, to be
able to change things like "the protocol" to "this implementation" and
similar.  But your suggestion is certainly a move in the right
direction.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 07 Oct 2005 09:55:15 +0200

> "RFC xxxx describes the functions as follows:

You are quoting my manual here, and not the RFC, since I noticed some
typographical changes I made.  Doing typographical changes through a
diffs is a problem.

> are a bit of special case.

Agreed, but there appear to be special cases in most of my projects.
In Libidn, the special cases are the long tables of Unicode code
points.  In GSS, it is an API documentation.  In GNU SASL, it is the
introduction text and security considerations.  In Kerberos 5, it is
the ASN.1 schema.  I think these special cases is a sign of a more
general problem, so I'm attempting to address the general problem.

> a note after a quote from the RFC stating which parts you believe are 

Again, I don't think that is reasonable in end-user manuals.

Thanks,
Simon