[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: #1400 Opinion poll - question draft
Yes.
> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:harald at alvestrand.no]
> Sent: Tuesday, December 05, 2006 2:55 AM
> To: ipr-wg at ietf.org
> Subject: #1400 Opinion poll - question draft
>
> This issue is now #1400 in the tracker.
>
> And I think it's time for one of my (in)famous opinion polls.
>
> First - let's see if I can get the question right. If it's
> OK, we'll go on
> to state opinions. So please do NOT spend bandwidth on
> stating your opinion
> now - this is about whether the question is right.
>
> Question formulation follows.
> --------------------------------------------------------------------
> We have two alternative formulations suggested for section
> 5.3 of the draft:
>
> 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.
>
> Draft authors or editors 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...
>
> ----------------------------------------------------------
> Remember: I AM NOT ASKING FOR PEOPLE TO STATE AN OPINION NOW.
> I am asking on whether the question formulation is "good enough".
>
> When trying to evalate responses, I intend to look at the
> number of people
> who choose A and B, and see how they match up with the 14:0
> distribution of
> people who stated an opinion in San Diego. If they all choose
> A, I'll count
> the 14 people in San Diego as preferring version 1; if they
> spread out,
> I'll evaluate it differently - if A:B has the same
> distribution as C:D,
> I'll just forget about reading anything into the San Diego poll and
> continue just based on the email poll.
>
> But this is the IETF, so it's NOT a vote; the purpose of the
> exercise is to
> figure out whether there is a rough consensus present, or
> whether there is
> a sizeable group of participants who agree that version 2 is
> better than
> version 1.
>
> A 51:49 outcome will decide nothing.
>
> Harald
>
>
> _______________________________________________
> 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