Subject: Status summary, IPR WG

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 04 Jan 2006 11:46:39 +0100

>From the chairs:

We believe that this is a fair summary of where the WG is today:

- The IETF at the moment DOES NOT HAVE THE RIGHT to permit derivative works 
to be produced from I-Ds or drafts outside the IETF process. The authors 
have that right, but the IETF has not been granted it.
This is a fact, and not something the WG can change, even if it wishes it 
was otherwise.
- The IETF SHOULD ask for that right in I-Ds, and MUST ask for it in I-Ds 
that become RFCs. This is what Scott's draft should accomplish.

With regard to outgoing rights - granted by the IETF to the community:

- The IETF rights are administered by the IETF trust. The WG should strive 
to encode the community's guidance to the trust, not to draft legal 
language.

- The rights that we have consensus that the trust should grant to the
  community are:
  - The community MUST be able to access, copy and redistribute RFCs
    and I-Ds freely, including permission to prepare translations and
    reformatted versions.
  - The community MUST be able to extract code and tables from the I-Ds,
    and process these according to its usual process. This includes
    incorporating them into products distributed under the GPL license,
    products distributed as "closed source", and modifications of these.

  - The trust SHOULD take steps to ensure that it's clear that modifying
    an RFC or a protocol and claiming that it's the "real" RFC or protocol
    is not permitted (unless such steps interfere with the more
    important goals above).

- The points that we have heard in the discussion that "seem like good 
ideas", but without enough discussion to be able to claim that there is a 
consensus, include:

  - The trust should permit quotations from RFCs and I-Ds, with permissions
    at least as liberal as US "fair use", and easy to figure out
  - The trust should give clear guidance on labelling excerpts from RFCs,
    for instance by recommending "extracted from RFC XXX" on unmodified
    text, and "based on RFC XXXX" for modified text (if permitted)

- The points that are still under debate include:

  - Whether or not all excerpts from non-code text should be permitted
  - Whether or not modified versions of excerpts from non-code text should
    be permitted

Does this seem like a fair summary of the discussion so far?

                  Harald and Steve

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 04 Jan 2006 08:43:14 -0500

This seems to me to be a fair summary of the discussion to date.
Yours,
Joel M. Halpern

At 05:46 AM 1/4/2006, Harald Tveit Alvestrand wrote:
>- The IETF at the moment DOES NOT HAVE THE RIGHT to permit derivative 
>works to be produced from I-Ds or drafts outside the IETF process. The 
>authors have that right, but the IETF has not been granted it.
>to encode the community's guidance to the trust, not to draft legal language.
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 4 Jan 2006 12:16:37 -0800

At 11:46 AM +0100 1/4/06, Harald Tveit Alvestrand wrote:
>- The IETF rights are administered by the IETF trust. The WG should strive to encode the community's guidance to the trust, not to draft legal language.
>

I do not think you have consensus on this.  There is consensus, I believe,
that the community needs to be able to extract code and tables from
the I-Ds.  "process them according to its usual process", though, is too vague
as guidance and "incorporating them into products distributed under the GPL license"
elides one of the problems.  If code derived from an RFC is GPLed, one of
the rights granted by the GPL is the right to modify the code; it is not
clear yet whether we can grant that right without granting the right to
modify the specification.

I believe that we have seen opposition from John, Dave, and me to the
IETF granting the right to modify the specification without reference to the
IETF standards process.

So, I do not agree with this aspect of the summary.
				regards,
					Ted Hardie

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 04 Jan 2006 21:49:54 +0100

--On onsdag, januar 04, 2006 12:16:37 -0800 Ted Hardie 
<[email-masked]> wrote:

>> - The IETF rights are administered by the IETF trust. The WG should
>> strive to encode the community's guidance to the trust, not to draft
>> legal language.
>>
> the I-Ds.  "process them according to its usual process", though, is too
> vague as guidance and "incorporating them into products distributed under
> the GPL license" elides one of the problems.  If code derived from an RFC
> is GPLed, one of the rights granted by the GPL is the right to modify the
> code; it is not clear yet whether we can grant that right without
> granting the right to modify the specification.

Ted, in an attempt at clarifying what you're saying when you say "I do not 
think you have consensus on this":

Do you believe that modifying code that was originally excerpted from an 
RFC can be construed as modifying the specification?

It's clear to me that it's possible to modify the code so that it's no 
longer compatible with the specification, but that's not what we're talking 
about.

I want to understand whether you are advancing the argument that such 
modification could modify the specification, or whether you are just 
claiming that such an argument has been made in the discussion.

> IETF granting the right to modify the specification without reference to
> the IETF standards process.

I believe that we have consensus that modification should not be permitted, 
if we can find processes that can ensure that without getting into the way 
(see my third point).

---

From: Ted Hardie <[email-masked]>
Date: Wed, 4 Jan 2006 14:17:57 -0800

At 9:49 PM +0100 1/4/06, Harald Tveit Alvestrand wrote:
>
>Ted, in an attempt at clarifying what you're saying when you say "I do not think you have consensus on this":
>
>Do you believe that modifying code that was originally excerpted from an RFC can be construed as modifying the specification?

I don't think it is clear.  Up to now, I believe code in many RFCs has been seen as one
of the elements of the specification, along with the free text description and
any psuedo-code.    That is, you didn't have to use that code to get interoperability,
but it was available for you to examine as you wrote your own code. 

I don't think that case is the real problem here, though; I think we're dealing
with situations like those where mapping tables are included in an RFC.  Any
code which is going to do the relevant mapping is going to use those tables or re-create
those same mappings.  Clearly, we want to allow folks to do that, since that is required
for them to follow the spec.  So we may want to allow those tables _as_code_ to be
eligible for inclusion in larger code bases.  If we decide that the
code in some RFCs is software distributed for inclusion in a larger code
base (rather than only for the purposes of elucidating a standard), there are
considerations that come into play that don't arise in the other case.

The main one, from my personal perspective, is how we use the distribution
of code to achieve interoperable behavior of implementations
(since that is usual driver for an Internet standard).  This is tricky because
things like these mapping tables are *both* part of the specification and code,
potentially available for inclusion in other code bases.  As specifications, we
do not want them modified without reference to the IETF standards process. 
As code, releasing them with a license that allows them to be included but not
modified limits their distribution.

I don't think the working group is yet clear on whether it is possible to
release these _as_code_ under a license like the GPL without affecting
their behavior as part of the spec.  If the IETF publishes mapping tables that say
code points 4E1C and 6671 are equivalent, and  you change your code to use mapping
tables in which  4E1C and 6671 are not equivalent, you  have clearly deviated
from the RFC.  If you change your code and then release it, with new mapping
tables that can similarly be excerpted, have you released a new specification
for the mapping tables?  How about if you publish those mapping tables
as an excerpt?  In general, when does that publication cease to be non-interoperable
code and become a modified spec?  For open source software, this is not a
frivolous question, as the local copy of the source for a mapping table may
be far more ubiquitous than an RFC.

I don't think we know yet if we can achieve the IETF's goal of producing stable
specifications of Internet standards and match specific licenses designed for
software.  It may be that we cannot, and we will have to work out a way of
publishing the specifications with pointers to code released under a license
different from the specification itself.  Maybe we can, using a form like
the lgpl or BSD.  But I don't think we have consensus on it now, and  I don't think
it is going to be that easy to work out. We might imagine requiring that any
modification be marked as a mod to the spec in the relevant RFC. 
We don't, however, currently require that any  implementation using an RFC
to do anything assert compliance with the RFC, so that would be a bit strange. 
And it is not clear whether that restriction would pass GPL or Debian tests
 (given the "advertising clause" issues between GPL and BSD in the past,
there is good reason to be cautious here).

I probably should not have gone this deeply into specifics, but I hope this
is at least marginally clearer now. 
			regards,
				Ted Hardie

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 04 Jan 2006 17:49:08 -0500

I think that we can usefully separate two things.
First. can we agree on the goal, with the assumption that we can find a way 
to achieve it.
And then, afterwards, can we find a way to achieve it.

If we have not agreed on the goal, the details don't matter.

If we do agree on the goal, I can think of two or three different ways 
that, with varying complexity, may be able to achieve the goal.  Possibly 
none of them will work.  But I see no reason to waste a copyright expert's 
time until we have agreed on the goal.

Hence, I concluded as a statement of agreement on goals, that Harald's 
description worked.

Yours,
Joel

---

From: John C Klensin <[email-masked]>
Date: Wed, 04 Jan 2006 20:27:10 -0500

--On Wednesday, 04 January, 2006 21:49 +0100 Harald Tveit
Alvestrand <[email-masked]> wrote:

>...
>> I believe that we have seen opposition from John, Dave, and
>> me to the IETF granting the right to modify the specification
>> without reference to the IETF standards process.
> 
> I believe that we have consensus that modification should not
> be permitted, if we can find processes that can ensure that
> without getting into the way (see my third point).

Harald, just to clarify my position on this, since Ted cited my
concerns...

As an author, I am willing to grant the IETF those rights, and
only those rights, that are needed to develop and maintain
standards and to permit those standards to be implemented and
interoperability to be evaluated.  I believe that includes
letting people copy and reuse, in code, code, tables, mappings,
and excerpts from published RFCs although I think we should
explore better ways to manage that.  I continue in the belief
that the IESG (not the IAOC, see below) should have broad
authority to interpret what is, and is not, needed to permit the
standards process to function effectively.

I do not believe that it has been demonstrated that extracting
and modifying (except with regard to format) RFC text to build
user-level documentation is required to implement standards or
test for interoperability.

I also do not believe that we should do anything that would
force (or even permit) the IAD or IAOC to get into the business
of making case-by-case decisions about licensing.  To do so
would require a rather different skill set in those people and
in those who select them.   As I've said in other circumstances,
I believe that the IETF should make policy and that the IASA
should administer and implement it only.

If proves impossible to devise a policy model by which the exact
rights that the IETF needs, and no others, can be released by
authors, my (distant) second choice is to transfer all rights to
the IETF with an irrevocable license back to the authors to
excerpt, derive, reuse, etc.

One way or the other, I think it is very important that authors
know, in a stable and predictable way, just what rights they
have and are able to enforce, i.e., that author rights not rest
on a vague grant to the IETF to relicense that, in turn, is
subject to buffeting by the changing winds of IETF politics and
the demands of those who are willing to yell most loudly and
most often at any given time.

    john

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Jan 2006 11:46:49 +0100

John C Klensin wrote:
...
> should administer and implement it only.

That's why the Trustees voted the following into the IETF Trust procedures
on December 15th:

"10.	The Trust shall be guided by IETF process documents, decisions of
the IETF leadership, and IETF consensus when licensing use of its
intellectual property in accordance with the Trust Agreement."

I don't think there's any contention about this point.

Now, I can't exclude that there might be special cases, requiring
a case-by-case decision; an example would be where the IETF desires
to hand a standard over to another SDO for future maintenance
(as we did with HTML, for example). But that doesn't change the
words quoted above - it's still the IETF that decides.

    Brian

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Jan 2006 05:58:25 -0500

Brian,

I think we are in agreement, perhaps violent agreement.   I was
only pointing out that some plausible evolution of the IPR
policies could, as a possibly unintentional side-effect of IETF
decisions, put the IAOC into exactly that case-by-case position.
I presume that is a position you don't want to be in either, but
that is a separate matter.

    john

--On Thursday, 05 January, 2006 11:46 +0100 Brian E Carpenter
<[email-masked]> wrote:

>> force (or even permit) the IAD or IAOC to get into the
>> business of making case-by-case decisions about licensing.
>> To do so would require a rather different skill set in those
>> people and in those who select them.   As I've said in other
>> circumstances, I believe that the IETF should make policy and
>> that the IASA should administer and implement it only.
>

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 09 Jan 2006 13:30:57 +0100

> We believe that this is a fair summary of where the WG is today:

Thanks for summarizing things.

> This is a fact, and not something the WG can change, even if it wishes
> it was otherwise.

Agreed.

However, I note that we could start a process to ask authors of
relevant earlier RFCs to grant the IETF this right.  This would result
in a change of that fact.  This WG could take on that work, or at
least produce a document that would describe the procedure to
performing that work.

> - The IETF SHOULD ask for that right in I-Ds, and MUST ask for it in
> I-Ds that become RFCs. This is what Scott's draft should accomplish.

Agreed.  With emphasis on 'should'.

> strive to encode the community's guidance to the trust, not to draft

I'm not sure this WG is the right place for such work, but it is
certainly a possibility.  I don't think you can declare consensus on
that issue without further discussion, and certainly not without a
charter update.

>    and I-Ds freely, including permission to prepare translations and

Agreed.

>    products distributed as "closed source", and modifications of these.

That assume the WG has decided to divide the outbound license into a
code and text license.  We haven't decided that, and the idea was
brought up fairly recently.  If you would declare on consensus on the
above, that would imply that we take on work to draft the license for
code-like material in RFCs.  But that would destroy the discussion of
whether or not the license on code and text should be divided.

>    is not permitted (unless such steps interfere with the more

That is poorly phrased.  The trust SHOULD take steps to ensure that
its license is clear.  Period.  If the license permit modified works,
then it should be easy to understand that.  If the license does not
permit modifications, then it should be easy to understand that.

> ideas", but without enough discussion to be able to claim that there
> is a consensus, include:
>

Note that the trust can't take away the "fair use" rights.

>    text, and "based on RFC XXXX" for modified text (if permitted)

Note that such language cannot be enforced legally without involving
trademarks.  The reference style on material borrowed under "fair
use", including modified material, is up to whomever adapt the
material.

> - The points that are still under debate include:

Please also include whether the license for code and text should be
separated.

> Does this seem like a fair summary of the discussion so far?

I think you should re-spin the summary after modifying it with the
input received so far.  To fully establish where we are now is useful
when deciding which direction we should go...

Regards,
Simon

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 9 Jan 2006 12:32:37 +0100

Yes, I agree it is a fair summary provided the words mean what I want them to
mean:-).

I am concerned about the code and tables, that is a more precise definition
thereof may show up disgreement, such as
a) what is code? eg are ABNF and FSM included? (I assume yes); I think the
constituents need nailing down sooner rather than later.
b) when extracting a MIB module, I always have a lot of editing to do to remove
those pesky running headers and footers - does this constitute modification?
Common sense says not, but common sense seems in short supply whenever lawyers
are around.
c) what is the status of information on the IANA website, much of which is
tables, but which also includes MIB modules derived from several sources, which
I would expect to be incorporated unchanged.  This may code or table in an RFC,
may come from expert review, may come from a text paragraph in IANA
Considerations, etc.  Derivative work, modified?  Do the rights we are talking
of encompass IANA?  I don't know (come to think of it, I have lost track of the
relationship of IANA to our new IAOC world:-(

Tom Petch

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 09 Jan 2006 13:49:04 +0100

> relationship of IANA to our new IAOC world:-(

That is an important aspect -- the IANA tables are useful as reference
material in products too.  Clarifying the license on the tables that
IANA publish would be useful.

Like Tom, I have also lost track of how IANA relates to the IETF in
the new IAOC world.  It is not clear to me whether the IETF has any
control at all of the license that IANA use for its publications.

Thanks,
Simon

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 09 Jan 2006 16:36:47 +0100

--On mandag, januar 09, 2006 12:32:37 +0100 Tom Petch 
<[email-masked]> wrote:

> Yes, I agree it is a fair summary provided the words mean what I want
> them to mean:-).
>
> I am concerned about the code and tables, that is a more precise
> definition thereof may show up disgreement, such as

I don't know (although I have opinions); I think we have consensus that 
there are things that are definitely "code" and things that are definitely 
not, but I think it's hard to nail down.

One heavyweight process for determining it would be to require the WG or 
individual submitting a specification to submit separately/alongside a file 
containing *only* the parts *he* thinks is code. I don't like it because 
it's heavyweight, an extra processing step, requires changes to the I-D 
process and runs the risk of losing consistency between the specification 
and the code - but it's possible.

> b) when extracting a MIB module, I always have a lot of editing to do to
> remove those pesky running headers and footers - does this constitute
> modification? Common sense says not, but common sense seems in short
> supply whenever lawyers are around.

Let's focus on figuring out what we want in this case; we *know* that the 
legal language doesn't come out right on the first try...... if we want to 
allow the extraction, we have to allow the extraction, so what you're doing 
is what we want to allow, whether a lawyer would call it "modification" or 
not.

> tables, but which also includes MIB modules derived from several sources,
> which I would expect to be incorporated unchanged.  This may code or
> table in an RFC, may come from expert review, may come from a text
> paragraph in IANA Considerations, etc.  Derivative work, modified?  Do
> the rights we are talking of encompass IANA?  I don't know (come to think
> of it, I have lost track of the relationship of IANA to our new IAOC
> world:-(

Me too.... I know what I'd like to view the work of the IANA as (work for 
hire, with the IASA being the hirer, and all IP rights assigned to the IETF 
Trust), but history makes this web uncomfortably tangled.

I think we should try to think of IANA as a situation we'd want to give 
IASA advice on, but they will have to take on the task of sorting out what 
the situation is....

                  Harald