Re: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem

Ed Juskevicius wrote:

Ed - you nor the rest of this list is going to like this retort but I 
would ask that you read all of it prior to flushing the response.
> The purpose of this message is twofold:
>
> 1) To summarize the issues that some members of our community 
>    have experienced since the publication of RFC 5378 in November 2008, 
>    and
> 2) To invite community review and discussion on a potential work-around 
>    being considered by the IETF Trustees.
>
> Some I-D authors are having difficulty implementing RFC 5378.  An  
> example of the difficulty is as follows:
>
>   - an author wants to include pre-5378 content in a new submission
>     or contribution to the IETF, but
>   - s/he is not certain that all of the author(s) of the earlier  
>     material have agreed to license it to the IETF Trust according
>     to RFC 5378.
>   
Then the submission of such an assertion would be a criminal act of 
fraud by wire... and that is not a joke.
> If an I-D author includes pre-5378 material in a new document, then s/he
> must represent or warrant that all of the authors who created the  
> pre-5378 material have granted rights for that material to the IETF Trust.
>   
Something which by the way is physically impossible because of how the 
RFC2026 licensing model was setup. Hell even BCP78 and 79 exist under 
RFC2026 rules since they had to be published as such to get them into 
the channel to review and advance them to the BCP's. As such these all 
are moot... funny that eh?
> If s/he cannot make this assertion, then s/he has a problem.
>
> This situation has halted the progression of some Internet-Drafts and  
> interrupted the publication of some RFCs.  The Trustees of the IETF Trust
> are investigating ways to implement a temporary work-around so that IETF
> work can continue to progress.  A permanent solution to this "pre-5378
> problem" may require an update to RFC 5378, for example new work by the
> community to create a 5378-bis document.
>   
You mean a POST-5378 IP Disclosure Document. The issue is what happens 
to any derivative licensing which stems from RFC2026 based controls. And 
since 5378 is a derivative of the BCP78 document it is tied itself to 
the RFC2026 rules still too one could easily argue.
> The remainder of this message provides an outline of the temporary work- 
> around being considered by the Trustees.
>
> RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with the  
> authority to develop legend text for authors to use in situations where
> they wish to limit the granting of rights to modify and prepare
> derivatives of the documents they submit.  The Trustees used this
> authority in 2008 to develop and adopt the current "Legal Provisions
> Relating to IETF Documents" which are posted at:
> http://trustee.ietf.org/license-info/.
>   
RFC2026 will not allow this. In fact once published under RFC2026 those 
document's are cast in concrete as far as the license model is concerned.
> The Trustees are now considering the creation of optional new legend text  
> which could be used by authors experiencing the "pre-5378 problem".
>
> The new legend text, if implemented, would do the following:
>
>   a. Provide Authors and Contributors with a way to identify (to the
>      IETF Trust) that their contributions contain material from pre-5378  
>      documents for which RFC 5378 rights to modify the material outside
>      the IETF standards process may not have been granted, and
>   
Meaning that those documents would be published under yet another set of 
IP licensing constraints - So lets see that makes

    1)   Pre BCP78
             o-   Pure RFC2026 based licensing

    2)   Post BCP-78 publishing with Pre-BCP 78 licensing included
             o- Includes non-trust managed IP
             o- Includes trust managed IP

    3)   Post BCP-78 with pure BCP-78 licensing through the Trust
>   b. Provide the IETF Trust and the community with a clear indication 
>      of every document containing pre-5378 content and having the
>      "pre-5378 problem".
>   

Ahahahah - Oh damn that's funny. Try all of the RFC's published prior to 
(IMHO) the IESG's #$%^&*()_ act of putting BCP78 and BCP79 into production.
> So, how could the creation and use of some new legend text help people
> work-around the pre-5378 problem?
>   
It cannot. The RFC2026 Licensing model clearly must survive the original 
filing of the original BCP78 and its ludicrously funny and pretty stupid 
brother BCP79.
> The proposed answer is as follows:
>
>   1. Anyone having a contribution with the "pre-5378" problem should add
>      new legend text to the contribution, to clearly flag that it includes
>      pre-5378 material for which all of the rights needed under RFC 5378
>      may not have been granted, and
>   
They, according to the IETF submission process, cannot do this because 
the amended document supposedly has to be submitted under the BCP78/79 
Terms which is what we are saying doesn't work here. So this is clearly 
impossible.
>   2. The IETF Trust will consider authors and contributors (with the  
>      pre-5378 problem) to have met their RFC 5378 obligations if the
>      new legend text appears on their documents, and
>   
The TRUST isn't the issue - its the US Courts that are the issue.
>   3. Authors and contributors should only resort to adding the new  
>      legend text to their documents (per #1) if they cannot develop  
>      certainty that all of the author(s) of pre-5378 material in
>      their documents have agreed to license the pre-5378 content to
>      the IETF Trust according to RFC 5378.
>   
I would suggest that this also is not enough...
> The proposed wording for the new legend text is now available for your
> review and comments in section 6.c.iii of a draft revision to the
> IETF Trust's "Legal Provisions Relating to IETF Documents" located at
> http://trustee.ietf.org/policyandprocedures.html.
>
> Please note that the above document also contains new text in section 5.c
> dealing with "License Limitations".
>
> If your review and feedback on this proposed work-around is positive,
> then the new text may be adopted by the Trustees in early February 2009,
> and then be published as an official revision to the Legal Provisions
> document.  If so adopted, Internet-Drafts with pre-5378 material may 
> advance within the Internet standards process and get published as RFCs
> where otherwise qualified to do so.  Unless covered by sections 6.c.i or
> 6.c.ii, authors of documents in which there is no pre-5378
> material must provide a RFC 5378 license with no limitation on
> modifications outside the IETF standards process.
>
> The IETF Trust will not grant the right to modify or prepare derivative
> works of any specific RFC or other IETF Contribution outside the IETF
> standards process until RFC 5378 rights pertaining to that document have
> been obtained from all authors and after compliance by the IETF Trust
> with RFC 5377.  The Trustees will establish one or more mechanisms by
> which authors of pre-5378 documents may grant RFC 5378 rights.
>
> The Trustees hereby invite your review, comments and suggestions on this
> proposed work-around to the "pre-5378 problem".  The period for this review
> is 30 days.  Microsoft WORD and PDF versions of the proposed revisions are
> attached to this message.  Copies are also available on the IETF Trust
> website under the heading "DRAFT Policy and Procedures Being Developed" at:
> http://trustee.ietf.org/policyandprocedures.html 
>
> All feedback submitted before the end of February 7th will be considered by
> the Trustees.  A decision on whether to move forward with this proposal will
> be made and communicated to you before the end of February 15th.
>
> Please give this your attention.
>   
Ed this is garbage... If the earlier releases IP Owners will not 
formally change their licensing terms then the ONLY solution is that the 
original license terms for any initiative apply to any and all 
derivative works unless those works have more restrictive licenses. 

There is also an issue as to any physical works which were derived from 
those earlier licenses since they also would be constrained by those 
original terms too one would think. Further this is NOT rocket-science, 
its common sense. If work-product "A" contained specific IP then the 
uses of that IP cannot exceed the original licenses including being 
given to the Trust which RFC2026 doesn't provide for in any form. That 
means that the IETF may not in fact convey those document's to the Trust 
at all. They remain inside the IETF until those other licensees agree to 
relicense their work, and still anyone who was a relying party is still 
bound by the original RFC2026 release rules.

So as an example of how simple this is, take for instance work-product 
"A" which was filed under RFC20206 alone, and that means that the 
follow-on derivatives MUST also be totally contained/constrained by that 
same set of terms and conditions otherwise the original conveyance 
contract is flawed, and may be unenforceable.

Which brings us back to the issue of that the Trust MAY not rewrite 
licenses for any IP that the IETF processed under RFC2026 unless ALL of 
the parties - the people who wrote those drafts, the IP owners of that 
work and anyone who has relied on a SW or systems product fabricated 
under those licenses.

Wake up and smell the coffee... BCP 78 and BCP79 are a waste of time and 
were fabricated by individuals of questionable expertise since they 
pretty clearly have screwed the pooch on this one. Nice move Harald...

Todd Glassey
On behalf of the victims of the IETF Trust.
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf