Subject: RE: One copyright issue or Two?

From: "Powers Chuck-RXCP20" <[email-masked]>
Date: Fri, 9 Dec 2005 10:14:40 -0600

Comment below

> "Powers Chuck-RXCP20" <[email-masked]> writes:
> 
> > Simon,
> >
> > Although I have yet to see anything in your arguments which 
> indicates 
> > that normative RFC text _must_ be used to document code, it is 
> > apparent that you feel that it would be impossible to not do so. 
> > Therefore, on that we must simply agree to disagree.
> 
> Ok.
> 
> I urge you to take a look of free implementations of some IETF RFCs.
> 
> Free implementations quote the RFCs in several places.  I 
> claim that removing all existing excerpts, and erasing the 
> long-standing tradition among developers to quote RFCs in 
> source code and manuals, is practically impossible.
> 
> Further, I don't understand what removing the excerpts, or 
> the tradition, would contribute to.  These excerpts are a 
> good thing. That's why I propose that IETF should change its 
> copying conditions to align with reality.  I believe it is 
> the right thing to do.

Allowing quotes from RFCs is not real the problem, as I see it. The real
problem is that your proposal would allow folks to take the normative
text, edit it to say anything they want, and republish it. This goes way
beyond "quoting RFCs". In fact, I think there would be little concern
over allowing verbatim, and properly referenced, quotes from RFCs used
as reference material - as a contributor to an IETF RFC, I would be
happy to see the results of my efforts quoted elsewhere.

Allowing the normative text to be freely modified, however, is IMO
unnecessary, and as of yet no one has provided a valid argument as to
why such permissions should be given by the IETF outside of
tightly-controlled situations, or how it would negatively impact the
open source community to not do so, particularly if verbatim quotes were
allowed. 

> 
> > However, to the text of your proposal:
> >
> >>     c.  The Contributor grants third parties the irrevocable
> >>         right to copy, use and distribute the Contribution, with
> >>         or without modification, in any medium, without royalty,
> >>         provided that unauthorized redistributed modified works
> >>         do not contain misleading author, version, name of work,
> >>         or endorsement information.  This specifically implies,
> >>         for instance, that unauthorized redistributed modified
> >>         works must not claim endorsement of the modified work by
> >>         the IETF, IESG, IANA, IAB, ISOC, RFC Editor, or any
> >>         similar organization, and remove any claims of status as
> >>         an Internet Standard, e.g., by removing the RFC
> >>         boilerplate.  The IETF requests that any citation or
> >>         excerpt of unmodified text reference the RFC or other
> >>         document from which the text is derived.
> >
> >    This is a start, but does not go nearly far enough in notifying 
> > downstream users that changes have been made, and that 
> caveat emptor 
> > is now a necessary rule for use, since we cannot assume that those 
> > producing the modified works in question will adequately document 
> > where their implementation differs from that of the RFC, 
> risking harm 
> > to the unwary adopter of their work. Therefore, I believe that is 
> > should be amended as such:
> >
> >      c.  The Contributor grants third parties the irrevocable
> >          right to copy, use and distribute the Contribution, with
> >          or without modification, in any medium, without royalty,
> >          provided that unauthorized redistributed modified works
> >          do not contain misleading author, version, name of work,
> >          or endorsement information, and that the following text
> >          is included in any subsequent distribution:
> >
> >          "Warning: This text describes a derrivative of the
> >          standard defined in RFCXXXX; the reader should be warned
> >          that this modified work may not operate in a way that is
> >          compatible with the protocol defined in RFCXXXX, and that
> >          using this modified work could result in incompatability
> >          with RFCXXXX, and thus fail to interoperate properly with
> >          compliant implementations of RFCXXX. Therefore, the reader
> >          is strongly urged to carefully review this documentation
> >          and the code it accompanies, to determine where this
> >          implemention is potentially incompatible with RFCXXX, and
> >          determine if such differences with RFCXXXX (if they exist)
> >          are acceptable."
> >
> >          In addition, any unauthorized redistributed modified
> >          works must not claim endorsement of the modified work by
> >          the IETF, IESG, IANA, IAB, ISOC, RFC Editor, or any
> >          similar organization, and remove any claims of status as
> >          an Internet Standard, e.g., by removing the RFC
> >          boilerplate.  The IETF requests that any citation or
> >          excerpt of unmodified text reference the RFC or other
> >          document from which the text is derived.
> >
> >    This would allow anyone who wanted to take and run with the RFC 
> > text to do so, while ensuring that the bar for "improving" the 
> > standard originally defined in the RFC (and thus potentially harming
> > interoperability) would be high enough that those wishing 
> to make the 
> > change would need to have a solid reason for doing so, and 
> would need 
> > to convince those who might use their code that they had 
> good reason 
> > to make the changes, and to clearly identify where those 
> changes have 
> > been made. Call it the IETF warning label...
> 
> I don't object directly to this proposal, one practical observation:
> 
> Adding the above quote to every small excerpt of RFC text in 
> an implementation seem unnecessary.

See above..

> 
> For example, in my DIGEST_MD5 implementation, the code may look like:
> 
>   /* This directive MUST appear exactly once if "auth-conf" is
>      negotiated; if required and not present, authentication fails.
>      If the client recognizes no cipher and the server only advertised
>      "auth-conf" in the qop option, the client MUST abort the
>      authentication exchange.  */
>   if (r->qop == DIGEST_MD5_QOP_AUTH_CONF && !r->cipher)
>     return -1;
>   if (r->qop != DIGEST_MD5_QOP_AUTH_CONF && r->cipher)
>     return -1;
> 
> The comment is a quote from the DIGEST-MD5 draft.
> 
> I believe the IETF may suggest that I should add a reference 
> to the DIGEST-MD5 draft in my document, but adding the above 
> warning label seem non-productive.  My implementation is 
> intended to be a compliant implementation.
> 
> But I think there is room to move ahead with your approach, 
> if we can make some minor adjustments.  I believe simply 
> removing all references to IETF etc is sufficient.  If you 
> believe adding a "warning label" would be required, we could 
> continue to discuss the actual text.
> 
> I'll forward this idea to debian-legal as well, to see if 
> they have some objections to this approach.  I can't recall 
> any existing open source license that use this approach, the 
> only thing I can recall is requests for "avoid calling the 
> product the same and clearly label all files as being 
> modified by you".
> 
> >    IMO this would also solve the "Fake RFC" problem, assuming that 
> > those wishing to fake an RFC would follow the copyright 
> rules in the 
> > first place.
> 
> I think we need to assume that.  If someone is not following 
> the rules, he can anything anyway.  Legal actions can be used 
> against people not following the license.
> 
> >    In addition, by the way, you must ensure that the 
> "Contributor" is 
> > listed among those who from whom the author of the modified work 
> > cannot claim endorsement from; one of the primary concerns 
> from some I 
> > have talked to regarding this issue is that they make a 
> contribution 
> > to an IETF standard, and then someone else takes their 
> text, reuses it 
> > in modified form, and claims that it is from, or endorsed by, the 
> > original contributor. Therefore, you cannot limit the list 
> to only the 
> > IETF and related organizations; it has to include the original 
> > contributor as well.
> 
> Ah, well spotted!  I agree.  Thank you, I have incorporated 
> this. I'll post the updated license text in a separate post.
> 
> Thanks,
> Simon
> 
> >
> > regards,
> >
> > Chuck
> >
> >
> >
> >> -----Original Message-----
> >> From: Simon Josefsson [mailto:[email-masked]]
> >> Sent: Monday, November 21, 2005 3:46 PM
> >> To: Powers Chuck-RXCP20
> >> Cc: [email-masked]
> >> Subject: Re: One copyright issue or Two?
> >> 
> >> 
> >> "Powers Chuck-RXCP20" <[email-masked]> writes:
> >> 
> >> >> Secondly, the text of RFCs is widely used inside comments in 
> >> >> source code.  This is example 1 in my draft.  Several free 
> >> >> software projects do this today (Apache, Samba, ...).
> >> >> 
> >> >> I have not gotten the impression that how RFCs are used in open 
> >> >> source projects is something the IETF want to forbid.  
> I believe 
> >> >> it would be better to harmonize the legal text with how IETF 
> >> >> standards are used.
> >> >
> >> > I don't think anyone wants to, or has even implied that
> >> they want to,
> >> > forbid the legal use of RFCs in open source projects. But simply
> >> > pointing to folks who _may_ have been using that text in 
> >> violation of
> >> > IETF copyrights and saying "you have to let them keep doing
> >> it" is not
> >> > really the right approach to solving the problem, IMO.
> >> 
> >> There is no legal use of RFCs in open nor closed source
> >> projects today.  Third parties have NO rights whatsoever to 
> >> RFCs.  Third parties are not granted a right to copy and 
> >> distribute RFCs, even unmodified, according to RFC 3978.
> >> 
> >> >> Example 1 and 5 in my draft is about this.  RFC text is 
> useful as 
> >> >> commentary in source code or documentation.  To adapt the 
> >> >> commentary for a specific audience, you need the right to make 
> >> >> modifications to it.
> >> >> 
> >> >> Compare the getaddrinfo man page in Solaris.  I think Sun made 
> >> >> good decision by using the RFC text there, and that the IETF 
> >> >> should support that behaviour.  Using the RFC text minimize 
> >> >> accidental errors introduced by a re-write.  They have 
> a standard 
> >> >> for how man pages should look, so they had to modify 
> the text in 
> >> >> some ways.  That's fine too.  But there are no legal rights 
> >> >> granted to permit that now. That's a problem.
> >> >
> >> > I understand that RFC text can be useful in documentation;
> >> but again,
> >> > that doesn't mean that is it essential, e.g. "that is the only
> >> > possible way to document my code" - is it a nice to have, it is 
> >> > awfully convenient to use, but being restricted from 
> modifying RFC 
> >> > text would not prevent anyone from documenting their code, 
> >> whether it
> >> > conformed with an IETF protocol or not.
> >> 
> >> This belittle the point of standardization in the first
> >> place.  The reason for standardizing something in the IETF is 
> >> that it should promote a better Internet.  Making it possible 
> >> for implementers to use the text in their products further 
> that goal.
> >> 
> >> If the license permit fake RFCs, that can be dealt with
> >> separately, and it has -- please read my latest license text 
> >> -- so this is not a good argument for disallowing 
> >> redistribution of modified works.
> >> 
> >> >> > and therefore risking all of the potential harm, to both the 
> >> >> > IETF process and to interoperability, that I believe could 
> >> >> > ensue.
> >> >> 
> >> >> I believe the fear here is mis-placed.  The open source 
> community 
> >> >> permit free modifications, and while there certainly has been 
> >> >> forks, none of them indicate that there is any 
> long-term harm for 
> >> >> the Internet.  Quite the contrary, the major forks 
> (e.g., OpenBSD) 
> >> >> contribute to a better working
> >> Internet.
> >> >
> >> > Having dealt with interoperability issues in standards for a long
> >> > time, I believe there is significant risk in forking of IETF 
> >> > protocols, particularly if the normative text of an RFC can 
> >> be used to
> >> > document the changes, but with no obligation to clearly
> >> state how the
> >> > revised code differs from the original implementation. We must
> >> > remember that there are those to whom a lack of 
> interoperability is 
> >> > desirable, for a variety of business and tehcnology reasons, and 
> >> > giving them the ability to make their variants appear more 
> >> valid does
> >> > not seem prudent to me, if it risks reducing the value 
> of the work
> >> > being done in the IETF.
> >> 
> >> Nobody wants to permit fake RFCs.  Can you describe a
> >> realistic scenario in which someone could create a derivative 
> >> work of an RFC that is permitted through my latest license text:
> >> 
> >>     c.  The Contributor grants third parties the irrevocable
> >>         right to copy, use and distribute the Contribution, with
> >>         or without modification, in any medium, without royalty,
> >>         provided that unauthorized redistributed modified works
> >>         do not contain misleading author, version, name of work,
> >>         or endorsement information.  This specifically implies,
> >>         for instance, that unauthorized redistributed modified
> >>         works must not claim endorsement of the modified work by
> >>         the IETF, IESG, IANA, IAB, ISOC, RFC Editor, or any
> >>         similar organization, and remove any claims of status as
> >>         an Internet Standard, e.g., by removing the RFC
> >>         boilerplate.  The IETF requests that any citation or
> >>         excerpt of unmodified text reference the RFC or other
> >>         document from which the text is derived.
> >> 
> >> If you can't find a loophole in that text that permit fake
> >> RFCs, I don't believe it is fair to use it as an argument to 
> >> forbid a free source compatible license for IETF Contributions.
> >> 
> >> > Alas, I still haven't seen any arguments which contradict
> >> my point -
> >> > that it is easy and convenient to use the RFC text for
> >> documentation,
> >> > but it is not _essential_ to do so in order to document 
> one's code.
> >> 
> >> We have been over this many times.  The explanation is that
> >> to be able to include excerpts from an RFC in free software 
> >> products, e.g. in source code, the right to make modification 
> >> must be granted, otherwise it is incompatible with both the 
> >> BSD and GPL license.
> >> 
> >> If we do not grant the right to adapt portions of RFCs in
> >> products, all RFC excerpts will have to be modified from free 
> >> software implementations.  That is a huge task that would 
> >> work against the goals of the IETF; to permit a smoother 
> >> running Internet.
> >> 
> >> > In fact, I am not against using RFC text for documenting
> >> > implementations of RFC protocols. I am, however, very 
> >> concerned that
> >> > allowing the free use _and modification_ of normative text could
> >> > result in incompatible implementations of IETF protocols 
> >> with no clear
> >> > indication that what has been implemented is no longer
> >> interoperable.
> >> 
> >> I don't disagree.  The license above is meant to prevent that
> >> situation.  Could you try to improve it to make sure what you 
> >> are worried about cannot happen?
> >> 
> >> Thanks,
> >> Simon
> >> 
> 

regards,

Chuck

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 09 Dec 2005 18:06:51 +0100

"Powers Chuck-RXCP20" <[email-masked]> writes:

> Allowing quotes from RFCs is not real the problem, as I see it.

Good.  Making sure quotes from RFC are usable in free software is one
of my goals.

> The real problem is that your proposal would allow folks to take the
> normative text, edit it to say anything they want, and republish
> it.

That is false.

The intent of my license is to protect against that.

You can't continue to claim that in good faith without explaining how
my license fail to protect against this situation.

To also require that a "warning label" is added may be fine, but I
don't want to add such text to the license unless you would accept the
final license.  I'd also like to hear from others whether a "warning
label" is a useful approach that would increase acceptance for the
license within the IETF.

I'm trying to understand whether you accept the notion that quotes or
extracts from RFCs should be permitted in free software.  If so, that
leads to granting rights to make modifications to the quote, otherwise
it will be incompatible with free software licenses.

> This goes way beyond "quoting RFCs". In fact, I think there would be
> little concern over allowing verbatim, and properly referenced,
> quotes from RFCs used as reference material - as a contributor to an
> IETF RFC, I would be happy to see the results of my efforts quoted
> elsewhere.

Good.  RFC 3978 forbid that usage, I'm trying to fix it.

> open source community to not do so, particularly if verbatim quotes were

If quotes (or tables, or ASN.1 schemas, etc) from RFCs are added to
free software projects, the quote (or tables, etc) must be modifiable
in order for the resulting combined work to be distributable under a
free license.  This argument has been given for many months, and
nobody has challenged it.

If quotes from a RFC cannot be modified, it is not possible to quote
RFCs in free software.

Thanks,
Simon

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 9 Dec 2005 12:59:36 -0500

Hi,

I'm new to the IPR list, so forgive me if I tread in areas that have
been discussed before.

I am the chair of the Bridge WG, and we are in the process of
transferring the responsibility for the Bridge MIBs to IEEE 802.1 WG.
As a result, we have been discussing what rights we can transfer to
them, what rights we cannot transfer to them, and how to protect IETF
rights.

This is the legal situation as I understand it:

There are two 'copies' of an RFC text. One is held by the RFC
editors/authors, the other one by the IETF. If
the IEEE is to use the IETF 'copy' then they are allowed to
incorporate
the RFC text 'as is', including the copyright notice. If they obtain
the
acknowledgement for derivative work from all authors and editors, they
can use the authors 'copy' and then they can change whatever they
want,
including the copyright notice (and it would be nice if they mentioned
the IETF RFC in a notice). 

In more detail:
The IETF/ISOC gets a non-exclusive copyright from RFC authors so that
the IETF can publish RFCs, let 3rd parties translate RFCs into other
languages, let 3rd parties reproduce RFCs as-is and to create
derivative works within
the IETF standard process. The author(s) retain all their rights other
than the right to withdraw the permission for the IETF to do the
above.

If anyone (including the IEEE) wants to reproduce any RFC as-is they
can do so without any specific permission - but it has to be "as-is"
and that includes the ISOC copyright - since the right for 3rd parties
to reproduce RFCs is part of the rights the IETF gets from the
author(s).

The author(s) of a RFC can tell another group (e.g., the IEEE) that
the other group can produce their own versions of the RFC if the
author(s) want to since the IETF does not get from the author(s) the
right to stop them from doing so.

If the author(s) give another group the permission to create
derivative works, this has nothing (legally) to do with the IETF
since the agreement is just between the author(s) and the other group.
Because of that, there is no reason for an ISOC 
copyright to appear since the new document is not an IETF document. It
would be nice if the other group were to include 
a note to say that their document is based on RFC XXXX, and the
author(s) can insist on that if they want but the IETF has
no formal role in the granting of permissions so the IETF cannot
require the pointer to the RFC.

A new proposal being considered in the IPR working group might change
this process so that the IETF would get from 
the authors the right to grant permission to other groups to produce
derivative works. If that were the case the IETF could 
then insist on the pointer to the RFC and an ISOC copyright if the
IETF wanted to do so. But even if this proposal is 
accepted the authors could still grant permission on their own without
any IETF involvement.

--

I'm not convinced that the existing rights are not already adequate to
allow free implementation developers to quote RFCs in their text, and
following the provisions of RFC3978 section 5, to even allow
developers to use extracts directly from RFCs.

David Harrington
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Simon Josefsson
> Sent: Friday, December 09, 2005 12:07 PM
> To: Powers Chuck-RXCP20
> Cc: [email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 10 Dec 2005 12:05:13 +0100

> I'm new to the IPR list, so forgive me if I tread in areas that have

Hi!  They have certainly been discussed, but it is not like there is
full agreement on the issue.  Below I explain my point of view of the
current situation.

> the RFC text 'as is', including the copyright notice.

Actually, no.

Supposedly by accident, the RFC 3978 license does not give third
parties any rights whatsoever.  IEEE can't even distribute verbatim
copies of the document.

However, I believe everyone in this WG agree that this should be
fixed.  Both Scott and my drafts solve this.

> If they obtain the acknowledgement for derivative work from all
> authors and editors, they can use the authors 'copy' and then they
> can change whatever they want, including the copyright notice (and
> it would be nice if they mentioned the IETF RFC in a notice).

Right.  This is likely to be the simplest way, if all authors/editors
are still active.

> the IETF standard process.

That was the intent, I believe.  RFC 3978 doesn't say this though.

> The author(s) retain all their rights other than the right to
> withdraw the permission for the IETF to do the above.

Right.

> to reproduce RFCs is part of the rights the IETF gets from the

Again, this was likely the intent (although the intent is not
documented in a "requirements document" or the like) but RFC 3978
doesn't say this.

> right to stop them from doing so.

Right.

The IEEE doesn't even need permission from the author, if the IEEE
create the document itself, without inheriting from the authors/IETF
document.

If you are copying the MIBs, this might require permission from the
IETF.  But more likely is that the MIBs are present in a free software
implementation, and that license permit the IEEE to extract and use
the MIB, so IEEE could go to implementations rather than the IETF
document.

> since the agreement is just between the author(s) and the other group.

Right.

> copyright to appear since the new document is not an IETF document.

Right.

> It would be nice if the other group were to include a note to say
> that their document is based on RFC XXXX, and the author(s) can
> insist on that if they want but the IETF has no formal role in the
> granting of permissions so the IETF cannot require the pointer to
> the RFC.

Right.

> derivative works.

Right, this is in Scott's draft.  In the Vancouver IPR WG meeting,
there was consensus on that proposal.  I support it too, it is the
first step toward making third parties have that right too.

Note that this is not an exclusive right.  The authors would still be
permitted to grant similar permissions themselves too.

> If that were the case the IETF could then insist on the pointer to
> the RFC and an ISOC copyright if the IETF wanted to do so.

Only if IEEE used the IETF work.  If the IEEE used the author's work
directly, without going through the IETF document, the IETF has no
such claim.

> But even if this proposal is accepted the authors could still grant
> permission on their own without any IETF involvement.

Right.

> developers to use extracts directly from RFCs.

Did you see my draft?  The essential portion is reproduced at:

http://josefsson.org/bcp78broken/

Currently, no implementation can quote the RFC in their text according
to the RFC 3978 license text.  The license only grant rights to the
IETF.  Rights for third parties are not granted at all.

I believe the current rights are inadequate, both for free and
proprietary implementations.

Thanks,
Simon