Subject: Please raise a DISCUSS on the WG meeting consensus, if you have one

From: Harald Alvestrand <[email-masked]>
Date: Mon, 27 Nov 2006 08:34:31 +0100

John, Frank:

pulling my WG Chair hat firmly down over my eyes....

the consensus in the WG meeting was:

> 1) Rights normally granted: Cite all, translate all, change code
> For: 12, Against: 0: Confused: 1

I read your last couple of messages as saying that you object to this 
consensus if "change code" means "change code without restriction".

If that is your opinion, please send a message to the list with a subject 
line of "DISCUSS: Rights normally granted".

If you do so, I'll open a tracker issue on this subject, and see if we can 
make a mailing list call on the issue.

                   Harald

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 27 Nov 2006 11:44:10 -0500

Harald,

I hate to do this, because I'm more ambivalent than what you
have interpreted from my comments.  But it probably needs to be
done and, worse, the whole can of worms needs to be put on the
table (noting that there is nothing below that I didn't say in
San Diego).  So...

--On Monday, 27 November, 2006 08:34 +0100 Harald Alvestrand
<[email-masked]> wrote:

>> 1) Rights normally granted: Cite all, translate all, change
>> code For: 12, Against: 0: Confused: 1

> I read your last couple of messages as saying that you object
> to this consensus if "change code" means "change code without
> restriction".

For the record, there were far more than 13 people in the room
and at least a few of us were sitting on our hands, either in
frustration at the general trend of the discussion or because of
a superceding concern.   I am not going to claim "silent
majority" here, but the count reported above does not
demonstrate a consensus, even in the room: it demonstrates the
result of a poll of a WG meeting that was fairly sparsely
attended and in which a number of people did not vote.   Recent
discussion on the mailing list also opens up options that were
not really on the table when the count was done.

There is a significant interaction between this and the recent
discussion about forking rights to code segments.  There is also
a vocabulary/terminology problem.  Specifically, there are two
types of changes to code or pseudocode that appears in RFC-type
documentation:

One is to map it from one programming language or environment to
another and, of course, to "compile" and execute the code,
without changing the underlying abstract algorithm or
information content of the data structure.  I believe that we
should define that, explicitly, as being part of "translate".
That is, IMO, what it is.  I have a vague recollection that
there is even precedent for treating it that way.   If we can do
so then, modulo the second issue, code isn't different from text
and we can move on.

The second is to make changes, not merely to the representation
form, but to the underlying algorithm or information content.
That makes me very anxious, especially if we do not have an
extremely clear definition of "code" and the difference between
it and "a few sentences that use pseudocode or
quasi-mathematical notation for clarity" (see "Broader Concern",
below).

Before I came to San Diego, I believed that unlimited rights to
make changes to code was simply a necessity.   Now we have a new
theory, based on an author's granting certain (transferable)
rights to the IETF but also licensing the code in other ways,
that gets us back closer to the principle of the author holding
and granting rights, rather than having the IETF do so as a
side-effect of publication.  So, I would like to see us explore,
very carefully, whether:

(1) "Translate" is sufficient, with any other rights being up to
the author (on the license-fork theory or otherwise).

(2) If we really want to, we can sensibly make "change code
without restriction" the default but permit authors to opt out
of it (but not out of "translate" as defined above), perhaps in
order to impose restrictions about sharing, for-profit use, etc.

---------

Broader Concern: I continue to worry about our inability to get
these things right the first time, or even the second or third
time, and about the consequences of continually shifting the
rules around.  I am especially concerned about that in the
context of the IETF granting outbound rights beyond those
granted to the IETF so it can do its work, and making permission
to grant those rights  a condition of participation in the IETF
process...  or of insisting that authors grant such rights in
some particular form.  Your comment in another note:

> I despaired of finding any statement that would allow all the
> things we think need allowing (wide implementation of IETF
> standards, and inclusion of implementations based on IETF
> standards in all sorts of products, including GPL and
> commercial product) and still imposing some restriction.

...just reinforces that fear.  I mostly agree with you about the
difficulty.  But, as Frank's comments indirectly point out,
there are legitimate reasons for being able to impose some
restrictions.   We need to remember that these decisions are not
without consequences: from my point of view, if a decision is
made that costs us even one active, productive, positive
contributor to the IETF, that is a fairly high price to pay and
the decision better have balancing value.

I also remain concerned that general exhaustion in the IETF
community about process work will make any claimed consensus in
this area the consensus of a relatively small number of Process-
or IPR-junkies rather than the community.   Under our
procedures, that type of consensus would not prevent our
approving this change, but would make it fragile and a greater
candidate than usual for some sort of "whoops, we need to go
back and tune that" discovery.  Unless there is considerable
confidence that we can get it right this time, I am very nervous
about basing grants of rights on definitions that seem to be
precisely tuned and aren't, especially if we are also giving the
IETF Trust the authority of interpretation.  Consequently,
unless we really sure that we can get it right this time, I
believe that we either need to be very narrow (forgoing
"outbound rights" that are not strictly needed for the IETF to
do its work and leaving those matters to permission and licenses
from authors) or we need to consider either copyright transfers
or transfers of unlimited relicensing rights to the IETF,
followed by IETF/IASA/Trust decisions about what to actually do
with that authority.

     john

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 27 Nov 2006 18:58:12 +0100

> pulling my WG Chair hat firmly down over my eyes....

You can't see anything in that position... ;-)

>> For: 12, Against: 0: Confused: 1

Yes, I've read the jabber log, and I agree with the spirit of 5.3.

Minus the last four words.  Maybe s/in any way desired/worldwide/
is better.  Or maybe a lawyer could tell us if "in any way desired"
is proper legalese, and necessary for the rest of 5.3 (218 words).

Simon's arguments that publishing example code within RFCs is better
than not publishing it -- because "modifications in any way desired"
might be not allowed -- were convincing.

Of course some readers would hate it if they can't do whatever they
like with the code, but they'd hate it more if they're forced to dig
for "some rights reserved" examples elsewhere.  With an RFC readers
know what they get, and in theory there's even a procedure to submit
errata if the code is buggy.

With example code published elsewhere it could be in some horrible
state, several MB PDF containing a few lines of C or similar.  So
if authors have some reasonable restriction like "I contributed it
to the IETF or to the Internet at large, use it as you see fit, but
don't steal it, share your improvements", then they should be free
to say so in their code, copied into the RFC.

The RFC author isn't necessarily the person who has written the code,
even if they're willing to remove that restriction maybe they can't,
or shouldn't.  Could something like RFC 4634 still be published with
an "in any way desired" clause ?  I doubt it, see chapter 1.1 in 4634.

Frank

---

From: Ted Hardie <[email-masked]>
Date: Mon, 27 Nov 2006 15:50:43 -0800

Inline.

>not really on the table when the count was done.

I've commented privately to John on this, but I will say that
I believe Harald's reporting of this as consensus of the room
is correct.  There was more than adequate time to discuss,
clear statements of the question, and offers of clarification;
people choosing not to comment is a normal part of any
working group meeting.

>so then, modulo the second issue, code isn't different from text

I don't think I agree with lumping this in with "translation", since
I believe the aim of that outbound right is to ensure that an
IETF RFC may be usefully distributed as widely as possible by making
the content understandable to as many human readers as possible.

I do agree that we likely need to be clear that including code or
pseudocode needs to include the rights to compile that code and use
its information content even if the invoking system does not use
the same machine language.  Granting the outbound rights only
to include the code in compendia of code would be pretty
pointless.  So adding "use code" to "change code" seems to
cover that for the purpose of the working group's input to
the lawyer's wordsmithing (obviously, they have to come up
with the eventual language).

If we want to have a consensus call on adding "use code" to  the list
of cite all, translate all, change code, I also hope it will go quickly.

<large snip>
>order to impose restrictions about sharing, for-profit use, etc.

Speaking as someone who has tried hard to get documents
through the current process with special-purpose licenses, let me
just say that allowing something complicated past the default
creates burdens on the standards process that make it
less useful.  I don't think we really want that, and I know I
don't.  If anyone does, I strongly urge them to come up with the small
subset of permissible not-defaults, so that the whole machinery
of the IETF does not have to grind into motion every time one of
these comes up.  I wish you good luck in getting consensus around
any such set, but I will be waiting in the bar with a drink for you,
since I suspect you will need it after even a short time at the effort.

				Ted

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 28 Nov 2006 08:31:50 +0100

Frank,

can you provide a proposal for text for 5.3 that creates the 
restrictions you want?

As I read your comments, you want to replace the text from 5.3:

>   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.
with something else. What?

                 Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Nov 2006 09:47:56 +0100

> an "in any way desired" clause ?  I doubt it, see chapter 1.1 in 4634.

There could always be exceptions. If we put out rules that don't
allow for exceptions, we know there will be trouble later. So
we need a variance mechanism.

     Brian