"Money for nothing..." -

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

Guys - I think that the current IETF submission process is still flawed in 
that it requires that any and all submissions to the IETF for participation 
in its Standards Process become the property of the IETF formally for 'any 
and all uses' whether the IETF dynes to allow that material into its 
publication process or not and this is an issue.

Under contract law and contract must have proper consideration. If the IETF 
refuses to allow proper consideration/compensation for a submission, then 
that submission becomes a gift and the cash value of the gift immediately 
becomes an issue.

Also if the Intent of the submitter is to have the IETF publish the material 
and it doesn't, then the intent of the submission has been violated and as 
such the conveyance is null and void no matter what the IETF's website's 
boilerplate says. Contract Terms are clearly modified by the actions of the 
parties involved whether these contravene terms originally negotiated within 
the 'four corners' of the contract per the Parole Evidence Rule and the 
Statute of Frauds.

Which again brings us back to the value of the IP itself and that any and 
all work-product produced for filing with the IETF or inside the IETF's WG's 
or by other SDO's as part of a joint effort, has a clear and demonstrable 
cash value. The question is what to do about this - and whether the IETF 
(and the Trust)  is/are properly setup as a 501(c) type entities.


Todd

----- Original Message ----- 
From: "todd glassey" <[e-mail]>
To: "todd glassey" <[e-mail]>; "Harald Alvestrand" 
<[e-mail]>; <[e-mail]>
Sent: Wednesday, March 28, 2007 8:49 AM
Subject: Re: DRAFT minutes from Prague IPR WG meeting


> Jorge, Harald, SOB and Bellovin - What I propose to correct these 
> deficiencies is a simple and easily understood set of conveyance rules 
> which I think should be something like as follows:
>
>    1)    "By submitting this work and authorizing the transfer of its IP 
> Ownership to the ISOC's IETF, the submitter warrants that they are the 
> Legal Owner of those rights or the Legal Agent of the Owner of those 
> rights such that they may act as the Entity controlling those IP rights. 
> The Submitter further warrants that they assume all liability for those 
> acts and acknowledge that they understand  that the IETF's function as the 
> recipient of those IP's is to republish that material as a formal part of 
> its Standards and IP Disclosure Process".
>
> [Statement one essentially says that they (the submitter) have the 
> authority or Power Of Attorney for those works and that they can submit 
> them. Also that they  (the submitter) assume the legal responsibility for 
> those actions and that the IETF is NOT responsible for anything regarding 
> the submission and publishing of controlled IP's... this is more and more 
> a very important thing to deal with IMHO]
>
>    2)    "In submitting this IP to the IETF, the Submitter(s) warrant that 
> they intend to make this IP freely available to the IETF and its Standards 
> Processes 'for any and all reasonable uses' within that Standards 
> Process". They also acknowledge that Research Exemptions under US 
> Copyright Law will only apply to those instances where the reprinting of 
> those documents is performed as part of the IETF's Standards Process and 
> for no other reason. Any other reprinting of the IETF Documents is 
> performed under the IETF's 'outgoing use license' and is not supported 
> under the US Copyright Act's Section 107 (research exemptions)".
>
> [Statement two states the Intent of the part in submitting that material - 
> something that is also key to any conveyance of IP through the Net IMHO. 
> It also separates the uses of the IP from those interested in reprinting 
> the IETF's Libraries like Debian and Sun as well as those who are actually 
> reprinting the material as part of the IETF's Standards Process itself. 
> This addresses uses within and outside of the IETF's process properly 
> IMHO]
>
> [The next two statement's are cleanup to protect the IETF's use models 
> further... ]
>
>    3)    "In submitting this IP to the IETF, the submitter's license the 
> IETF to reprint this material for any and all uses pursuant to the IETF's 
> and the IETF's IP Trust's Operations, including all textual and code or 
> digital program content".
>
> [ Statement three deals with the uses by the trust as well... as 
> reaffirming Statement two's use for the IETF's Standards Process enabling 
> the Trust to operate as it was setup...(BTW - I still dont like the 
> Trust's makeup but that's another issue!]
>
>    4)    "In submitting this IP to the IETF the submitter's agree that the 
> IETF's rights include any and all textual and program derivatives produced 
> by the IETF, its RFC Editor's, its WG's, IETF Meeting's,  or other SDO's 
> external to the IETF, including but not limited to the simple reformatting 
> of the documents to meet IETF publication and style standards or likewise 
> to reflect vetting and other disclosure accomplished through the IETF's WG 
> Mailing Lists and Meetings per its Note-Well Process Definitions".
>
> [Statement four says that the derivatives in all forms are the IETF's and 
> possibly the IETF's Trust if it wanted to assign them all to it...]
>
> ---
>
> I think these four simple rules will allow any and all IP to be 
> transferred into the IETF and the intent of that transfer to be included 
> in the process.
>
>
>
>
>
> ----- Original Message ----- 
> From: "todd glassey" <[e-mail]>
> To: "Harald Alvestrand" <[e-mail]>; <[e-mail]>
> Sent: Tuesday, March 27, 2007 2:43 PM
> Subject: Re: DRAFT minutes from Prague IPR WG meeting
>
>
>> 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
> 


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