Subject: #1175 Code vs text

From: Harald Alvestrand <[email-masked]>
Date: Thu, 25 May 2006 13:09:45 +0200

In our list of open issues, we have this issue:

> If there are different rights granted to participants for working with 
> code than with non-code, it
> has to be possible for users to tell which is which. Suggestions include:
> - Defining it by type (C code, ABNF, MIBs...)
> - Defining it by marker (<code>/</code>)
> - Defining it by separate submission (file alongside draft)
> If there are no such differences, the point is moot.

There has been no discusssion with this issue number.
Based on the in-room discussion in Dallas, I suggest that we resolve it 
by saying (remember, this is informing the IETF Trust about the desires 
of the IETF community):

If a distinction needs to be drawn between code and non-code in IETF 
documents, the community desires that:

- Specifications in formal languages, including C code, ABNF, MIBs, 
ASN.1 and so on, are clearly "code".
- Tables such as the character lists in IDNA are to be regarded as 
"code" too.
- Prose, including "pseudocode" that does not claim any level of 
formality, is not "code".
- The IETF Trust should maintain specific guidance on what will be 
regarded as "code", including guidance on how to mark "code" in 
documents where doubt could exist; this guidance is expected to change 
more often than the IETF IPR rules.
- If there is ever a conflict over what constitutes "code" in a 
document, the IETF Trust can make a decision on the issue.

I think this communicates a desire of the community that it will be 
clear how to apply for the 95% case, and allows the IETF to decide on 
the borderline cases (if any) as we go along.

Comments?

                         Harald

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 27 May 2006 11:59:42 +0200

Harald Alvestrand <[email-masked]> writes:

>> If there are different rights granted to participants for working
>> with code than with non-code, it
> Based on the in-room discussion in Dallas, I suggest that we resolve
> it by saying (remember, this is informing the IETF Trust about the
> desires of the IETF community):
>

Agreed.

> - Tables such as the character lists in IDNA are to be regarded as

Sounds good.

> formality, is not "code".

I'm less sure here.

Compare RFC 2222 section 7.2.1 and section 7.2.2.  That is essentially
programming code described in prose.  When I implemented that section,
I translated the English words (without much additional creative
input) to C code.  This example is a not completely clear, but if
there is a document with text that is even more detailed than
2222§7.2, I suspect that it may be a clear copyright infringement to
translate it from English to C.

So I'd claim that pseudocode may be considered code too, as far as
copyrights are concerned, to be on the safe side [from the point of
view of developers].

> more often than the IETF IPR rules.

Sounds good, although I think the guidelines should be a BCP document
that is developed in the normal consensus way.  If this WG still
exists, it would be a suitable place to discuss the document, and any
updates to the BCP.  Otherwise, the general IETF list would work.

> document, the IETF Trust can make a decision on the issue.

I agree with John that this may put the IETF Trust in serious
problems.  Developing the guidelines as a BCP would reduce these
risks.

> the borderline cases (if any) as we go along.

I think that's incorrect, above you say that the IETF Trust would
decide this.  Thus, the "IETF" would not make such decisions.  The
only way for the IETF to influence the decision is by indirect
measures, such as replacing the members of the IETF Trust.  I believe
that is a too heavy-weight instrument to use when the IETF wishes to
influences the IETF Trust guidelines.  There seem to be no guarantees
that the IETF Trust takes the time to find out the IETF's wishes
before making decisions.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 29 May 2006 02:05:22 -0700

>copyrights are concerned, to be on the safe side [from the point of
A translation of pseudocode into C would constitute a paraphrase, I think.
I also think that it would be very hard to consider those two paragraphs 
"pseudocode" as the term is usually used; here is the first para of RFC 
2222 section 7.2.1:

   The client calls GSS_Init_sec_context, passing in 0 for
   input_context_handle (initially) and a targ_name equal to output_name
   from GSS_Import_Name called with input_name_type of
   GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
   "service@hostname" where "service" is the service name specified in
   the protocol's profile, and "hostname" is the fully qualified host
   name of the server.  The client then responds with the resulting
   output_token.  If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED,
   then the client should expect the server to issue a token in a
   subsequent challenge.  The client must pass the token to another call
   to GSS_Init_sec_context, repeating the actions in this paragraph.

>updates to the BCP.  Otherwise, the general IETF list would work.
My thinking here is that a WG process, or a debate on the IETF list, 
takes "forever" even for simple cases. And publishing BCP documents has 
an overhead of several months just in processing, even if we disregard 
the time spent in discussion. It shouldn't be necessary to invoke that 
overhead just because we want to add another formal language to the list 
of languages considered "code".

>problems.  Developing the guidelines as a BCP would reduce these
Comment about risk noted.
I do fear the consequences of not having anyone with arbitration powers 
- it gives people who want to block a process Yet Another Tool, throwing 
the system into a state where we can't make forward progress because 
nobody can decide which set of rules to apply.

Of course, that point is moot if the difference does not matter.

>that the IETF Trust takes the time to find out the IETF's wishes
If they don't, we'll have to fire them.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 29 May 2006 11:57:05 +0200

> A translation of pseudocode into C would constitute a paraphrase, I think.

The critical point, I guess, is if the C code would infringe on the
copyright of the prose.  Would a paraphrase not infringe?

> I also think that it would be very hard to consider those two
> paragraphs "pseudocode" as the term is usually used; here is the first
> para of RFC 2222 section 7.2.1:

I disagree.  I don't think it is unreasonable to call that pseudocode.

My point is that if text contains many details, that make the
translation into C code a simple mechanic process, there is a point
where I'd start to call the text pseudocode, and consequently have it
be subject to copyright rules that apply to pseudocode.  I'm not sure
7.2.1 has passed that point for me, but it is close.

In general, I believe the conservative approach would be to be lax
about the definition of "pseudocode", so it can include common things
that are translated into code.

Further examples are RFC 3490 section 4.1/4.2, and several parts of
RFC 3492 (e.g., section 3.4).  I think they have past the point, and
should be called pseudocode.  I think it will be difficult to come up
with a strict definition of pseudocode that would include those
sections, but rule out 2222§7.2.

> takes "forever" even for simple cases. And publishing BCP documents
> has an overhead of several months just in processing, even if we
> disregard the time spent in discussion. It shouldn't be necessary to
> invoke that overhead just because we want to add another formal
> language to the list of languages considered "code".

Maybe the process should be fixed, then.

Frankly, I really don't see the problem with using a BCP here.

The IETF will have the powers to make retro-active changes to future
documents for this area.  An overhead of a few months, and the work
required to push out a new BCP, seem to be a _good_ thing to me, not a
bad thing.  The time will help make sure that the community will have
time to review the updates, and the output reflects community wishes,
and that the powers are not abused.

Guidelines on copyright issues should not be changed on a whim,
_especially_ not by people that doesn't represent the copyright
holder.

> I do fear the consequences of not having anyone with arbitration
> powers - it gives people who want to block a process Yet Another Tool,
> throwing the system into a state where we can't make forward progress
> because nobody can decide which set of rules to apply.

Giving some set of people more powers because we can't be bothered to
write better and clearer rules sounds like an extremely poor idea for
an open organization to me.

Note that _better_ rules does not necessarily mean _more_ rules.

I believe part of the problem today is that there are too many rules.

> Of course, that point is moot if the difference does not matter.

I don't follow you here.  Do you mean the difference between code and
text?

If so, then I agree.  That's one reason I argue we shouldn't separate
text and code.  Separating them only create more rules, which are
poorly understood and followed.  The IETF isn't following its own
rules today (e.g., additional copyright notices), so I believe it
would be better if the rules would be simplified, not made even more
complicated.

> If they don't, we'll have to fire them.

If we instruct the Trust to make decisions on these matters
internally, the Trust likely won't take a few months to debate the
matter on the general list, to find out the IETF's wishes on this, and
we cannot fire the trust for following our instructions that say they
should decide on these matters internally.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 29 May 2006 23:05:47 +0200

> sections, but rule out 2222§7.2.
I don't think of those as pseudocode either.

When I say "pseudocode", I think of things like section 4.1.2 of RFC 
3419 - semiformalistic, and definitely not English by any metric.

The difficulty in defining "pseudocode" may argue against calling it "code".

                       Harald

---

From: "todd glassey" <[email-masked]>
Date: Mon, 29 May 2006 16:10:41 -0700

Harald
would you say a PERL or Python module constitute code? its pretty close to
English, and most Pseudocode is very close at one level or another to spoken
language.

Todd Glassey

----- Original Message ----- 
From: "Harald Alvestrand" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 29, 2006 2:05 PM
Subject: Re: #1175 Code vs text

                       Harald