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

What is code? [Re: #1400 Opinion poll - question draft]



I thought we had agreed that "code" is text intended to be read by
a computer program.

It could be a data definition, a syntax definition, or an actual
program fragment. As far as I can see, it could be either normative
or informative, depending on the role it plays in the document.
I don't think those distinctions affect this discussion at all.
This is about the fact that for practical reasons, it may be
physically necessary to transform such code in order to make use of
it, and that is an exception to our general restriction on derivative
works outside the IETF process.

   Brian

Tom Petch wrote:
It is perhaps implicit, but I would rather it were explicit, that there are
other types of code than those listed in both questions;  The wording has
overtones for me that this is an exclusive list.  'XML Schema' sort of
implies the W3C schema but (I keep being told) RelaxNG is much simpler and
widely used in the Transport Area and then there is XML itself, while security
documents are littered with ASN.1 that will never see the inside of a MIB.  I
know we debated earlier what is code and I cannot see a resolution of that and,
as I say, the question sort of implies that this is what code is, period.

Tom Petch


----- Original Message ----- From: "Harald Tveit Alvestrand" <harald at alvestrand.no> To: <ipr-wg at ietf.org> Sent: Tuesday, December 05, 2006 8:54 AM 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


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