Harald the language of the reformulation is also wrong...But
that's OK we
can fix it.
And as a comment - ANY file which is transferred through a
computer
including text files would qualify and there is little
differentiation
therein. That said I propose a simple one paragraph fix.
How about:
----------------
"IETF contributions may include Text Alone, Formatted
Text, or other
inclusions meant to be interpreted by a computer or
computing device. The
purpose of the IETF's licensing to its relying parties is to
allow relying
parties to use these Standard's Design and those examples
shown in their own
products freely. The IETF thus authorizes the relying
parties to use and
develop derivatives of these contributions as their
implementation of this
IETF Standard from those sample programs or excerpts
therein"
----------------
So let me ask -Why bother giving it more detail than this -
that entire
statement is totally handled in the above??? Keep the policy
short and
applicable to the issue - the content of submissions.
T.
----- Original Message -----
From: "Powers Chuck-RXCP20" <Chuck.Powers motorola.com>
To: "Harald Alvestrand" <haraldalvestrand.no>; <ipr-wgietf.org>
Sent: Friday, December 08, 2006 4:53 AM
Subject: RE: #1400 Opinion poll - PLEASE REPLY
C - I was not able to participate in the San Diego meeting.
rgds,
Chuck
> -----Original Message-----
> From: Harald Alvestrand [mailto:haraldalvestrand.no]
> Sent: Thursday, December 07, 2006 6:33 AM
> To: ipr-wgietf.org
> Subject: #1400 Opinion poll - PLEASE REPLY
>
>
> This is it:
>
> We have two alternative formulations suggested for
section 5.3 of the
> draft. The change is in the second paragraph.
>
> 1) Original:
>
> IETF contributions often include components intended
to be directly
> processed by a computer. These may be ABNF
definitions,
> XML Schemas
> or DTDs, MIBs, or even classical programming code.
These
> are include
> for clarity and precision in specification. It is
clearly
> beneficial, when such items are included in IETF
contributions, to
> permit the inclusion of such code fragments in
products which
> implement the contribution. It has been pointed out
that
> in several
> important contexts, use of such code requires the
ability to modify
> the code. One common example of this is simply the
need to adapt
> code for use in specific contexts (languages,
compilers, tool
> systems, etc.) Such use frequently requires some
changes
> to the text
> of the code from the IETF contribution. Another
example
> is that code
> included in open source products is frequently
licensed to
> permit any
> and all of the code to be modified. Since we want
this
> code included
> in such products, it follows that we need to permit
such
> modification. While there has been discussion of
restricting the
> rights to make such modifications in some way, the
rough
> consensus is
> that such restrictions are likely a bad idea, and
are
> certainly very
> complex to define.
>
> As such, the rough consensus is that code components
of IETF
> contributions can be extracted, modified, and used
by anyone in any
> way desired.
>
> 2) Reformulation:
>
> IETF contributions often include components intended
to be directly
> processed by a computer. These may be ABNF
definitions,
> XML Schemas
> or DTDs, MIBs, or even classical programming code.
These
> are include
> for clarity and precision in specification. It is
clearly
> beneficial, when such items are included in IETF
contributions, to
> permit the inclusion of such code fragments in
products which
> implement the contribution. It has been pointed out
that
> in several
> important contexts, use of such code requires the
ability to modify
> the code. One common example of this is simply the
need to adapt
> code for use in specific contexts (languages,
compilers, tool
> systems, etc.) Such use frequently requires some
changes
> to the text
> of the code from the IETF contribution. Another
example
> is that code
> included in open source products is frequently
licensed to
> permit any
> and all of the code to be modified. Since we want
this
> code included
> in such products, it follows that we need to permit
such
> modification. While there has been discussion of
restricting the
> rights to make such modifications in some way, the
rough
> consensus is
> that such restrictions are likely a bad idea, and
are
> certainly very
> complex to define.
>
> As such, the rough consensus is that code components
of IETF
> contributions can be extracted, modified, and used
by anyone
> worldwide.
>
> Drafts and RFCs MAY state that substantial
> modifications based on the published code have to be
> "shared alike", i.e. published with a
similar proviso.
>
> There were 14 people who stated at the San Diego
meeting that
> they were part of a consensus for the first version.
While
> the second alternative
> was not explicitly put on the table in San Diego, I
think the
> debate has
> been circling around the issue long enough that it's
reasonable to
> consider these 14 as not supporting the second - but
it's
> better to ask
> than to blindly assume that. So I'll give more than two
alternatives:
>
> A) I stated a preference in San Diego, and prefer
version 1
> B) I stated a preference in San Diego, but prefer
version 2
> C) I did not state a preference in San Diego, and
prefer version 1
> D) I did not state a preference in San Diego, and
prefer version 2
> E) I have another opinion, which is...
>
> Please reply with a message stating which (single)
> alternative you agree
> with. If you wish to reply privately for less list
traffic,
> you can send
> your answer to the chairs. The list of names will be
included in the
> summary; your opinion will be known by others.
>
> Harald, for the chairs
>
>
>
>
>
>
>
> _______________________________________________
> 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
|