Subject: Comments on draft-josefsson-ipr-notices-00

From: Elwyn Davies <[email-masked]>
Date: Mon, 03 Jul 2006 13:54:40 +0100

Hi, Simon.

The four examples of recent RFCs with 'extra' copyright statemsnts which you
quote are actually three separate classes of 'copright' statement.  I think you
will need two different clauses (and maybe an extra 'stub' as well) to cover the
different cases.

- RFC4501 (and the rfc3584bis draft) contain a notice which you as
author include regarding your retained rights in the whole document.  As
such that doesn't really affect the copyright notices of the draft/rfc
regarding the IETF/ISOC rights.  I guess there should be no difficulty
in drafting some suitable boilerplate to cover this case and I see no
reason why the IETF should stop authors making this sort of statement
(although doubtless those with corporate employers and IPR lawyers will
find it difficult to persuade them that the statement should appear :-)
).  This has nothing specific to do with embedded code fragments or
other pieces that might be extracted.

- RFC4287 is just an example and I don't think it need concern us here
as it doesn't actually affect anything (or shouldn't).  The stub
mentioned above might be useful for specifying the form of a suitable
example copyright statement where such is needed.

- The interesting cases are RFC4122 and RFC4226.  Looking at these I
believe that they are different from your proposal to use the GNU Lesser
GPL in the rfc3584bis draft because they essentially grant free licence
to modify the code without publishing the mods which is nearly in line
with RFC3978, s3.3 a(E) which covers extractable code fragments and the
like.  The Lesser GPL is different in that it requires publication of
modified source code which is not in line with the general principles of
RFC3978. To be consistent with our existing position we would need to
only allow additional copyright statements to be present in RFCs and to be
propagated into extracted code if they followed the spirit of s3.3 a(E).
[Note: Brian Carpenter has recently obtained an opinion from our lawyer related
to this issue:

s3.3 a (E) of RFC3978 states:
       (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]).

I quote...
For other reasons, I received Jorge's opinion on this point the other
day:

"  Under RFC 3978, it is currently OK to modify
code extracts from RFCs.  Thus, this aspect is not currently
being discussed at the IPR WG.  The issue is modification of
  other types of extracts. "

So Jorge certainly reads (E) to mean the world and not
the I*. That is because of the parenthesis "(and not limited
to use within the IETF Standards Process)".
]

So I would suggest that you need to cover these three cases separately
(and think about whether the last one applies to things other than code
fragments).

The draft will also need to extend the form of the abbreviated copyright notice
that is supposed to go into such extracts (s5.6 of RFC3978).

Regards,
Elwyn

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 03 Jul 2006 16:10:17 +0200

Elwyn Davies <[email-masked]> writes:

> Hi, Simon.
>
> The four examples of recent RFCs with 'extra' copyright statemsnts
> which you quote are actually three separate classes of 'copright'
> statement.  I think you will need two different clauses (and maybe
> an extra 'stub' as well) to cover the different cases.

Hi Elwyn!

> other pieces that might be extracted.

Right, agreed.

> example copyright statement where such is needed.

Right.  It's only relevance here is that, technically, it does contain
an additional copyright notice, but RFC 3978 forbids such additional
notices.  The example can be used as a sanity checks on rules in this
area.

> - The interesting cases are RFC4122 and RFC4226.

Right, although I consider the first class (RFC 4501/RFC 3584bis) as
equally important.  However, they may be less contentious.

This class seem different in that it relates to the LICENSE associated
with the copyright notice, not the actual copyright notice itself.  My
draft did not intend to go into this area, because the outbound IETF
license discussion in this WG has not concluded (or even began..).  It
may be premature to discuss restrictions on outbound licenses when the
WG haven't discussed the general IETF outbound license yet.  However,
for the purpose of discussion, let's go ahead anyway...

> Looking at these I believe that they are different from your
> proposal to use the GNU Lesser GPL in the rfc3584bis draft because
> they essentially grant free licence to modify the code without
> publishing the mods which is nearly in line with RFC3978, s3.3 a(E)
> which covers extractable code fragments and the like.

I believe a similar problem exists with the RFC 4226 license.  Here is
the RFC 4226 license:

   /* Copyright (C) 2004, OATH.  All rights reserved.
    *
    * License to copy and use this software is granted provided that it
    * is identified as the "OATH HOTP Algorithm" in all material
    * mentioning or referencing this software or this function.
    *
    * License is also granted to make and use derivative works provided
    * that such works are identified as
    *  "derived from OATH HOTP algorithm"
    * in all material mentioning or referencing the derived work.
    *
    * OATH (Open AuTHentication) and its members make no
    * representations concerning either the merchantability of this
    * software or the suitability of this software for any particular
    * purpose.
    *
    * It is provided "as is" without express or implied warranty
    * of any kind and OATH AND ITS MEMBERS EXPRESSaLY DISCLAIMS
    * ANY WARRANTY OR LIABILITY OF ANY KIND relating to this software.
    *
    * These notices must be retained in any copies of any part of this
    * documentation and/or software.
    */

This license require things (i.e., the acknowledgement requirement in
paragraph 1 and 2 below the copyright notice) which the IETF license
do not require.

It is unclear whether you have the right to use the code extract under
the IETF license, which do not require the acknowledgements discussed
above, or not.  The license above places restrictions that are
incompatible with the IETF license.  It appears that the RFC 4226
source code cannot be used within the IETF process without conforming
to the license above, which goes beyond the IETF license.

However, I don't see this as a serious problem.  You don't have to use
the source code, neither in an implementation, nor in a follow-on IETF
contribution.  The presence of the source code may provide useful to
some people that are willing to accept the license, it does not appear
to harm anyone else.  Source code, even with a restrictive license, in
documents further the goal of the IETF.

> The Lesser GPL is different in that it requires publication of
> modified source code which is not in line with the general
> principles of RFC3978.

First, the general principles of RFC 3978 seem to depend highly on
whom you're asking, and they were never formally documented anywhere,
so I don't think that is a useful argument.  IIRC, Scott Bradner said
even RFC 2026 never gave people permission to extract and use portions
of RFCs in implementations.

Second, the argument above for RFC 4226 is as applicable here.  The
presence of LGPL source code may be useful for someone who accepts the
license.  Others do not need to use the code.  The net result is that
some people can implement the protocol easier.  If we remove the code,
we don't get any practical advantage but we do get conformance to the
current IETF license.  It doesn't seem to further the goal of the IETF
to remove the code, even if it has a poor license.

> To be consistent with our existing position we would need to only
> allow additional copyright statements to be present in RFCs and to
> be propagated into extracted code if they followed the spirit of
> s3.3 a(E).

I'm having serious trouble understanding that spirit.  The spirit
doesn't seem documented anywhere, and there are different
interpretations of the current license clause.

I believe that the RFC 4226 license, and the LGPL license, share the
same spirit that RFC 3978.  There may be technical incompatibilities,
such as preventing additional copyright notices.

> [Note: Brian Carpenter has recently obtained an opinion from our
> lawyer related to this issue:
>

This is very interesting.  If there is consensus around this point, I
believe the update of RFC 3978 should be clarified to make this point
clear.  I believe this should be brought up as a separate issue.  I've
never heard this argument before.

Everyone I've talked to who has reviewed the license has interpreted:

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

To mean that (A)-(E) are only granted to I*.

> (and think about whether the last one applies to things other than code

It's not clear to me how the document could be updated, so I'm
postponing any changes until there are explicit text suggestions or
some consensus around an approach have been established.

> The draft will also need to extend the form of the abbreviated
> copyright notice that is supposed to go into such extracts (s5.6 of
> RFC3978).

Hmm.  I haven't considered that part before.  I wonder if such a
copyright claim is even valid.  The copyright notice in IETF documents
relate to the RFC numbering scheme and the IETF boiler plate.  None of
those exist in an extracted MIB (right?).  It seems strange to force a
copyright notice on something that the IETF doesn't have any copyright
claim on.

This should probably be discussed as a separate issue too.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 04 Jul 2006 14:52:47 +0200

I believe this is worth a separate issue in the tracker.  The question
is technically limited, has input from Jorge, so I hope it can be
closed fast.

The only reason I wish to bring this up as a formal item is that we
haven't heard about this interpretation before, and it is a rather
surprising one (to me).

A first attempt at defining the issues:

1) Do RFC 3978 already permit modification of code extracts from RFCs
   by third parties, through the "(and not limited ...)" phrase?

If the consensus is affirmative, I believe RFC 3978bis, or the
document that deals with the outbound rights from the IETF to third
parties should be clarified to make this point more explicitly.  Hence
a second part of this issue:

2) Should we clarify the license to make this clear?

I'm quoting the relevant part from Elwyn's e-mail below.

Thanks,
Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 04 Jul 2006 10:14:49 -0400

It certainly seems to me as a lay reader that "to ...modify ... (and 
not limitted to use within the IETF Standards Process) any executable 
code or code fragments" does permit modification of code 
extracts.  Which is consistent with what we have agreed we want.

Yours,
Joel M. Halpern

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 04 Jul 2006 17:14:05 +0200

Joel, note that the first section of RFC 3978 3.3 says:

   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:

Thus all rights granted below in (A)-(E) appear to be granted to the
ISOC and the IETF.  It doesn't say anything about third parties.

When I read the above together with (E):

I get the impression that the ISOC/IETF has been given the rights in
(E) to use the contribution "for any purpose (and not limited to use
within the IETF Standards Process)".

I cannot infer from anywhere that third parties are granted the rights
in (E).  If I read Jorge's interpretation below, that is what he seem
to suggest, and that's why I'm so surprised.  If I'm
miss-understanding his point, please point out the error.

I'm pretty sure this aspect has been discussed before, but I don't
recall that the conclusions were the same then.

Regards,
Simon

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

> code or code fragments" does permit modification of code extracts.
> Which is consistent with what we have agreed we want.
>
> Yours,
> Joel M. Halpern
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Jul 2006 11:43:47 +0200

Simon,

This is why we need to fix the inbound rights, to ensure we have
the right to give the outbound rights that we already claim to give.

    Brian

---

From: "todd glassey" <[email-masked]>
Date: Wed, 5 Jul 2006 05:47:27 -0700

You understand Brian that you have just described is knowledge of the
commission of a fraudulent conveyance... right? Doesn't Jorge advise you to
not put statements like that in print.

Todd Glassey

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 05, 2006 2:43 AM
Subject: Re: NEW ITEM: Does RFC 3978 3.3.a.(E) grant third parties rights to
modify source

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Jul 2006 15:20:27 +0200

If my understanding of Jorge's interpretation below is correct, it
seems that the ISOC/IETF may have already acquired those inbound
rights for code, in RFC 3978 3.3, and can grant the same rights to
third parties if the IETF wishes too.

Doing so would be quite useful, since if this were not the case, the
only solution for me would be to approach authors of RFC 3978 licensed
RFCs and try to convince them to release portions under a more liberal
license.  Now, it may that the IETF can grant rights to at least code
fragments in RFC 3978 licensed RFCs.

This isn't to disagree, the inbound/outbound rights should be fixed
and clarified.

/Simon

---

From: "todd glassey" <[email-masked]>
Date: Wed, 5 Jul 2006 09:43:36 -0700

Simon
----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 04, 2006 8:14 AM
Subject: Re: NEW ITEM: Does RFC 3978 3.3.a.(E) grant third parties rights
tomodify source

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

Simon -
that happens when the Document is Published... remember there are two
releases...  There is the release that is signed by the submitter when they
enter IP into the IETF for Standardization; and then THERE IS A SECOND, AND
SEPARATE RELEASE when the IETF publishes this document...

The rights granted in the SECOND (Outgoing) Release MUST be equal to, or a
subset of those rights granted in the Incoming Release since those rights
(the Incoming ones) cap those available for re-publication. Another VERY
important aspects of this is that the releasese are NOT simultaneluouly
executed, they are executed sequentally and that is it... there isnt
anything else.

Becuase the process is not simultaneous the IETF is still stuck with all the
Sua Sponte responsibilities that the diligence requirements put in place too
IMHO.

The IETF republishes under its Publishing and Use proviso (which is defined
in the Outgoing Rights Statement) and as you can see by the reading of this
text, the participation in this IETF means turning over any and all rights
to the IP to the IETF. And that means any and all uses, not just
re-publication rights.

Todd

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 28 Jul 2006 01:19:25 -0700

Ticket #1339 assigned.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 Jul 2006 21:43:20 +0200

> Ticket #1339 assigned.

I believe Jorge have explained that; Yes, the intention (if not the
language) was to give third parties the right to modify code fragments
of documents.

I believe some WG members earlier claimed the opposite.

I think we can close the ticket with the contents of this e-mail.
Unless someone objects, of course.

Thanks,
Simon

From: "Contreras, Jorge" <[email-masked]>
Subject: RE: Comments to WG meeting
Newsgroups: gmane.ietf.ipr
Cc: "Joel M. Halpern" <[email-masked]>, [email-masked]
Date: Mon, 17 Jul 2006 20:33:11 -0400

> -----Original Message-----
> From: Simon Josefsson [mailto:[email-masked]]
> Sent: Monday, July 17, 2006 2:36 PM
> To: Contreras, Jorge
> Cc: Joel M. Halpern; [email-masked]
> Subject: RE: Comments to WG meeting
> 
> 
> >
> >> If I understand Jorge correctly, in his response quoted by Elwyn
> >> recently, RFC 3978 already give everyone this permission too, for
> >> code, but due to its unclear wording, at least I have not 
> been reading
> >> it that way.
> >
> > Here is the right granted for code extracts that's 
> currently in RFC 3978
> > at 3.3.a(E):
> >
> > 		to extract, copy, publish, display, distribute, 
> modify and
> >           Section 5
> Right, although the interesting aspect is whether the rights 
> are granted
> to third parties or only to the IETF and the ISOC.  Your statement, as
> quoted by Brian/Elwyn, implies that you regard the '(and not 
> limited to
> use ...)' parenthesis to mean that third parties are granted 
> those rights.
> 
> The leading text in 3.3.a says that the rights in (A)-(E) are 
> granted to
> the IETF and ISOC, it doesn't say anything about third parties.
> 
> I think we need to establish (1) whether RFC 3978 give third 
> parties the
> above rights, and more importantly, (2) what the IETF's 
> intentions are in
> this area.
> 

Simon -- you are right about the ambiguity.  The license language
that I pasted above just grants rights to IETF Participants.  You have
correctly interpreted RFC 3978.  However, many people point to the
legend "Distribution of this memo is unlimited" that appears in most,
if not all, RFCs as indicating that rights extend more broadly.
This conclusion is drawn not only from this language (which is admittedly
vague), but also from generally accepted past practice.

This being said, I completely agree with you that the intent should
be clarified in the next iteration of RFC 3978.