[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Status summary, IPR WG - Jan 17, 2005



>  - 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 fair use doctrine is narrower than you may think.  I would not reference
this legal standard, but try to specify exactly what types of 
extracts/quotations should be permitted.


-----Original Message-----
From: ipr-wg-bounces at ietf.org [mailto:ipr-wg-bounces at ietf.org]On Behalf
Of Harald Tveit Alvestrand
Sent: Tuesday, January 17, 2006 3:57 AM
To: ipr-wg at ietf.org
Subject: Status summary, IPR WG - Jan 17, 2005


Trying to summarize the situation again, hopefully having refined the 
understanding of the issues somewhat:

>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 do the modifications needed to use them in implementations of
    the standard.

  - 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

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

  - It is important that authors know, when they submit contributions to
    the IETF, which rights they are granting to the IETF, and what they
    can expect the IETF to do with them

- The points that are still under debate include:

  - Whether or not permission to use code for other purposes than to
    implement the standard should be given - this affects whether or not
    the license granted by the IETF can be GPL-compatible

  - 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

  - How to define the division between "code" and "text" (C code and
    MIBs are clearly "code"; ABNF and mapping tables may be)

  - Whether or not there are more categories of stuff than "code" and
    "text" (Ted mentioned mapping tables as a special case)

  - What it means to "modify" a standard

  - What measures are helpful to forbid modification of a standard;
    whether protecting the "RFC format" is sufficient to prevent it,
    or whether other measures such as field-of-use for extracts from
    code are relevant

  - Who should make decisions on licensing, if case-by-case decisions
    are permitted or desirable

Notes that may be important:

 - "fair use" is an US legal concept, and a fuzzy one. We'd like to
   make sure everyone, everywhere in the world has the same rights.

 - one fairly heavyweight means of separating "code" and "data" is
   to have the author mark them up in the document, perhaps even
   extracting the "code" bits at contribution submission time

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

                  Harald and Steve


_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg

_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg