Subject: Fair use conclusion?

From: [email-masked]
Date: Sat, 12 Nov 2005 20:04:20 -0500

> 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.  An easy way to see this is that many
MIB modules are a sufficient portion of the containing RFC that extracting
the entire module exceeds what "fair use" could conceivably allow (and
cf. previous discussion about the need to make non-functional changes to
code extracts to deal with compiler/tool issues).

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.  Note that it's
impossible to create a fraudulent RFC based on this class of
extract (I think the closest one can come is to butcher a MIB
module, and people who do that get what they deserve ;-) ).

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.

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.

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?

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

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: Don Armstrong <[email-masked]>
Date: Sat, 12 Nov 2005 18:04:59 -0800

On Sat, 12 Nov 2005, [email-masked] wrote:
> usage, we can temporarily avoid the "fair use" quagmire.

The primary issue is that fair use rights aren't universal, nor are
they consistent throughout all jurisdictions. An ideal license
wouldn't require interpretation under the laws of a specific
jurisdiction in order to grant the rights necessary to exercise
whatever rights the WG decides are important. [Whether we can reach an
ideal license or not in the first steps is another question, however,
and I have no real opinion on that yet.]

> changes - IMHO,

Just to clarify, the "Desert Island Test" rejects binding requirements
to send changes,[1] not non-binding requests. [Where requests can be
ignored by the licensee.] Hopefully that makes more sense now.
Furthermore, such clauses in a license will likely be GPL
incompatible.

Don Armstrong

1: Specifically, requirements to send changes to people to whom the
changed code isn't actually distributed to.
-- 
<Clint> why the hell does kernel-source-2.6.3 depend on xfree86-common?
<infinity> It... Doesn't?
<Clint> good point

http://www.donarmstrong.com              http://rzlab.ucr.edu
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 12 Nov 2005 18:42:41 -0800

On Sat, 2005-11-12 at 17:04, [email-masked] wrote:
>  it's reasonable for the IETF to make similar non-binding
> to our protocols.

I think it's entirely reasonable for the IETF to make *binding* requests
for copies of derivative specifications based on our specs.

					- Bill

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 14 Nov 2005 02:08:53 +0100

Hi David,

[email-masked] writes:

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

> will be unusable in systems including Linux.

I believe that is the case currently.

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

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

> sufficient for educational purposes or whether something else

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.

> 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

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