Hi Barry, all, I’ve had a conversation with Jorge and Scott Bradner and have come up with the edits below as a result. Would these address your concerns?
OLD The WG will prefer algorithms or tools where there are verifiable reasons to believe they are available on an RF basis over algorithms or tools where there is RF uncertainty or known active IPR claims with royalty liability potential. The codec specification will document why it believes that each part is likely to be RF, which will help adoption of the codec. This can include references to old prior art and/or patent research information. NEW In keeping with BCP 79, the WG will prefer algorithms or tools where there are verifiable reasons to believe they are available on an RF basis. In developing the codec specification, the WG may consider information concerning old prior art or the results of research indicating royalty-free availability of particular techniques. Delete this sentence since WGs generally accept input from external parties all the time: The WG will accept and consider in its decision process input received from external parties concerning IPR risk associated with proposed algorithms. Everything else would remain the same. The above edits don’t change the kinds of things WG may want to do to help produce a codec that many parties can believe to be RF, but they stay closer to the existing BCP 79 language that we usually rely on. Alissa On Apr 20, 2015, at 3:27 PM, Barry Leiba <[email protected]> wrote: > Barry Leiba has entered the following ballot position for > charter-ietf-netvc-00-00: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-netvc/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > The IESG has discussed this issue on last week's informal call, and we > have asked the IAOC legal committee to comment. We have some > response so far, and we're waiting for Jorge to weigh in. > >> The WG will prefer algorithms or tools where there are verifiable >> reasons to believe they are available on an RF basis over algorithms > or >> tools where there is RF uncertainty or known active IPR claims with >> royalty liability potential. The codec specification will document why >> it believes that each part is likely to be RF, which will help > adoption >> of the codec. This can include references to old prior art and/or > patent >> research information. > > We are pretty explicit, in general, that working groups do NOT > evaluate patents and other intellectual property, and there are good > reasons for that. Some companies would have problems with their > employees participating in such discussions. Discussions of that > nature can put people into positions where they become aware of > patents they otherwise would not, and that their employers would > prefer that they didn't. > > I think that at the very least, we should loop the IAOC legal > committee and/or Jorge into this, and make sure they are/he is OK with > having anything about patent research information in a working group > charter. I know that many companies do not allow their employees to > do patent searches and evaluations without explicit permission. > > I worry that such a discussion will either make it impossible for some > people to participate, or cause some people's participation to > unintentionally violate their employers' policies. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I certainly support this charter. I have two concerns, one minor, one > not so minor. The not-so-minor one is above, in the "discuss" box. > > The minor one is here: > > << > 5. A collection of test results, either from tests conducted by the > working group or made publicly available elsewhere, characterizing the > performance of the codec. This document shall be informational. >>> > > I'm really happy that the deliverables are, in general, specified in > terms of what will be delivered, and not how it will be laid out in > how many documents of what sort. Thanks! > > Related to that: > I strongly urge that we strike the last sentence in item 5. Actually, > I prefer that we replace it with an explicit statement that the > collection might live in the working group wiki (or github, or > whatever), and might not be published as an RFC at all. But I'd be > happy with just striking the reference to publishing a document. > > > _______________________________________________ > video-codec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/video-codec _______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
