Subject: RE: One copyright issue or Two?

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

Comments below

> Subject: Re: One copyright issue or Two?
> 
> 
> * Powers Chuck-RXCP:
> 
> >          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."
> 
> Okay, what about this one:
> 
> | For legal reasons, we must include the following warning notice in 
> | this specification:
> | 
> |   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.
> |
> | However, as far as we know, the present specification is fully 
> | interoperable with RFCXXXX.
> 
> Does this really make sense?  Suppose you combine multiple 
> RFCs, do you need to add a warning for each one?
>

   I don't think there would be anything that could stop someone from
adding a tag line that they feel their implementation is interoperable
with RFCXXXX; who knows, perhaps it is? IMO as long as folks are warned
that it is a derrivative, and that caveat emptor should be the rule of
thumb, then the implemenator can make any statements they want to argue
that their implementation is acceptable.

regards,

Chuck

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

---

From: [email-masked]
Date: Fri, 09 Dec 2005 20:29:40 +0000

David
 -------------- Original message ----------------------
From: "David B Harrington" <[email-masked]>
> 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. 

Actually no there is only one copy and one conveyance authorization done... Both copies that you have identified were submitted as a single instance to the IETF's Editors for the specific purpose of publishing them such that they (those submitters) could formally use the vetting processes of the IETF to vet and advance the development of those IP's and for NO OTHER PURPOSE...

No one submitted anything to the IETF so the IETF could sit on it and not publish those IP's for vetting and advancement, there is no reason on earth to do something like that.

BTW, my feeling is that this is a key failing and for the IPR WG to just change the rules and say "tough, this is how it is today" is the fastest way into Court I can think of since it claims that the IETF and IESG have voted on these changes and they are acceptable to all participants, which clearly its not.

> If
> the IEEE is to use the IETF 'copy' then they are allowed to
> incorporate
> the RFC text 'as is', including the copyright notice. 

What you are referring to are "republishing rights" where the media must remain as it was submitted to the IETF and only for those purposes that the media was submitted for. Which is to say if the person submitting the media didnt give the IETF rights to republish their work externally from the IETF, then the IETF has violated the agreement and intent of the party submitting the media and as such is legally liable for damages and all the pain that court will cause... 

Anyone republishing these documents for any other purpose than vetting them in a IETF working group like say Debian for instance, is violating the intent of the submitter, and the IETF's offerings, such that it also may be liable for damages therein...

The question is not whether this will wind up in court but when.

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

If those submitters actually owned the work, but if they didnt, and had no rights therein, oooops. The IETF beciomes an active partner in a Computer Fraud that is prosecutable under the US's CFAA...

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

Again, this release is flimsy and one that could easily be challenged in Court especially with the sheer number of times this commentary has come up from myself alone. This group as been formally contaminated and refusing to look at whether those claims are legal requirements means that this group and its active members and their sponsors would stand as liable in any claims situation... 

If you want to get Jorge to claim publicly that this is not true and that I am wrong, and in the process, have him formally put his legal credential at risk, go ahead - but I bet he says no... he wont do it. The net effect of that would be to leave no one to refute the simple claim that if the IETF wants to give stuff away it has to be able to prove where they came from and that the submitter had proper rights to authorize them on behalf of the Submitter's Sponsor, and then to control those materials after the IETF allowed someone else to publish them, so that if there is a IP violation, there is some possible recourse. 

In closing this commentary, the intentionally building a system that violates global IP law and forces litigation against it based on that is more than negligent in my book too.

Todd

> 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]
> 
> 
> > -----Original Message-----
> > 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]
> > "Powers Chuck-RXCP20" <[email-masked]> writes:
> > 
> > >> 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.
> > 
> > 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.
> > 
> > > 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.
> > 
> > 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: [email-masked]
Date: Fri, 09 Dec 2005 22:18:29 +0000

Chuck/All - responses in-line - but basically the Release Model has some flaws... and we need to deal with the issues of intent - also please don't take this commentary personal (anyone) it's meant to be the devil's advocates role and I do it pretty well!

Todd

 -------------- Original message ----------------------
From: "Powers Chuck-RXCP20" <[email-masked]>
> > From: Simon Josefsson [mailto:[email-masked]] 
> > Sent: Friday, December 09, 2005 11:07 AM
> > To: Powers Chuck-RXCP20
> > Cc: [email-masked]
> > 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.
> > 
> > You can't continue to claim that in good faith without 
> > explaining how my license fail to protect against this situation.
> 
> [Text from draft -03]
> 
>       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. 

Once again I have to bring up that the contributor is not necessarily the author or the person who submitted the material to the IETF. That needs to be addressed.

>            Unauthorized redistributed
>            modified works 

No propagatable release the IETF was to issue for forward use, cannot violate the intention of the person submitting the works to the IETF which brings us to whether RFC's were supposed to be reference-able as Internet Standards or Standards in process relative to the intent of the person who submitted the work.

For instance, if my intent in submitting to the IETF an IP was to vet it and work on it in a WG, I would not be intending that the IETF be able to republish that work for anyone's use outside of the vetting process, and so Debian is now in copyright violation, and yes I am about to start speaking with their general counsel about it...

>            must (a) not claim endorsement of the
>            modified work by the IETF, IESG, IANA, IAB, ISOC, RFC
>            Editor, or any similar organization, and (b) remove any
>            claims of status as an Internet Standard, e.g., by
>            removing the RFC boilerplate.  The IETF suggests that any
>            citation or excerpt of unmodified text reference the RFC
>            or other document from which the text is derived.

This last part also doesn't work at all, and the reason simply is that the IETF can only work within the constraints of the contract it set up with the person who submitted the materials. So you have to ask, was the intent of the person who owns the IP to give it away? because that's what this does...

> 
> 
> Not sure how this can be construed to "protect" against publishing
> modified normative text - it would be horribly easy to publish edited
> normative text which did not "contain misleading author, version, name
> of work, or endorsement information" but which could still be implied to
> be the actual text from the RFC. 

All anyone would have to do is re-write enough of the text to qualify as a new work, and then the copyright statement is moot. That's why this doesn't work.

> While one might not be able to publish
> a complete, "fake" RFC, one would still be able to grab pieces of an
> RFC, edit it and republish it without the unsuspecting reader being any
> wiser to the fact. 

Uh OK but why? what is the business case or value in this happening?

> This is why I propose the use of a "warning label" -
> telling folks they must say "this is not real" is much more effective
> than just telling them "you can't say this is real."
> 
> > 
> > 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.
> 
> Here, you make my point above. You insist that the IETF grant
> permissions compatible with free software licenses, which by definition
> would allow someone to take the normative text, edit it to say anything
> they want, and then republish it, with some rather minimal restrictions
> regarding claiming it to be valid. By "say anything they want", I don't
> mean they could specifically claim it is an RFC; I mean they could copy
> and modify a part(s) of the normative text itself so that it had a
> completely different meaning, publish it in their work, and still imply
> through context that it was taken verbatim from the relevant RFC. I
> believe that your proposal allows this, and therefore, my statement
> above is in fact "True", not "False". Perhaps the confusion comes from
> the fact that I am less worried about entire fake RFCs being published
> than I am about it happening in pieces, which would make it much more
> difficult to recognize.
> 
> Also note that we cannot limit our discussion to just what the original
> "quoter" would do; we also have to look at future iterations. If you are
> allowed to quote normative text from an RFC, and then pass that along
> under a license which allows the next guy to edit it as they see fit,
> the result would be the same as if you yourself changed the normative
> text.
> 
> > 
> > > 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.
> > 
> > > tightly-controlled situations, or how it would negatively 
> > impact the 
> > > open source community to not do so, particularly if verbatim quotes 
> > > were allowed.
> > 
> > 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.
> 
> As I said in previous emails, I believe that a way could be defined
> which would indicate which portions of an RFC constituted "code" (e.g.
> something that would either be included in, or referenced by, an
> executable), and that those portions should be made available under an
> IETF software license, which could/should be compatible with open
> source. While making this happen would not be a trivial effort, I think
> it is possible to accomplish.

Sure - this is true but the basic issue of the intent of the submitter and the proving of their rights to do so is critical to any license that the IETF intends to stand behind being enforceable IMHO...

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