Todd, Thank You for your comments. I've read them. Carefully. Three times.
I'm not sure if we are on the same page.
For example, you wrote:
> 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.
The IETF Trust is not looking for a way to rewrite licenses for IP processed
under RFC2026. That is not the objective or the driver of the proposed
revision to the Trust's "Legal Provisions" document.
You also wrote:
> ... If work-product "A" contained specific IP then the used 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.
Could you please point me to text in RFC2026 that pertains to the above?
When I read 2026, I see the following:
10. INTELLECTUAL PROPERTY RIGHTS
10.3. Rights and Permissions
10.3.1. All Contributions
l. Some works (e.g. works of the U.S. Government) are not subject to
copyright. However, to the extent that the submission is or may
be subject to copyright, the contributor, the organization he
represents (if any) and the owners of any proprietary rights in
the contribution, grant an unlimited perpetual, non-exclusive,
royalty-free, world-wide right and license to the ISOC and the
IETF under any copyrights in the contribution. This license
includes the right to copy, publish and distribute the
contribution in any way, and to prepare derivative works that are
based on or incorporate all or part of the contribution, the
license to such derivative works to be of the same scope as the
license of the original contribution.
I believe the text (above) is quite broad and does permit an author (today)
to prepare a derivative work from a pure 2026 licensed work, and then submit
that derived work into the IETF process. RFC 5378 is the current BCP with
respect to rights in IETF Contributions; it replaces all of the text in
Section 10 from RFC 2026. 5378 requires new author(s) to make some clear
statements about rights to and for the IETF Trust.
The issue for some authors today is that they may not be able to assert that
the original licenses (covering some earlier work that they may be using)
would allow for use of the new work outside of the IETF process. Sam
Hartman identified this concern during the IETF Plenary in November 2008,
and that was a trigger for the "work-around" proposal which the Trustees
sent out for review to everyone a few hours ago.
BCP78 is not, in my personal opinion, "garbage". Rather, I think it is
incomplete with respect to providing guidance on how pre-5378 content in new
contributions should be handled. That issue is the driver for the proposed
(and temporary) work-around (per below), and it is also the reason I said
that a permanent solution may require new work by the IETF community to
update RFC 5378.
Regards,
Ed J.
-----Original Message-----
From: TSG [mailto:tglassey@xxxxxxxxxxxxx]
Sent: January 8, 2009 6:21 PM
To: Ed Juskevicius
Cc: 'IETF Discussion'; ietf-announce@xxxxxxxx; iesg@xxxxxxxx; iab@xxxxxxx;
rfc-editor@xxxxxxxxxxxxxx; wgchairs@xxxxxxxx; 'Trustees'
Subject: 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf