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

[Simon Josefsson <[e-mail]>]

Elwyn Davies <[e-mail]> 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!

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

Right, agreed.

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

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:
>
> 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)".
> ]

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

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

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

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