Subject: RE: One copyright issue or Two?

From: "Powers Chuck-RXCP20" <[email-masked]>
Date: Mon, 21 Nov 2005 15:30:16 -0600

[delayed response...]

Comments below

> -----Original Message-----
> From: Simon Josefsson [mailto:[email-masked]] 
> Sent: Tuesday, November 15, 2005 3:07 AM
> To: Powers Chuck-RXCP20
> Cc: [email-masked]
> Subject: Re: One copyright issue or Two?
> 
> 
> "Powers Chuck-RXCP20" <[email-masked]> writes:
> 
> >    As best as I can tell, folks in this discussion are doing jumps
and 
> > twists trying to resolve two separate issues, the 
> > use/modification/derivation/etc of "code" embedded in IETF RFCs
(e.g. 
> > ASN.1 schemas, source code, etc), and the 
> > use/modification/derivation/etc of normative text of the RFC 
> > documents. In doing so, it appears that attempts are being made to 
> > resolve the discussion with a single solution when I believe the two

> > can and should be addressed separately, as to me they merit very 
> > different solutions.
> 
> They could be addressed separately, but I believe many of the 
> issues are similar.
> 
> Where do we draw the line between source code and text?  For 
> example, is ABNF code or text?

I think this line would not be that difficult to draw, and would even
support a rather liberal definition of "source code". But there are
portions of RFCs that are clearly normative text which would not be
considered a functional component of any software implementation (e.g.
not comments, documentation, etc). These portions should be excluded
from permissions covered by a relevant IETF software license.

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

> 
> >    For the other issue, that of reuse of the normative text by
anyone 
> > who wants to do so, I am still struggling to understand why there is
a 
> > _need_ to make the text of the RFCs broadly available for use in 
> > derivative works
> 
> 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.

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

> 
> > If I were to write some code which implemented an IETF RFC, and at 
> > various points I decided that I have a better way to implement the 
> > protocol than as defined in the RFC, then I am certainly free to do 
> > so, and I am also free to draft man pages, comments, etc indicating 
> > what I have done without having to use to RFC text itself as a 
> > starting point.  Copyright law does not prevent me from writing my
own 
> > description of what I have done, it simply prevents me from deriving

> > my description from someone else's description without permission. 
> > Since the right already exists to redistribute the IETF document as
a 
> > whole in unmodified form, then it would be easy to indicate with my 
> > own text where my code differed from the RFC (and presumably why) 
> > without having to use the existing RFC text.
> 
> I don't think this is a realistic view of how software is 
> developed today.
> 
> If you are implementing something you are normally building 
> on someone else's work.  There is no reason not to, most 
> standards have a open source implementation available.  These 
> implementations all permit modification by third parties.
> 
> You take an implementation, make your own modification and 
> document them.  The problem now is that the original 
> implementation (which could be Apache, BIND, OpenSSL, LibIDN, 
> ...)  include material derived from RFCs.  If you don't have 
> the right to re-use that material in an implementation that 
> doesn't implement the original protocol, there is a problem 
> for the implementer.  I'm arguing that it is 
> counter-productive for the IETF to cause this problem.  This 
> harms the companies doing research and development on 
> Internet protocols, which are the same companies who sponsor 
> IETF attendees.
> 
> Permitting that someone from releasing his modified generally 
> lead to a better working Internet.  This is how software that 
> runs the Internet today has developed.  For example, Sendmail 
> and the Cyrus IMAP server has been widely used by companies 
> which make minor modifications (e.g., optimizations for 
> mobile platforms), these later changes eventually move back 
> into the IETF if they proved useful and there is a need to 
> standardize them.  Look at what the LEMONADE WG is doing, and 
> who's driving that work.  There are many other examples.

I don't believe that how software is being developed by some, and
whether or not any particular change to implementations of an IETF
standard improves the Internet, is in question, either.

> 
> >    It seems to me that the primary desire to have this broad right
is 
> > based on "I want to use the RFC text", and not "I have no option but

> > to use the RFC text"
> 
> I'm not sure this is correct.  I think we are close to the 
> second position, at least if you consider what is practical 
> for most companies.  Many companies are basing their work on 
> free software projects (look at how Mac OS X re-use parts 
> from FreeBSD).  If you want to take Apache, BIND or other 
> free software projects that include excerpts from RFC, you 
> need the right to be able to modify the package, including 
> any RFC excerpts.  I'm arguing that the RFC copying 
> conditions shouldn't be a burden here.

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

> 
> > and I don't believe that is a compelling enough argument to open the

> > IETF process up to the potential issues that could result from 
> > allowing folks to run wild with their own derived versions of IETF 
> > RFCs. I think the downside risk is too high for the potential
benefit 
> > of just making it easier to draft documentation.
> 
> I believe there are more concerns than merely producing draft 
> documentation.  I also believe, which Sam has argued for, 
> that any harm inherent in my proposal is already inherent in 
> the current system.  Folks won't run wild with derived IETF 
> protocols just because the copying conditions permit that.  
> The experiences from the free software community set a strong 
> precedent here.  In the few cases where a fork has happened, 
> it has frequently made things better in the long run.
> 
> Thanks,
> Simon
> 

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 21 Nov 2005 22:45:55 +0100

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

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

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

> 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

---

From: "todd glassey" <[email-masked]>
Date: Mon, 21 Nov 2005 14:11:05 -0800

Chuck and Simon -
I want to ask a sort of important question and that is "why does the IETF
have to allow anyone republishing the RFC's to put their mark on them?" - I
mean,  what is the point? the old RFC2026 license and the updated ones to a
large extent says that the documents can be reproduced as long as they
maintain their copyright acknowledgment/branding... So then why does an
OpenSource vendor need to place an OpenSource license on the IETF's work
product? So it can own the mark? But it doesn't own the IP its republishing,
and that is the key. Unless the IETF's licensing models want to take into
account any other licensing systems and interoperating with them, they are
legally irrelevant to how the IETF's contract between the submitter and the
standards process work flow works.

That is something I have wanted to ask - since the IP itself doesn't belong
to the OpenSource Vendor at all anyway... I understand the issue about
derivative rights for those that are doing work on developing product, but
not simple republishing...

Remember there are three uses
----------------------------------
1)    reference only republication rights

2)    derivative documentation rights

3)    derivative product rights

So if Debian or whoever is not turning the RFC's into a product but rather
publishing them as part of its document set, then #1 works for it. Likewise
its customer's republish the same docs or ship them on DVD or CD and there
is no issue.  If they wanted to modify the IP in the RFC's or use pieces of
RFC's they would need the #2 rights at the least and possibly the #3 rights
as well.

Todd

---

From: "todd glassey" <[email-masked]>
Date: Mon, 21 Nov 2005 14:14:41 -0800

SNIP

> unmodified, according to RFC 3978.

This is the problem because RFC2026 did allow for this and many started
using RFC's as such. This means that the IETF in pushing the RFC3978
revisions, unilatterally modified the contract between it and ongoing users.
Anyone see any problem with this?

Todd