Subject: One copyright issue or Two? (was: Fair use conclusion?)

From: "Powers Chuck-RXCP20" <[email-masked]>
Date: Mon, 14 Nov 2005 14:41:41 -0600

(Changed subject to reflect broader scope of message)

   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.

   For the "code-like" items in the RFCs, it is (IMO) correctly believed
that implementers of the RFC specification must have free access to
implement, and modify as needed/desired, the code contained in an RFC in
software products compliant with the RFC, whether proprietary, open
source, or Martian - if you are going to specify code, then everyone
should be able to use, and modify, that code as needed to make their
software work. If this is the case, then why not adopt a software
license, based on what ever model the consensus of this group can
achieve, which would be applied to these portions of the documents? We
could then modify the RFC template and process to provide indications of
what portions of the document the software license would apply, and
clearly indicate to contributors that these portions are intended for
implementation, and that reuse/modification must be allowed. This would
solve the first problem in a way that would make it easy to draft, and
propagate, implementations of the RFC in question, including making any
changes that one believes are warranted due to errors, bright ideas,
etc.

   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, and therefore risking all of the potential harm, to
both the IETF process and to interoperability, that I believe could
ensue. 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.

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

My $.02 worth.

regards,

Chuck Powers

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Simon Josefsson
Sent: Sunday, November 13, 2005 7:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Fair use conclusion?

Hi David,

[email-masked] writes:

>> To try and draw a conclusion from this thread, it seems that whatever

>> the license we end up with, we should not have to rely on copyright 
>> law's interpretation of "fair use" as it is not clear enough.
>
> I'm going to both agree and disagree ... watch this ...
>
> I agree for that the purpose of source code usage we should not rely 
> on "fair use" rights - the most obvious examples are things like ASN.1

> modules, MIB source, etc. that are clearly intended to be used 
> verbatim (or close to it) in source code.

ASN.1 schemas are clearly not used verbatim or close to verbatim today.
They are modified heavily, sometimes beyond recognition.  The same can
be said about source code, they are often modified to conform to various
coding standards used in different projects.  I'm not sure how or
whether this modify the rest of your message, but I'll respond to it
anyway.

> IMHO, if such source code extracts from RFCs are restricted in a 
> GPL-incompatible fashion, we've made a major mistake in that they will

> be unusable in systems including Linux.

I believe that is the case currently.

> I reserve judgment on documentation while I think about it some more 
> because unlimited rights to modify documentation is what opens the 
> gate to fraudulent RFCs, but protocol implementations need to be 
> documented.

Remember that there are other legal ways to handle fraudulent RFCs.
Trademark laws is a good tool for that sort of abuse.  Copying
conditions is a fragile tool here.

> The place where I disagree is educational usage.  Two of the central 
> purposes of "fair use" rights are to establish the rights to comment 
> and critique copyrighted works without the permission of the copyright

> holder.  Needless to say, comment and criticism of existing works is 
> central to the purpose and practice of education, hence if educational

> use of RFCs is to be considered, I will insist that "fair use" be part

> of that consideration.  Yes, it'll be messy, but ignoring the 
> existence of "fair use" rights, particularly for education, is an 
> exercise in ignoring reality.

There are several problems here.

1) "Fair use" differ between jurisdiction.  You later claimed to want
   to use the US's fair use interpretation.  Then I believe using the
   term "fair use" is confusing; my company is not based on the US so
   my lawyers would use a different "fair use" meaning.  If we are
   going down this route, call it "Us-Fair-Use" instead to make things
   clear.  As far as I recall, the international copyright policies
   also use the term "fair use".

2) Instead of referring to "fair use", why not simply include the
   permissions allowed through fair use in the actual license?  That
   make our intention more clear.  It could go into an informative
   section, if you want.

3) "Fair use" is an under-defined matter.  I believe the IETF should
   be able to decide what it wants in this area, and to document that.

4) This is the essential part of my objection.  There are educational
   uses that go beyond what is permitted through "fair use".  I
   believe the example in my presentation, about a university teacher
   including protocol-incompatible descriptions derived from RFCs, is
   such an example.  He doesn't want to criticize the RFC.  He doesn't
   want to comment on it.  He wants to give his student an exercise:
   to implement a protocol they can't download an implementation from
   the net for.

5) You forgot that educational use was only one of my examples.
   Another common example is where you take an existing RFC
   implementation, modify it to experiment with how well this works.
   This is how most Internet protocols evolve.  For example, the NSEC3
   work done in the DNSEXT WG break compatibility with the DNSSEC RFC,
   yet one of the patches to implement that proposal is based on BIND,
   an implementation that I believe incorporate portions of RFCs.

> As a temporary means of making progress, if Simon is willing to 
> temporarily withdraw his insistence that we support educational usage,

> we can temporarily avoid the "fair use" quagmire.  If Simon's 
> unwilling to do so, I will have to discuss "fair use" in the "field of

> use" draft I need to write.  Let me strongly suggest to Simon that he 
> should temporarily withdraw the educational aspect (i.e., so the WG 
> can first focus on what is necessary to support implementers, and then

> determine whether that + "fair use" is sufficient for educational 
> purposes or whether something else is required).  Simon?

I could stop insisting we support educational use, but I don't believe
it would help us get anywhere.  You still have other examples of where a
"field of use" rights doesn't work.

I hope my discussion above of why it is pointless for me to stop
insisting this is illuminating.  Don't get me wrong, I really do want to
see your text that include a "field of use" text.

I have thought about a "field of use" license, but I found it extremely
difficult to write it down without preventing simple things that I
believe should obviously be permitted (e.g., case 5 above). Then I
started to question what harm would be caused by permitting any
modifications (except, of course, attributing the modified work as an
IETF product, but that is a given), and I couldn't come up with
anything.

> As for Debian's "desert island" - I would prefer to focus on what the 
> GPL license requires, which is at the core of that story.

I'm not sure GPL is the core here, but anyway.

> Debian appears to go beyond GPL in rejecting non-binding requests to 
> send changes - IMHO, that's a mistake, as I not only believe such 
> requests are GPL-compatible, but I also believe that just as most open

> source developers would like to be told about bug fixes and 
> improvements to their code

I believe you are wrong here.  Essentially no open source code require
this right.  It is encouraged to send back changes, but no widely used
license require this.  Specifically, the GPL do not require this.  It
merely require that someone who receive the work should have access to
the modifications.  Not the original author.

> it's reasonable for the IETF to make similar non-binding requests that

> we be told about analogous bug fixes and improvements to our 
> protocols.

Agreed, although I believe you meant "binding request".  I believe a
non-binding request would be preferable.

> OTOH, I view the issues of whether such requests would
> be part of the formal "license" and how they interact with that 
> license as issues to be sorted out by the WG.

Right.

My opinion on that is that it serve no purpose to require third parties
to send changes back to the IETF.  Bad actors doesn't care whether the
IETF wants modifications back.  Good actors will send the changes to the
IETF because it is the right thing to do.  The harm caused by that text
-- Debian can't use the RFCs -- outweigh any benefit that I can see.

Thanks,
Simon

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

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

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 Nov 2005 10:06:46 +0100

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

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.

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

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

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

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

> 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

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Nov 2005 19:06:56 -0500

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

    Powers> (Changed subject to reflect broader scope of message) As
    Powers> best as I can tell, folks in this discussion are doing
    Powers> jumps and twists trying to resolve two separate issues,
    Powers> the use/modification/derivation/etc of "code" embedded in
    Powers> IETF RFCs (e.g.  ASN.1 schemas, source code, etc), and the
    Powers> use/modification/derivation/etc of normative text of the
    Powers> RFC documents.  In doing so, it appears that attempts are
    Powers> being made to resolve the discussion with a single
    Powers> solution when I believe the two can and should be
    Powers> addressed separately, as to me they merit very different
    Powers> solutions.

I would strongly prefer a single liberal interpretation to both
issues.

If and when the chair of this wg rules that the consensus of this WG
is not to pursue that approach I'd be interested in looking at
separating the issues.

--Sam