[MPEG-OTSPEC] Patent policy and process

[Levantovsky, Vladimir]

On Wednesday, August 19, 2020 2:07 PM Norbert Lindenberg wrote:
> On Aug 18, 2020, at 19:59, Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com<mailto:Vladimir.Levantovsky at monotype.com>> wrote:
>
>> On Tuesday, August 18, 2020 3:15 AM Norbert Lindenberg wrote:
>>
>> I’d like to have a forum where font rendering implementors, font developers, font tool developers, text application developers, script experts, and others with relevant expertise can collaborate on roughly equal footing. It’s unavoidable that implementors in the end have a stronger voice because without them it’s all just talk, but I think it’s essential to get out of this situation where a single company or person can control the process.
>
> Agree completely that we need to make sure that every voice is heard on equal footing. On a few occasions, I mentioned that this AHG strives to make our decisions based on consensus, which means that anyone who has a valid concern should be able to bring it for consideration of the group, and these concerns have to be resolved to make a progress. At the same time, the mechanism to resolve a blocking objection should also be in place if reaching a consensus decision becomes impossible – I very much like [and for many years have followed] one of the basic HTML design principles: “In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.” I believe we can adopt it pretty much verbatim.

That’s a good principle, but doesn’t actually resolve anything when there’s disagreement between implementors and specifiers (the main people in the room) over what’s best for users and authors (who for the most part are not present).

It depends. Even if we don’t have users represented in the room, if a good case can be made that one solution is going to benefit users more than another, reasonable people would agree. For example, when deciding on web fonts implementations, it was clear to me that effective font-specific compression would be a valuable and needed component (and I argued for it since 2008 when first Monotype proposal was submitted). But then an argument was made that widely supported minimally viable solution would offer far better outcome for the users than a great solution that is only supported by a single browser vendor, and I agreed (here comes WOFF 1.0). As web fonts adoption using WOFF1 skyrocketed, it became clear to _everyone_ “that effective font specific compression would be a valuable and needed component”, and no one ever argued against WOFF 2.0. So, these basic design principles worked exactly as they should! ☺
>> Standards produced by the group should have a specification, a conformance test suite, and at least two conformant implementations. There should be defined stages from idea to standard, as used by the W3C or Ecma TC39.
>
> Again, this is a decision that may not be in “one size fits all” category – there is always a tradeoff between spec publication steps and implementation / test requirements. I mentioned earlier about WOFF2 development at W3C and the effect W3C implementations & conformance tests requirements had on final Recommendation approval – it took roughly three more years until the WOFF 2.0 Recommendation was officially finalized [to progress from its Candidate Recommendation stage to Proposed Recommendation presented for Advisory Committee approval].

What caused the three-year delay? And why do you think finalizing the standard without the thing that caused the delay would have been a better outcome?

A couple of reasons for delay: 1) development of the conformance test suite took a lot longer than was originally anticipated, for various reasons due to resource availability, bandwidth, etc.; 2) The WG (Google folks primarily) produced a really good WOFF2 reference implementation – secure, well tested, good performance, … - so good that no one else wanted to spend time developing a second implementation, everyone (including MS folks) decided to use the one and only codebase. Took a while to figure out what to do to satisfy “two implementations” requirement. And in that particular case, the delays related to both CTS and implementation efforts didn’t really produce any significant feedback for the spec to incorporate, I really don’t remember anything major we had to change to improve the spec once the CTS results were in. Finalizing WOFF2 sooner wasn’t really a critical path for W3C folks (most browser vendors supported it even when it was a WD), but for organizations like ISO – holding off on final standard ratification for three more years pending on reference implementation availability would’ve been a very different story.

>> The outputs of this forum, and all inputs used in decisions, should be available to anyone with an internet connection, free of charge, in HTML or PDF format. I know that people commonly rely on second-hand information about ISO standards because they don’t want to pay €€€ for a PDF document. I also find it ridiculous that this AHG is supposed to work on a mandate whose input most of us don’t have access to.
>
> Agree in principle, the caveat is in different processes. Some organizations like W3C have all their working documents and most [but not all] of their communications available to general public. Some other organizations (e.g. ISO) prefer to keep their internal working documents accessible only to those who have proper credentials. It doesn’t mean it is impossible to make them publicly available, it means that one need to take an extra step to make it happen. In fact, in most cases when intermediate ISO documents (such as OFF Committee Draft or DIS) would be up for approval via ballot, I often requested to make that document publicly available in order to share it with this group. It’s doable, just doesn’t happen automatically by default.
> And as far as final output documents are concerned, there is another mechanism in place that allows submitting a request to make the ISO standard publicly available, free of charge. The ISO/IEC 14496-22 OFF standard from its 1st edition and up until now (4th edition with amendment #1) has always been publicly available free of charge, but it is also on the official ISO bestsellers list, even though the ISO store page where you can buy the PDF text has a link right next to the “Buy” button that says you can download it for free.

John’s suggestion was that we “consider to what kind of process do we want, collectively and voluntarily, to submit ourselves. How do we want to collaborate? And then we look at existing organisations and determine which, if any, provide that kind of process”. So if we agree that publishing all inputs is essential, what are the chances of getting ISO to allow us to do that *by default*?

ISO isn’t likely to publish inputs, but it is up to us to do so, and no permission is required – it is our input. Publishing output / working documents at different stages of the ISO process is a possibility, but it doesn’t happen by default, we need to ask for it. The only output documents ISO will never publish is the FDIS text submitted for a final approval ballot (if that text is published, no one would ever need to buy anything from ISO). But, like I said [and the OFF is a proof], if a good case is made why the particular ratified standard need to be made publicly available, it will be.

Thank you,
Vlad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200820/03f8172c/attachment-0001.html>