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

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 03 Oct 2005 18:56:58 -0400

Folks, draft-ietf-ipr-rules-update-00.txt is the primary work item left 
for this WG.  Is this a direction we want to go?  Is this the way to 
get there?

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Oct 2005 08:26:50 +0300 (EEST)

> for this WG.  Is this a direction we want to go?  Is this the way to

The clause on extracting material is OK.

The text on the rights to create derivative works is confusing, 
however.  RFC3978 section 3.3 states that it's OK to make derivative 
works for the IETF standards process or an internet-draft.  You'll 
need to closely examine the definitions to note that 'IETF Standards 
Process' applies to all IETF RFCs, not just those on the standards 
track.

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.

As for "is this the way to get there?" -- I'd say, initially (to 
evaluate whether there is WG consensus or not) this is OK.  However, I 
think we should consider re-spinning BCP 78 to add these provisions, 
or at least create a new self-standing document.  I don't want to see 
the IPR process documents ending up patchwork with no one able to 
figure out where to find the patches and how they fit together.

-- 
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: Wed, 05 Oct 2005 10:56:16 +0200

(I'm re-sending this because my previous attempt did not arrive...)

> for this WG.  Is this a direction we want to go?  Is this the way to 

The two problems I have identified earlier are still present in this
new version.  They prevent me from incorporating RFC material in my
free software products, both in manuals and in source code.

I get the feeling my issues have been ignored, but I will once again
attempt to explain my concerns.

The most important part is 1), but 2) is critical too.  Below I have
tried to focus on my interpretation of the current text, rather than
claiming some objective form of interpretation.  If my interpretation
is wrong somewhere, please tell me where it is flawed.

1) The text in RFC 3978 3.3(a) only grant rights explained in (A)-(E)
   to the IETF and ISOC only:

   a. To the extent that a Contribution or any portion thereof is
      protected by copyright and other rights of authorship, the
      Contributor, and each named co-Contributor, and the organization
      he or she represents or is sponsored by (if any) grant a
      perpetual, irrevocable, non-exclusive, royalty-free, world-wide
      right and license to the ISOC and the IETF under all intellectual
                        ^^^^^^^^^^^^^^^^^^^^^^^^
      property rights in the Contribution:

   The newly proposed section reads:

  (E)  to extract, copy, publish, display, distribute and incorporate
      into other works, for any purpose (and not limited to use within
      the IETF Standards Process), and to grant third parties
      sublicenses to do the same, any portion of the Contribution
      without modification (other than non-substantive modifications
      such as translation into languages other than English or
      compilation of source code statements into executable code), and
      further provided that the notices required by Sections 5.4 or 5.6
      below, as applicable, are included.

   The reference to "grant third parties sublicenses" does not seem to
   me to mean that the rights are granted to third parties
   automatically.  The text suggest to me that IETF/ISOC has acquired
   the right to grant sublicenses.

   I interpret the combination of text that third parties are not
   granted any rights at all to RFC material.  The only change here is
   that IETF/ISOC is granted the right to sub-license their own
   rights.  It doesn't say that the rights are sub-licensed to third
   parties, or that they will be on a wide scale.

   Third parties aren't even allowed to distribute un-modified RFCs
   from what I can tell.  IETF/ISOC has the right to grant such rights
   to others, but there is no statement that this is made.

2) Now I assume that the text has been modified so that third parties
   are granted the rights listed in (E).

   The problem then is that the rights granted by the text is
   insufficient for use in free software products.

   The problem with the rights is that I, and my customers, are not
   granted any rights to make modifications to the material.  I
   personally need to be able to do that, to make RFC material in my
   manuals readable for the customer.  RFCs are often written to
   explain things in a protocol-oriented way that isn't appropriate in
   end-user documentation.  Further, RFCs frequently contain language
   problems that I'd like to correct.  I want to be able to
   re-organize and re-write portions of the RFC in a way that fit into
   my manual.

   Finally, my customers have chosen to buy software from me that is
   freely licensed.  I.e., they pay for the right to be able to make
   modifications to the software package.  I can't use material from
   RFCs in my software packages if I want to sell to these customers.
   You may claim this is my problem, but I claim that it is in the
   IETF's interest, or at least should be, to have the actual RFC
   material be spread as widely as possible, rather than a protocol
   explanation made by various implementers.

If the IPR WG will meet in Vancouver, and if there is a genuine wish
from the WG to not only listen to my opinion but also to address my
concerns, I could make travel arrangements and give a presentation.

Thanks,
Simon

---

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

I am personally uncomfortable with the notion that anyone can make versions 
of the RFCs that say anything they want.
I have no problems with folks incorporating the whole RFC, or portions of 
it that they need to make products.
and I have no right to gainsay anyone from writing a document that they 
distribute which says "While I like RfC X, my product implements 
modification Y..."
However, it is not clear to me that it is necessary to permit modification 
of the actual RFCs.
For example, if someone uses a MIB, it would be extremely BAD if they 
changed the definition of the objects using the assigned OIDs.
And while we can not prevent folks from creating confusion about what the 
RFC actually says, we can at least set up the rules to try to make it clear 
that the RFC is the RFC and not some modificaiton thereof.

Maybe I am misunderstanding what Simon Josefsson has asked for, but the 
above is what I thought I had heard, and my personal reaction.

Yours,
Joel

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Oct 2005 14:05:55 +0200

> of the RFCs that say anything they want.

People can already write a protocol spec to say whatever they want.

I understand and share your concern, but I believe there are better
ways to deal with the problem.  I think the belief that restricting
copying permissions of RFCs to fix the problem you are concerned with
is flawed.

If RFCs can't be modified, I may have to describe the protocol that my
products implement by writing a new protocol specification (assuming I
need to go into that kind of details in documentation, which isn't
entirely unlikely).  People who improve my product will update that
protocol specification to match the implementation.  Eventually,
sorting out the differences between the IETF published RFC and the
protocol my product implement will be difficult.

I claim it would be better if I would be able to copy parts of the RFC
into my manual, to describe the protocol I implement.  My customers
want the right to be able to modify all of my product, so they could
theoretically modify the part of the manual that was copied from the
RFC to say whatever they wanted.

I don't see a problem with my approach.

If the modifications are bad, people simply won't use it.  They can't
claim IETF supports their modification, they can't tell people to
change their software to confirm to their new invention.  They simply
have a lousy product and a nonsense document to go with it.

However, if the modification is good, other software will pick up the
improvement.  Eventually, someone may believe it is worthwhile to go
back to IETF and publish the protocol extension.  Comparing the
original RFC with the modified work will then be simple.  The modified
work can then be scrutinized by the normal IETF consensus approach
before adoption.

This is why I believe releasing as much rights as possible to RFC
texts to third parties would further the goals of the IETF.

> distribute which says "While I like RfC X, my product implements 

Agreed.

> However, it is not clear to me that it is necessary to permit
> modification of the actual RFCs.  For example, if someone uses a
> MIB, it would be extremely BAD if they changed the definition of the
> objects using the assigned OIDs.

You don't have to change the RFC to be able to do that.  You can
simply change the OID in your program.  You will then have a useless
piece of software that nobody would use, but that would be your
problem.  The IETF cannot do anything about this situation.

> And while we can not prevent folks from creating confusion about
> what the RFC actually says, we can at least set up the rules to try
> to make it clear that the RFC is the RFC and not some modificaiton
> thereof.

I'm not challenging this.  It is clear that if you take a RFC from
IETF and modify it, it is no longer the real RFC, and you can never
claim that it is.  Adding legal text in the re-distribution
permissions to explicitly take care of this potential problem would be
fine.

> above is what I thought I had heard, and my personal reaction.

I understand your view, and before I implemented RFC protocols my
products I shared your view.  But I have implemented several IETF
protocols in my products, and 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.

Thanks,
Simon

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 5 Oct 2005 07:42:13 -0700 (PDT)

>       right and license to the ISOC and the IETF under all intellectual

Indeed.  As I read it, neither this language, nor that currently in
RFC 3978, viz.,

    (E) to extract, copy, publish, display, distribute, modify and
        incorporate into other works, for any purpose (and not limited
        to use within the IETF Standards Process) any executable code
        or code fragments that are included in any IETF Document (such
        as MIB and PIB modules), subject to the requirements of
        Section 5 (it also being understood that the licenses granted
        under this paragraph (E) shall not be deemed to grant any
        right under any patent, patent application or other similar
        intellectual property right disclosed by the Contributor under
        [RFC3979]).

permits third parties to extract even unmodified MIB modules for
separate use.  Since that's something we _want_ people to do,
permission to do so should be explicit and automatic (i.e., not
requiring any special action by the IETF).  I originally thought we
had this covered in 3978, but I missed the language in 1(a) that
Simon Josefsson has emphasized.

I think these are bugs that need to be fixed.  I would be very
happy if I am in fact wrong and if someone could explain to me why.

//cmh

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 5 Oct 2005 07:48:32 -0700 (PDT)

> "Joel M. Halpern" <[email-masked]> writes:
[ ... ]
> problem.  The IETF cannot do anything about this situation.

What Joel is concerned about is publishing a modified version of an
IETF MIB module that uses the SAME OIDs as the original.  I very
strongly agree that this should not be permitted.

I have no problem with someone taking an IETF MIB module, changing the
root OID (e.g., to something under an enterprise tree), and then
making arbitrary modifications.  I think that this should be permitted,
but my reading of the language in both 3978 and the proposed update is
that it is not.

//cmh

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 5 Oct 2005 11:17:58 -0700 (PDT)

[ Resent; apologies if this turns out to be a duplicate ]

> problem.  The IETF cannot do anything about this situation.

What Joel is objecting to is for someone to substantively modify an
IETF MIB module without changing the OIDs.  I strongly agree that
this should not be permitted.

I don't have any problem with someone taking an IETF MIB module,
changing all the OIDs appropriately (e.g., by relocating the root
node under a perperly-assigned enterprise OID tree), and then making
arbitrary modifications.  I think that this should be permitted to
anyone, and if 3978 or draft-ietf-ipr-rules-update-00.txt does not
say that, then it should be fixed.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Oct 2005 15:34:35 +0200

Bundled replies:

Pekka Savola wrote:
...
> think we should consider re-spinning BCP 78 to add these provisions, or 
> at least create a new self-standing document.  I don't want to see the 
> IPR process documents ending up patchwork with no one able to figure out 
> where to find the patches and how they fit together.

Possibly, but note that it is entirely possible for a BCP (like an STD)
to consist of several RFCs. I used to think that wasn't so, but it
is allowed by BCP 9. So we can do whatever is more convenient.

Scott Bradner wrote:
...
> 
> Simon further sez:
>   The text suggest to me that IETF/ISOC has acquired
> "will acquire" (since this applies going forward, but basically correct

Exactly. So in specific cases and on request, sublicenses could be granted.
They could be royalty free. They could allow extracts from an RFC to be
embedded in open source code. So the IETF would have the freedom to do this,
but not a requirement that contributors automatically grant such rights.

...
> Pekka sez:
>   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?

I see an argument for "IESG or IAB" and I see an argument for "on the
advice of WG chairs or RFC authors".

Pekka Savola added:

 > 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.

I think that's wrong, actually. The IAD is likely to be the person
who phsyically signs a license but shouldn't be the decider; that's
for the technical side of the house.

 > Indeed.  As I read it, neither this language, nor that currently in
<snip>
 > Simon Josefsson has emphasized.

It's clear to me that the IETF's desire, historically, has been
to allow extractions of unmodified code (e.g. MIBs) but not to allow
uncontrolled modifications - that's exactly why the emphasis is on
the right to make derivative works. The new language will give us
the right to license derivative works but will not hand blanket
permission to change our RFCs to unknown third parties. I think that's
the intention.

I can envisage that once this is signed and sealed, we could issue
a public license to extract MIB modules, for example. But completely
open blanket permission? I don't personally think that is desirable.

Simon Josefsson wrote:
...
 > The page also include a petition, if you want to indicate support of
 > this effort.

Contrary to what you may falsely deduce from other events, petitions are
not part of the IETF consensus process.

     Brian