Subject: WG LAST CALL on the -outgoing document

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 06 Jul 2007 16:02:57 +0200

As of last week, the community has been able to see what I hope closely 
approximates a final version of our -incoming rights document: 
draft-ietf-ipr-3978-incoming-01, published June 28.

Given that this is now present, I believe it is time to start the WG Last 
Call on draft-ietf-ipr-outbound-rights-03.txt, published April 30.

This Last Call will run from today, July 6, 2007, and end in 2 weeks, on 
Friday, July 20, 2007, just prior to the next IETF meeting, where the IPR 
WG has a scheduled slot on Monday, July 23.

The list of issues raised against -outgoing will form one part of the 
agenda in Chicago; the other part of the agenda will be looking at 
-incoming.

IF YOU HAVE AN ISSUE WITH draft-ietf-ipr-outbound-rigths-03 going to the 
IESG for processing as a BCP document, please do the following:

- Send a message to the IPR WG list with a subject line of the format "LC 
ISSUE: OUTGOING <section>: <your issue>".

If you have an issue with the principles of the -incoming document, please 
do NOT use this format, but rather use a descriptive subject line, and have 
discussion on the list.

The chair will attempt to get all issues so noted into the issue tracker 
before Chicago, and we will go through them there.

The chair reserves the possiblity of not recording some issues, if that 
seems like obviously the right thing to do (for instance, if two people 
note exactly the same issue, only one will be tracked).

                        Harald

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jul 2007 09:59:26 +0200

It's inappropriate to use RFC 2119 terminology in this document.
Section 2 should be deleted and any use of the capitalized words
should become lower case.
(draft-peterson-informational-normativity-00.txt will tell you why.)

Section 3 is completely redundant and should be deleted.

Otherwise, I support this version for BCP.

     Brian

On 2007-07-06 16:02, Harald Tveit Alvestrand wrote:
> Given that this is now present, I believe it is time to start the WG 
> Last Call on draft-ietf-ipr-outbound-rights-03.txt, published April 30.
> 
> Friday, July 20, 2007, just prior to the next IETF meeting, where the 
> IPR WG has a scheduled slot on Monday, July 23.
> 
> - Send a message to the IPR WG list with a subject line of the format 
> "LC ISSUE: OUTGOING <section>: <your issue>".
> 
> If you have an issue with the principles of the -incoming document, 
> please do NOT use this format, but rather use a descriptive subject 
> line, and have discussion on the list.
>

---

From: [email-masked]
Date: Thu, 12 Jul 2007 11:19:21 -0400

I asked a lawyer to review the -outgoing document, and the following
text in Section 6.3 turned up a concern:

   As such, the rough consensus is that the IETF trust is to grant
   rights such that code components of IETF contributions can be
   extracted, modified, and used by anyone in any way desired. 

The concern is that the software licensing implications of that
text are not clear to someone who has not been following our
discussions and hence the text could be *misread* as permitting or
encouraging the use of licenses with copyleft (aka viral or
share-alike) and/or patent license provisions.

While it should be the case that code in IETF RFCs can be placed
under almost any software license, (including those with copyleft
and patent license provisions), the IETF Trust should not be doing
so on its own initiative.

Hence, in the outbound document, I think it would be good to add
a statement that the IETF Trust should avoid adding software license
obligations beyond those already present in a contribution, and noting
that both copyleft and patent license provisions in software licenses
depart from the goal of "extracted, modified and used by anyone in
any way desired," but also noting that the ability to place extracted
code under such licenses is an important aspect of "use in any
way desired."

This also impacts the inbound document, but that'll be a separate
thread.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Scott Brim <[email-masked]>
Date: Thu, 12 Jul 2007 13:47:49 -0400

> (draft-peterson-informational-normativity-00.txt will tell you why.)

The problem that Jon points to is that requirements documents aren't
normative but standards track RFCs reference them as normative because
they have what he (not 2026 or 2119) has decided to call "normative"
terminology.  Here we have a rather different problem, which is that
the definitions of must, should etc. in 2119 refer to
"specifications".  The spirit of use it the same -- this document is a
requirements document (just don't ask me to define that) and clearly
defining the use of must, should, etc. is a good idea, but the
definitions in 2119 make assumptions.  If you want to do it completely
correctly, you might copy the definitions from 2119 but removing
references to "the specification".

---

From: John C Klensin <[email-masked]>
Date: Thu, 12 Jul 2007 14:43:16 -0400

--On Thursday, 12 July, 2007 13:47 -0400 Scott Brim
<[email-masked]> wrote:

>> It's inappropriate to use RFC 2119 terminology in this
>> document. Section 2 should be deleted and any use of the
>> capitalized words should become lower case.
> The problem that Jon points to is that requirements documents
> aren't normative but standards track RFCs reference them as
> normative because they have what he (not 2026 or 2119) has
> decided to call "normative" terminology.  Here we have a
> rather different problem, which is that the definitions of
> must, should etc. in 2119 refer to "specifications".  The
> spirit of use it the same -- this document is a requirements
> document (just don't ask me to define that) and clearly
> definitions in 2119 make assumptions.  If you want to do it
> completely correctly, you might copy the definitions from 2119
> but removing references to "the specification".

Scott,

Thanks for bringing this up, but I think the problem runs a
little deeper.  As you point out, we are in danger of playing
word games here, ones in which terminology is given a specific
(and retroactive and individual) definition and that definition
is then used in lieu of thinking and common sense.   In addition
to the fact that we continue to confuse protocol specifications
and administrative and editorial ones in ways that do not serve
the community well, I see three separate issues in this
"normative" discussion.

(1)  When we have talked about normative references in the RFC
series, our definition has been principally tied to the notion
of "you need to understand that one in order to correctly
understand this one" and not to any notion of requirement
levels.  The latter tie is, I believe, original with Jon's
document.  Prior discussions and rules about normative
references and content (see, e.g., RFC 4897) have been
associated with maturity levels and stability, not requirement
levels.

(2) Historically, MUST/ SHOULD/ MAY language has been used
around the IETF with two separate, subtly different,
interpretations.  One interpretation has to do with standards
and conformance to them: these terms are used to express strong
and weaker conformance requirements.  The other has to do with
the practice of the protocol and risks to interoperability: if
one violates a MUST statement, one will almost certainly not
interoperate, while violation of a SHOULD poses some risks to
interoperability.   The first definition was used in RFC 1122
and RFC 1123; something close to the second appears to have been
intended in RFC 2119.

RFC 2119 was approved only after a fairly strong agreement that
it represented one set of definitions that could be used and
referenced, not that its definitions were mandatory.  If the
IESG now believe that they should be mandatory, I believe we
need to have the debate that we avoided a decade ago, keeping in
mind that at least one strict reading of 2119 implies that every
MUST statement in a protocol specification is required to be
justified by an interoperability analysis.

(3) I continue to believe, perhaps naively, that when a member
of the community, even an AD, posts an I-D, that is a proposal
and the beginning of a discussion, not a statement that is
sufficiently normative (sic) that it immediately imposes
requirement on how other documents are written.   If that is no
longer the case, we have far more serious problems than any
debate about an IPR specification.   The fact is that we have
extensive precedents for the use of "RFC 2119 language", or at
least uses of the words for which RFC 2119 offers a definition,
in administrative and procedural documents.  We can stop doing
that, but it seems to me that making elimination of that usage
into a hard requirement requires community consensus, not just
posting of an I-D.

      john

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Jul 2007 09:39:06 +0200

...

>    The fact is that we have

Completely agree. But I stick to my comment, and to the fact that
it's editorial. I have no objection to the MUSTs in the outgoing
draft but citing 2119 to justify them seems wrong to me. In fact,
I don't see what the document would lose if they were in lower
case.

    Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 15 Jul 2007 18:35:27 +0200

Thanks for alerting me to Jon Peterson's document.

I'll try to get it read ASAP, and will try to tone my reaction down by 
about 7 orders of magnitude from my initial reaction.

What is the proper mailing list for discussing Jon's proposed text?

                 Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Jul 2007 09:43:08 +0200

> What is the proper mailing list for discussing Jon's proposed text?

No idea...

For this WG, please forget I mentioned it. My point is only that "must"
is a perfectly clear English word and all we need for our draft.

     Brian

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Jul 2007 15:42:13 +0200

Issue #1499 has been assigned to this issue.

Brian E Carpenter wrote:
>> As of last week, the community has been able to see what I hope 
>> closely approximates a final version of our -incoming rights 
>> document: draft-ietf-ipr-3978-incoming-01, published June 28.
>>
>> This Last Call will run from today, July 6, 2007, and end in 2 weeks, 
>> on Friday, July 20, 2007, just prior to the next IETF meeting, where 
>> the IPR WG has a scheduled slot on Monday, July 23.
>>
>> IF YOU HAVE AN ISSUE WITH draft-ietf-ipr-outbound-rigths-03 going to 
>> the IESG for processing as a BCP document, please do the following:
>>
>> The chair will attempt to get all issues so noted into the issue 
>> tracker before Chicago, and we will go through them there.
>>
>> The chair reserves the possiblity of not recording some issues, if 
>> that seems like obviously the right thing to do (for instance, if two 
>> people note exactly the same issue, only one will be tracked).
>>
>>                        Harald
>>
>>
>>
>>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Jul 2007 15:43:51 +0200

Issue #1500 has been assigned to this issue.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 17 Jul 2007 17:34:09 +0200

> so on its own initiative.

I disagree -- I believe the IETF Trust should do what the IETF asks them
to do.  Limiting them to some set of licenses at this point seems to
short-circuit their ability to do their work.

There may be perfectly good reasons for the IETF Trust to release some
set of contributions under, say, the GPL.  For example, consider
software tools written for the IETF and assigned to the IETF Trust.

> code under such licenses is an important aspect of "use in any

I think this is somewhat confused -- the IETF Trust must decide under
which license outgoing contributions will be made available on.  They
can't use the -incoming license as the outgoing rights, since that
license only grants rights to the IETF Trust.  Thus, it is not trivial
to see what "adding software license obligations" really mean.  Some set
of obligations -- e.g., crediting the copyright owner and/or author --
may be perfectly fine.  The IETF Trust should be able to demand in a
license that users of the contributions retain copyright and/or author
notices.  Thus, I don't think your suggested modification is a good
idea, at least not without much more detail and consideration to avoid
unintended side effects.

/Simon

---

From: [email-masked]
Date: Tue, 17 Jul 2007 12:03:38 -0400

Simon,

Thanks for weighing in on this.

> software tools written for the IETF and assigned to the IETF Trust.

I think I agree with the latter paragraph, but let's focus on code in
Internet-Drafts and RFCs for now, and leave software tools for another
day.
 
> idea, at least not without much more detail and consideration to avoid

The concern is about adding obligations to outbound licensing of code
in Internet-Drafts and RFCs when those obligations have the effect of
restricting practical usage of the code beyond what is necessary (e.g.,
necessary to comply with whatever inbound terms and conditions were
used).
Copyright acknowledgements are not a problem here.  To be specific,
(IMHO) the IETF Trust should not be adding copyleft, share alike or
patent license terms and conditions to licensing of outbound code -
such terms and conditions should only be used for code that was already
under corresponding terms and conditions when it came inbound.  Whether
and under what circumstances these sorts of terms and conditions are
allowed for inbound code is an inbound issue for the other thread.

Thanks,
--David

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jul 2007 10:07:32 +0200

David,

I suspect you are asking for a few words too many by explicitly
mentioning copyleft etc. How about something a bit simpler like

The IETF Trust should avoid adding software license
obligations beyond those already present in a contribution,
so as to strictly maintain the right to extraction, modification
and use by anyone in any way desired (which may include
further derived works with additional license obligations).

     Brian

---

From: [email-masked]
Date: Wed, 18 Jul 2007 09:36:14 -0400

Brian,

That sounds reasonable (copyleft and patent licenses are
the things that concern my lawyers, but I think they can
be implied by this sort of language) - some minor tweaks:

The IETF Trust should avoid adding software license
obligations beyond those already present in a contribution,
so as to strictly maintain the broadest possible rights
of extraction, modification and use by anyone in any way
desired.  Extraction, modification and use of code outside
the IETF includes creation of further derived works
that may carry additional license obligations.

Plus a sentence to acknowledge Simon's concern:

The IETF Trust should preserve copyright notices that
accompany code and ensure that authors of code are
acknowledged in published RFCs and other IETF documents.

Thanks,
--David

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Wednesday, July 18, 2007 4:08 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: LC ISSUE: OUTGOING Section 6.3: vague s/w 
> licensing guidance
> 
> David,
> 
> >> to see what "adding software license obligations" really 
> mean.  Some
> > set

---

From: Ted Hardie <[email-masked]>
Date: Wed, 18 Jul 2007 10:49:09 -0700

>acknowledged in published RFCs and other IETF documents.

I think asking the Trust to ensure this is a bit odd.  What happens
if they discover that a published RFC does not have the correct
acknowledgement?  The RFC series is archival, and we don't want
to change that.  Are you suggesting that they be able to request
a new, obsoleting RFC be issued with the correct acknowledgement?
And who does this review for acknowledgement?  The Trust's
officers?

I think the IETF should be careful of correct acknowledgement
and should preserve copyright notices in cases where the
copyright notices are permitted (either by exception, as now,
or by some decision on what is  generally permitted), but
the review for this seems to me to belong to the parties submitting
the documents for publication and to the community as a whole,
rather than to the Trust.

Have I misunderstood your intent here?
				Ted

---

From: [email-masked]
Date: Wed, 18 Jul 2007 14:04:07 -0400

> Have I misunderstood your intent here?

I think we're in violent agreement.  Copyright notices need to be
preserved, and someone (need not be the IETF Trust) ought to be
encouraging mention of the code authors in the Acknowledgements
section of published RFCs.  I understand that RFCs are archival
documents that can't be changed once published.

Thanks,
--David

---

From: John C Klensin <[email-masked]>
Date: Thu, 19 Jul 2007 12:07:28 -0400

--On Wednesday, 18 July, 2007 14:04 -0400 [email-masked]
wrote:

> I think we're in violent agreement.  Copyright notices need to
> be preserved, and someone (need not be the IETF Trust) ought
> to be encouraging mention of the code authors in the
> Acknowledgements section of published RFCs.  I understand that
> RFCs are archival documents that can't be changed once
> published.

With the understanding that I'm in violent agreement too, the
place to try to ensure/ force this is with the introductory
boilerplate and "incoming", and the standard pre-publication
review to be sure those terms have been satisfied, not in trying
to either demand that the Trust do things it can't do or to
insert the Trustees in the pre-publication review process of
individual documents.

For example, we might want to consider modifying the assertions
that someone makes in requesting that an I-D be published to
include not only that everyone who should be acknowledged is
acknowledged but also that any required copyright or license
notices, especially for anything that might be construed as
"code", are preserved as needed.

But, again, it seems to me that those are requirements on
submissions, not requirements that the IETF Trust needs to write
rules about or try to enforce or validate on a case-by-case
basis.

   john

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 Jul 2007 18:03:02 +0200

below...

> documents that can't be changed once published.

Maybe weasel-word the 'should' with 'as far as possible'?

     Brian

---

From: [email-masked]
Date: Sun, 22 Jul 2007 14:33:47 -0400

Trying again with improved text:

  To the extent reasonably possible, the IETF Trust should
  preserve copyright notices that accompany code and encourage
  acknowledgement of code authors in published RFCs and other
  IETF documents.

I substituted "encourage" for "ensure" as I think that goes to
the heart of Ted's concern.

Thanks,
--David

> Sent: Sunday, July 22, 2007 12:03 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Jul 2007 20:24:01 +0200

That text sounds good to me.  Note that section 6.5 currently says some
rather opposite things wrt to additional copyright and license notices.
Replacing that text with your paragraph would be good.

/Simon

---

From: [email-masked]
Date: Tue, 24 Jul 2007 15:03:13 -0400

Section 6.5 is mostly about avoidance of additional licenses -
the word "copyright" seems to have snuck in there and ought to
be expunged (IMHO).   Thanks, --David

> From: Simon Josefsson [mailto:[email-masked]] 
> Sent: Tuesday, July 24, 2007 2:24 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 24 Jul 2007 15:23:12 -0400

The copyright text didn't sneak in.  It was the consensus as I was 
informed of it at the time.
If the consensus shifts, I am happy to remove the word copyright from 
6.5, while retaining the prohibition on multiple licenses.

Yours,
Joel