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

From: Nathanael Nerode <[email-masked]>
Date: Thu, 6 Oct 2005 20:59:54 -0400

Executive summary:

On the whole, I think both the current RFC and Bradner's proposed changes are 
barking up the wrong tree.  They're trying to use copyright law's 
restrictions on the creation of derivative works to prevent confusion 
regarding standards.  Apart from the trouble this causes for free software, 
it *doesn't work*, because I could create my own "RFC 3978" whenever I wanted 
without using any text from the real RFC, and be subject to zero copyright 
restrictions.

What you want in order to do this is a careful *trademark* policy.  This would 
also drastically simplify the weird language which is present to deal with 
the issue mentioned in section 7.3:
"But organizations that publish
   information about proprietary technologies are frequently not willing
   to have the IETF produce revisions of the technologies and then claim
   that the IETF version is the "new version" of the organization's
   technology."
The copyright restriction language doesn't work, of course.  The IETF can make 
a document and claim that it's the "new version" of the organization's 
technology without any copyright restrictions, by writing entirely new text 
describing the same technology.  If the organization is allowed to retain 
trademark control over the names associated with the technology, while the 
IETF (or anyone else) is allowed to create derivative standards, then it 
works and everyone is happy.  The IETF can produce revisions, but they can't 
claim that they're the "new version" of the technology.

Ted Hardie <hardie at qualcomm.com> writes:
> At 12:52 PM +0200 10/6/05, Simon Josefsson wrote:
>>I need to be able to rewrite paragraphs from the RFC to better fit my
>>manual,
>
> To do this you need to understand the RFC; you don't really need
> special rights to the RFC itself.
This appears to betray a misunderstanding of copyright law.  Simon would like 
to be able to use the wording of the RFC where it is applicable.  This is 
prohibited without a copyright license, forcing either
(1) gratuitous writing of new text describing exactly the same thing
or (2) a document which is completely incomprehensible without following 
references to an external document

Neither of these is particularly desirable.

> 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.
Sounds just exactly right.  But BCP 78 does not allow him to make a new spec 
using text from the RFC where appropriate.  The proposed update, 
draft-ieft-ipr-rules-update-00.txt, doesn't either, although it gives the 
IETF permission to grant such permission on a case-by-case basis.  A 
free/open source copyright license for the RFCs would allow the text to be 
reused in any way for a document which didn't pretend to be an IETF spec or 
an RFC.  The draft-ietf-ipr-rules-update-00.txt does not allow this, and it 
is prohibited by copyright law (in every country I know of) without a 
license.

Pekka Savola wrote:
> 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.
This is correct.  This is exactly what we're talking about.

>    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.
This would not be correct for the case where he wishes to define a different 
"Joseffson protocol".  A correct version would be:
My documentation should not be considered as a 
normative description of an Internet or IETF 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  
Now, obviously we don't want them to publish it as an "RFC" or an "IETF 
document" or an "Internet draft" or anything like that.  But what precisely 
is the problem with them publishing it as "something else" (a Josefsson 
standard, for instance)?

>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)?
Let's put it a different way: what exactly is the problem with outsiders 
making modified copies of all the RFCs, as long as the modified versions 
don't claim to be RFCs, don't claim to be Internet Drafts, don't claim to be 
IETF documents, rename all the protocols they define, don't claim to be the 
standard for anything defined by an RFC, and generally don't pretend to be 
RFCs in any way, shape, or form?

Simply allow any modified version as long as it is made absolutely clear that 
it is not an RFC, not an Internet draft, and not an IETF standard.  What's 
the problem?

> I'm having trouble figuring out why one would want to take (with
> modificaiton permission) larger extracts than allowed by the regular
> copyright laws.  
Perhaps you are unaware of how little the regular copyright laws actually 
allow in most countries.  The size of extracts allowed under the "fair 
dealing" doctrines in the U.K., for example, is really tiny.

>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.
One result of the non-free license for the RFCs is that they are being removed 
from Debian, which isn't supposed to contain anything but free software.  
Debian users will probably want free protocol descriptions to use; a likely 
result is that people will create new descriptions of RFC-described 
protocols, written painstakingly with entirely different text (so not subject 
to any IETF copyright restrictions), with a reference to the RFC commenting 
that it is intended to describe the same protocol.  These will then be used 
by free software developers as normative references to implement protocols.

This seems like a really dumb result, and not in the interests of the IETF.

To clarify, in a later message Pekka Savola wrote:
> 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.

....
This is actually incorrect.  The half-page-long quotation (not for the 
purposes of review or criticism) seems very likely to be a copyright 
infringement under UK law, for instance.  The routine names are likely 
uncopyrightable under interoperability provisions of most copyright laws, but 
the descriptions are another matter entirely.

Joel Halpern wrote:
>I realize that the normal rights granted for free software give anyone the
>right to do anything with the software. 
An exaggeration: they don't allow people to commit fraud with it, or 
misrepresent its origin, or lie about its authors.  (Which in fact is the 
issue here, isn't it?)
> But there is no reason one can not write free software where specific parts
> have exceptions. 
Software with some parts free and some parts not is called "non-free 
software".

----
There are other problems with rfc3978.
Section 5.4:
> "Copyright (C) The Internet Society (year).
> 
>       This document is subject to the rights, licenses and restrictions
>       contained in BCP 78, and except as set forth therein, the authors
>       retain all their rights."
>
>Additional copyright notices are not permitted in IETF Documents
>except in the case
....
This doesn't work for most cases under US copyright law.  The documents' 
copyrights are held by their authors unless they are (a) works-for-hire of 
the Internet Society or (b) the authors have signed paper documents 
transferring copyright.  The authors have the right to have their copyright 
notices present, and I don't think it's waiveable.  I suppose if this is only 
for the case where the work is a work-for-hire of the Internet Society, then 
it works.

The only place in the entire document where permission to redistribute is 
given to anyone but the ISOC and IETF is in section 3.2:
>   No information or document that is subject to any requirement of
>   confidentiality or any restriction on its dissemination may be
>   submitted as a Contribution or otherwise considered in any part of
>   the IETF Standards Process
This is a very indirect method of permitting distribution, and it probably 
wasn't even intended as a copyright license to permit redistribution, given 
its location in "Confidentiality Obligations".

-- 
Nathanael Nerode  <[email-masked]>

[Insert famous quote here]

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 07 Oct 2005 10:57:45 +0200

Nathanael Nerode <[email-masked]> writes:

> notices present, and I don't think it's waiveable.

For what its worth, when I wanted to put "Copyright (C) Simon
Josefsson" into RFC 4027, it wasn't allowed.  After some discussions,
I was entitled to add the following:

A.  Disclaimer and License

   Regarding this entire document or any portion of it, 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.

Since I haven't signed any copyright transfer papers, nor is this
work-for-hire for the ISOC, I believe I still own the copyright for
the text that I wrote in that document.

Regards,
Simon

---

From: "todd glassey" <[email-masked]>
Date: Sun, 9 Oct 2005 09:38:15 -0700

So Steve, Simon and Nathan -

Can I ask the WG a style question  about the goals of the group -

'We' seem to be here to resolve

    1) what the submission rights are

and

    2) then to describe the relicensing or sub-licensing
        models and services/rights provided to those who
        use those licensed IP's

So can I ask you, and the group...  doesn't it sorta sound like what the
group is heading towards is a combinatorial IP release that treats a
submission for what it is, that being textual, and possibly containing sw,
or possibly being  purely sw. The reasoning is a simple Copyright-release
alone probably isnt the best coverage for these types of submissions.

Something that merges or combines the Copyright release statement's and a
selectable Freebsd/AU, OpenSource or Commercial style licensing statement
for the embedded code in the submittals?

The reasoning is that sub-use or republishing may or may not include any
code snippets, data models, or programs from extracted IETF documents,
so a one-size fits all release wont really work. There would need to be
something like a GNU? or other artistic use license against code and  MIB
definitions and then a copyright republishing right for all other textual or
graphical submissions, right?

It also may be that the code described is not licensed for reuse herein...
and that also is something that adds value since it allows for commercial
code models to be a part of the IETF process without causing any real
rugburn. I.e. provides a seamless way to include proprietary work product
without losing control of that work product. The mindset is simply that
when a patent is filed generally a best practice is filed with it, along
with the rest of the claims, and it seems reasonable that the best method
would be protectable even within the framework of the IETF.

My feeling is that a solution like this would address virtually all of the
reproduction issues including translation's and the like, as well as
providing for usable and proprietary code to be added as well.

Todd Glassey