Re: DRAFT minutes from Prague IPR WG meeting

["todd glassey" <[e-mail]>]

Good work Harald...

Some commetary on what I think are still convoluted documents, I will keep 
them to
BCP78 in this commentary:

0) The claim is that the process of the IETF's standardization model
respects the rights of others as defined in BCP78's section 3.1, but this is
in fact not true based on the other clauses in the document. In fact all
rights for all uses are lost for any and all derivative works including
those from Vetting and WG activities as well... So there is 'no intent or
otherwise to respect any previously controlled rights" and if there were
there would be a more rigorous process for donating IP to the IETF.

Also there is an grating issue of "that contracts without proper
consideration are void for that lack of consideration" and the contract I am
referring to is the "gift of the IP to the IETF"... This is a key flaw in
the IETF's process today since if the IETF refuses to publish the
'submission' there is no proper consideration for the submission itself. If
it is a gift then there are tax implications for the submitter and their
organization at the very least and the IETF too probably which MUST be
reviewed...

By the way - as noted this "consideration" may be the publishing of the
document as a RFC or I-D... but without the 'appropriate consideration and
its valuation' the transfer of any IP to the IETF is at best questionable.
This is simple US Contract Law and is true in every major country I know of
as well.

Again ask Jorge for a formal opinion on this if you doubt my commentary

next stop is BCP78 3.3...

1) the "Unlimited License to modify and then use without any restrictions,
code submitted to the IETF as part of a standards process" which pretty
obviously means that the submitter will then no longer control that code or
its derivatives. See section 3.3 (a) (E) of BCP78 for more confirmation of
this commentary.

This clause totally eliminates any control of that IP once it is submitted
to the IETF which means that the submitter retains no rights whatsoever
including patentability. This is not just a (c) specific statement... all
the end-user rights are transferred to the IETF ...That's right - they are
all gone per this statement.

In fact the caveat at the end of the Statement which excludes Patent Rights
is ineffective IMHO based on the statement prior to it. ANY AND ALL USES
means ANY AND ALL USES including new and derivative patents, period. Adding
this new clause as a separate clause to the end of that statement makes the
validity of the statement and its enforceability questionable IMHO...

Bluntly the IETF and anyone who relies on their publications is free to do
whatever to the code/IP submitted after that including use it for any
purpose outside of the IETF Standards Process as directly noticed in (a)
(E).

Also again, there is the issue that the IETF's submission process should
require a signature to codify this. :-)


2) Likewise BCP78's sub-section (C) of 3.3 (a) is also flawed since all
works that are vetted through the process of the IETF's standards process
are derivative works... for which the initial submitter retains NO RIGHTS
whatsoever as far as I can tell. Those efforts belong collectively to the
Sponsors and the WG Members who do that vetting and are assigned by NOTEWELL
and Submission Rules to the IETF.

3) The Derivative Rights permissions under section 5.2 of BCP78 actually
prevent any vetting or republishing of the work either by the IETF/ISOC or
its RFC Editor, or by the WG itself. In fact these stop the standards
process dead in its tracks since NO Derivative Works of any type can be made
from submissions tagged as such including those defined in 3.3 (a) (E)...

4) Under the BCP78 Copyright Statement there is a clause that says:

      This document is subject to the rights, licenses and restrictions
      contained in BCP 78, and except as set forth therein, the authors
      retain all their rights."

Unfortunately the conflicting statements of 3.3 (a) (A), (B), and (E) and
those elsewhere make this (c) statement invalid IMHO. In submitting any
materials for publication the individuals lose all of their rights and so
this statement is void and unenforceable as far as I can tell.

Again - dont take my word for it, ask Jorge.

Todd
----- Original Message ----- 
From: "Harald Alvestrand" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, March 27, 2007 6:48 AM
Subject: DRAFT minutes from Prague IPR WG meeting


Thanks to Scott Bradner for compiling these minutes.

I have inserted various points from the slides; if you were present (in
person or via audio/jabber), please send any comment you have to the
minutes as soon as you can.

                     Harald

Date: March

I - agenda bashing: no changes

II - outgoing rights draft
   anyone wish to raise issues before going to IESG
   Simon (on Jabber) - I sent in a review
   Harald: who thinks its ready for iesg - no response
   Brian - ok but should be reviewed on mailing list
   no objections in the room to send to IESG but Harald will take
question to list

III - matching issues to resolutions
   Harald reviewed issues from issues list and the resolutions
1166 Quotations from RFCs and I-Ds
Resolution: Permitted
1167 Excerpt labeling
Resolution: SHOULD label, format as appropriate
1168 non-code excerpts
Resolution: Permitted
1169 Modified excerpts
Resolution: Permitted for code, not permitted for non-code
1175 How can code be distinguished from non-code?
Resolution: List of types of content + a marker mechanism – Trust maintains
1199 What license should the IETF grant to third parties on Contributions?
Resolution: Unmodified excerpts for non-code, excerpt & modify for code
1212 Copyright statements in I-Ds and RFCs: Meaning?
Resolution: Basically meaningless in I-Ds, relevant for RFCs
1237 Should incoming rights be published as 3978 delta or replacement?
Resolution: Replacement
1238 Should secretariat ask for IPR clarification from IPR holder on 3rd
party IPR
disclosures
Resolution: Yes. draft-narten-ipr-3979-3rd-party-fix approved in January.
1239 Understanding intent of participants
Resolution: None needed.
1400 Permission to modify code: Unlimited or restrictable
Resolution: Unlimited
no argument that these issues should be closed
   Harald reviewed issues that have not been resolved
1246 Incoming rights: How much should be said about outgoing rights?
Not resolved, punted to next agenda item
1273 How do we usefully define "excerpt"?
San Diego: Somebody else’s problem (closed)
1282 Should multiple copyright statements be permitted in I-Ds and RFCs?
Suggestion: none needed for I-D, RFC Editor matter for RFCs
Need the ability to do “joint” for joint publication. Need to avoid lots of
conflicting ones.
1337 Notices and Rights Required in RFC Editor Contributions
Proposal: RFC Editor’s problem (+IAB) – not the WG’s issue.
1338 Notices "normally placed at the end“ (raised in conjunction with nits
checker)
Word “normally” was chosen to be non-nonrmative. Don’t check.
1339 Does RFC 3978 3.3.a.(E) grant third parties rights to modify source
Jorge believes that license permits extraction & bugfixing.

close - what is an excerpt
multiple copyrights statements in ID - may need for other SDO
document
rfc ed specific text in incoming doc - consensus: should
be removed
others as on slide

IV - incoming draft
   add phrase that says what is normative and what is not
boilerplate - should it be there?
Scott Bradner - yes
Brian Carpenter - changes are painful but 1st set of
boilerplate important
Scott Bradner - do not need most of boilerplate - need
1st pp & exp date
Harald - conclusion: short boilerplate - with trust ok to change
John Klensin - should be in RFC and unchangeable or just
a pointer
Scott Bradner - how about pointer with text that says
text for start of ID that summaries responsibilities
of authors in light of bcp 79
Harald - how many support pointing to doc maintained by trust?
consensus in favor
   Harald -incoming doc structure:
abstract
defs
intro & descriptions
legal stuff

   John Klensin - need to have incoming stable before last calling outgoing
   Harald - do WGLC on outgoing but say that doc will not go to
IESG until incoming done to cover what -outgoing needs
   Ted Hardie (via Jabber) - not do IETF Last Call until incoming
document finished working group last call

meeting concluded






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


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