Subject: Minutes from Chicago

From: Harald Alvestrand <[email-masked]>
Date: Tue, 14 Aug 2007 14:30:24 +0200

First draft attached. Please comment ASAP.

                Harald

Intellectual Property Rights Working Group (IPR) Minutes

Meeting: IETF 69, Tuesday, July 24, 2007
Location: Red Lacquer room, 1740 - 1950 US-CT
Chair: Harald Alvestrand <[email-masked]>
Minutes: Scott Bradner <[email-masked]>
	 Version: 2
==================================================================
These minutes have been reformatted by HTA to follow
ION-agenda-and-minutes, version of 2007-03-16. 

1. Agenda bashing

Agenda was approved as published:

1740: Welcome, scribe selection, agenda bashing
1750: Outgoing document: Open issues from WG Last Call
- Use of MUST, SHOULD to indicate requirements
- Code "used in any way desired" - more explicit text about copyleft
or patent license issues?
- Other issues?
Hum on acceptance of the -outgoing document, with fixes as identified.

1820: Incoming document: Issues
- Software licenses: How do we ensure that the IETF Trust is in a
position to grant the rights desired in -outgoing, and are there cases
where that is not true, but publication is desirable?
- Other issues?

1850: End of meeting, unless discussion shows that the second hour is needed.

2. Resolved issues

Moved issue of copyright in IDs (#1212) to open
Moved issue of  multiple copyrights in RFCs (#1282) to open

Consensus in room that the other issues have been resolved: #1166,
1167, 1168, 1169, 1175, 1199, 1237, 1246, 1337, 1400

Consensus in the room that punted issues were reasonably punted:
#1273, 1338, 1339 - all with "details left to the IETF trust".

3. Outgoing document

3.1 Issue #1499 on use of RFC 2119 terms (MUST)

Brian Carpenter - brought up the topic but does not feel strongly about it
David Black - what does trust think 
Jorge Contreras - do not know
Jonne Soininen - trust does not care
Brian Carpenter - I withdraw the issue

The chair called consensus anyway, and the consensus in the room was
to use lower case instead of RFC 2119 terms

3.1 Issue #1500 - software licensing

David Black - report from corporate lawyer that the
current text is not clear - David has sent suggested text to list -
basically, trust should not add software licensing restrictions not
already in the text.
 
Consensus in room to add this text.

3.2 Issue #1282 - should multiple copyrights be permitted?

David Black - code often comes with copyright - should preserve
Scott Bradner - note that the purpose of the original text was to not
 permit this type of thing
David Black - common way to recognize author
Joel Halpren - multiple copyright leads to confusion as
 to usability
Jorge Contreras - have concern in RFCs - need to move to
 situation where trust is clear about what rights the trust has - also
 needed if need to enforce - rather than having to get all authors
 together to enforce rights
?? - some places additional copyright statements might be seen
 as endorsing moral rights - then in conflict with what the IETF can do
 with code
Stephen ?? - may be way to create legal language to make rights
 statements in code null & void 
David Black - any copyright should be only a one line & purpose
 is so that extracts will include the copyright - and that is a good
 thing
John Klensin - a problem if we move to a model that the trust
 owns doc w/o also having a clear license back to authors for the
 published doc
Jorge Contreras does not think it's an issue
Scott Bradner - using a bare copyright statement to give
 attribution is a big gun - 
David Black - maybe have trust come up with a form for
 attribution
John Klensin - bare copyright an issue
Joel Halpren - people can put comments code - we do not need to
 have the trust do this
Stephan ?? - issue came up when open source folks contribute
 code and want to include the open source copyright
David Black - write a FAQ to say its ok 

Consensus call:
Is it ok to have copyright statements in code in RFCs? -
The consensus was no, by a count of roughly 6:1. We do encourage
acknowledgement of authors, also in comments in the code, but not by
putting in copyright statements.

David Black - text on list was to encouragement of
acknowledgements of authors in code

3.3 Issue #1212 - Copyright statements in I-Ds and RFCs

Harald Alvestrand - placing copyright statements where
 we do not have copyright does not make sense (e.g. singe author IDs) -
 but some IDs that are many authors - but cannot tell difference - 
Jorge Contreras - any collection will have a copyright owned by
 authors - want trust to have copyright to be able to enforce copyright -
 even single author RFC because want to enforce 
David Black - boilerplate is IETF owned - that presents a
 barrier to creation of fake RFCs
Stephen ?? - if no copyright in ID means that other SDO could
 steal and modify text - is it so important to not have copyright in IDs?
Joel Halpern - agree - need to protect IDs, but collaborations
 are not collective works under Jorge's description
John Klensin - if we believe that IDs are working documents then
 there is no reason to think that the IETF trust can grant rights to IDs
Harald Alvestrand: proposal - do not require copyright in IDs
Scott Bradner - if authors put copyright statement in ID then
 they cant claim that this was done w/o their agreement
Brian Carpenter - proposal - maybe require statement in ID that
 says "if published copyright IETF Trust"
Jorge Contreras - maybe "portions copyright IETF Trust" - note
 to Joel - collaborative work is the same 
Russ Housley - republished ETSI doc was very beneficial -
 problem comes up from time - and should be able to be done
Harald Alvestrand - consensus call:

We do not require "IETF Trust" copyright notices in I-Ds. We do
require them in RFCs. Consensus (headcount about 12:1).

3.4 Other issues

Henrik Levkowetz - Simon suggested start and end of code markers
 - are we discussing this?
Harald Alvestrand - no 

3.5 Consensus call for -outgoing readiness for IESG

Harald Alvestrand - is doc ready to go to iesg if above changes
 made - consensus yes
John Klensin - should have WGLC on incoming before closing this
 doc
Harald Alvestrand - agree - will say issues on outgoing doc are
 in scope when last call on incoming
consensus - no known issues, but take it to the list.

4 Incoming rights document

4.1 Software licenses

David Black - problem with software licenses when it conflicts
 with licenses grants specified in -incoming, there will be exceptions
 and RFC 2026 variance process should be used
Jorge Contreras - trust has right to deal with license 
John Klensin - no, that right was withheld from the trust when
 IASA was created - don't go there
Harald Alvestrand - if software license is incompatible - talk
 to author for a compatible grant

4.2 Should we include text to tell trust to license back to authors

John Klensin - no - it needs to be part of license agreement
 author has when submitting
Joel Halpern - -inbound can just say that the license includes
 the right for author to make extracts etc - i.e.' imbedded in license
 author gives trust - look at SPARC addendum -
 http://www.arl.org/sparc/author/addendum.html

The room registered general support for the ideals behind the SPARC
addendum, and requested that appropriate language be included in
-incoming.

Consensus call: should IDs have to include "if published as an RFC the text
"copyright IETF Trust will be added" (exact text to be in the
instructions maintained by the Trust)?

Consensus - yes

Consensus call: Should we permit multiple copyright statements for the whole
document?
Consensus to continue with current practice, which requires IAB approval.

5. Next steps 

please review documents and comment if you have comments
The chair will hold outgoing until -incoming last call is over.
The chair will then send the two to IESG together

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 14 Aug 2007 18:55:45 +0200

Since 2 people have commented that they didn't get the linebreaks, I'm 
resending..... you can also look at the minutes on the IETF website.

1. Agenda bashing

1850: End of meeting, unless discussion shows that the second hour is 
needed.

2. Resolved issues

3. Outgoing document

Consensus call:

3.4 Other issues

4.1 Software licenses

Consensus - yes

5. Next steps

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Aug 2007 09:11:11 +0200

These look accurate to me.

    Brian

---

From: John C Klensin <[email-masked]>
Date: Wed, 15 Aug 2007 09:08:15 -0400

Harald,

Two small suggestions...

--On Tuesday, 14 August, 2007 18:55 +0200 Harald Tveit
Alvestrand <[email-masked]> wrote:

>...

the "right" being referenced was for the Trust / IAOC to start
making policy for the IETF in this (or any other): IASA
interprets and administers the rules but does not have any
authority to start making them.  IMO, that restriction includes
dealing with licenses in the sense in which that topic was
discussed at the meeting.

>...

>  http://www.arl.org/sparc/author/addendum.html

Since there has been some subsequent confusion and I thought
things were clear at the meeting, it is worth noting that SPARC
only involves author retention of rights to the text as handed
over to the publisher's editing process, i.e., it avoids
transfer of copyright to the publisher.  The RFC tradition, as I
have understood it for the last 30-odd years, is that the
authors retain substantially all of the rights in the version of
the document as published that they had to the version submitted
(e.g., including changes made by the RFC Editor).  That suggests
that we need either a SPARC superset or SPARC plus additional
language that applies its provisions to the post-editing/
post-compilation version as well as the submitted original.

And, since the minutes seem to be reflecting a "he said" style,
I think I bear the blame for bringing up SPARC, not Joel.

regards,
    john

---

From: "todd glassey" <[email-masked]>
Date: Wed, 15 Aug 2007 08:25:00 -0700

John -
I dont think bringing up that the IETF will suffer from not being in 
compliance with SPARC is a bad thing. As a 'trustee in the process' - i.e. a 
stakeholder in the IETF, you showed foresight and vision in bringing this 
up. So I think its a good thing that this WG has been apprised of SPARC and 
what its implications to the IETF are.

Todd