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

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
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

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
<haraldalvestrand.no> wrote:

> 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".

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


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

Inline.

At 11:44 AM -0500 11/27/06, John C Klensin wrote:
>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
><haraldalvestrand.no> wrote:
>
>> 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".
>
>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.

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.


>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.

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>
>
>(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.

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

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