Brian E Carpenter <brc@xxxxxxxxxxxxxx> writes: > Simon Josefsson wrote: >> "Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx> writes: >> >>> >>> >>>> From: Brian E Carpenter [mailto:brc@xxxxxxxxxxxxxx] >>> >>>> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf