Brian E Carpenter <brc(_at_)zurich(_dot_)ibm(_dot_)com> writes:
Simon Josefsson wrote:
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
From: Brian E Carpenter [mailto:brc(_at_)zurich(_dot_)ibm(_dot_)com]
Its purpose is to give the IETF control of its own IPR, which has
previously been held by 3rd parties. (That's not the legal
statement of purpose in the formal Trust Agreement.)
What we then do once we have such control is then something we can
discuss and reach consensus on. Part of that discussion is already
happening in the IPR WG.
That is an interesting approach.
The reason I raised the point was that I suspect that there will be many
members of the IETF community who would prefer to have the debate on use
before they have surrendered control.
I agree.
As I already pointed out, the rights we will get when the Trust
is signed into existence are only the rights that the Settlors
currently have; they will be moving from two bodies over which
the IETF has *no* control (CNRI and ISOC) to a body whose Trustees
are appointed according to RFC 4071.
That is true, but irrelevant to my point.
The IETF Trust should be allowed to grant licenses to their IPR
without requiring the licensee to grant back all rights to derivative
works. The IETF Trust doesn't have to use that ability. For most
licenses, requiring the licensee to contribute back all rights to
derivative works would be useful.
It seems this process is being rushed through before all issues are
settled or even discussed.
I imagine we'll be discussing IPR issues for the next twenty years
at least. What we are doing *now* is moving some of the IPR into
the IETF's control.
No, some of the IPR that is moved into the IETF Trust will, under the
updated IETF Trust license, not be under IETF's control. For example,
the IETF cannot grant a third party the right to use IETF IPR without
giving up all rights to derivative works. I know RFC/I-D's are
excepted now, but there are other material which the IETF may decide
to grant third parties rights to.
I'd feel more comfortable if the outbounds right issue was settled,
before all IPR is signed away to some external body that, to me, it
seem unclear whether the IETF has total control over.
That is completely wrong. We are moving *some* IPR, not all, from bodies
where the IETF has no control to a body that exists only for the benefit
of the IETF.
Right. And the license in which the IETF Trust should permit all
things the IETF may decide to do. Otherwise we lose the control over
the IPR.
The license text that went out for final review was clearly
insufficient, and would have made it impossible for the IETF community
to fix things later on. The IETF would not have been in control of
the IPR if that license would have passed.
That isn't a license, it is a Trust Agreement that sets boundary
conditions.
That's hair splitting. The boundary conditions imply what flexibility
the license can have. If the boundary conditions are too narrow, all
licenses are not possible. That restrict the IETF's ability chose
some licenses.
The community objected to one of the boundary conditions, and we
fixed it. That was the purpose of the community review.
Right.
I stress this: All past IETF IPR would appear to have been lost and
out of control for the IETF community if the initial legal document
had passed.
Absolutely not. That is completely untrue. There was an unintended side
effect on derivative works, and we fixed it. If we hadn't been able to
fix it in the Trust Agreement, we would have found another way to fix it.
You fixed it only for RFC/I-D's, not all material.
Giving the community 3 additional days to review the revised legal
document, to identify similar problems, is ridiculous. (Brian's
announcement of the updated section 9.5 was posted on December 5th,
and the deadline extended to December 8th.)
Yes, well, some of us take weekends sometimes. Also, this point was
raised with the IAOC during the Vancouver meeting; we didn't rush
the fix.
Was this discussed in public? If not, the fact remains that the
community were given 3 days of review time for the updated text. If 3
days isn't rushing the fix, I don't know what is.
The problem raised and the fix was non-trivial. The normal procedure
when that happens for a technical document would have been to have
another last call. It may have been wise to follow the RFC 2026
procedures when attempting to reach consensus on this work.
Please, give the community more time to review this.
Unfortunately, we need to close on these documents before the
holidays. Sometimes, we have to work 'just in time.' I would
have been much happier if we could have exposed the draft
several months earlier, but it just wasn't possible.
I understand, but still feel this was rushed ahead. I don't
understand why there is a hurry to move this forward now.
Thanks,
Simon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf