Tom this would change the fundamental structure of the I-D
and RFC document
and what they contain I think. It also STILL doesnt address
that the IETF's
Standards Process MANDATES a second Interoperable Protocol
be built by one
of the parties involved in the Initiative... and without the
Derviative
Rights no one can legally claim that they have the right to
implement that
instance of that protocol.
Todd
----- Original Message -----
From: "Tom Petch" <nwnetworks dial.pipex.com>
To: "Harald Tveit Alvestrand" <haraldalvestrand.no>; <ipr-wgietf.org>
Sent: Tuesday, January 17, 2006 7:04 AM
Subject: Code and notcode was Re: Status summary, IPR WG -
Jan 17, 2005
> Agreeing unreservedly that the way forward is to treat
the two
separately - they
> may merge again later but I see separation at this
point as sound
engineering -
> I did encounter another example of (what I see as)
code, namely most of
RFC4134
> Examples of S/MIME Messages, most of which I would
expect to be fed
straight
> into a computer (or else a cure for insomnia
>
> I wonder too if code etc should be stored on a separate
web site, in a
easy to
> use by computer form, headers and footers removed.
That would make it
clear
> just what was covered by whatever conditions are
attached to code, should
they
> be different from those attached to text. It would
also make it easy to
attach
> something like
> 'By clicking on this to download, you agree to the
following conditions
....."
>
> Tom Petch
>
> ----- Original Message -----
> From: "Harald Tveit Alvestrand"
<haraldalvestrand.no>
> To: <ipr-wgietf.org>
> Sent: Tuesday, January 17, 2006 9:57 AM
> 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-wgietf.org
> > https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wgietf.org
> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
|