[MPEG-OTSPEC] Patent policy and process

James Clark jjc at jclark.com
Wed Aug 19 05:40:22 CEST 2020


One approach for accommodating some more informal documents within the ISO
process is to do a multi-part technical report in addition to a standard.
In SGML days, we did this with ISO/IEC TR 9573 on top of ISO/IEC 8879.
Initially 9573 was a single TR, but it later was split up into 15 parts;
for example, part 13 defines SGML named entity sets for mathematics and
science.

James

On Wed, Aug 19, 2020 at 9:59 AM Levantovsky, Vladimir <
Vladimir.Levantovsky at monotype.com> wrote:

> I am mostly in agreement, with few comments inline.
>
>
>
> 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
> <https://www.w3.org/TR/html-design-principles/#priority-of-constituencies>:
> “In case of conflict, consider users over authors over implementors over
> specifiers over theoretical purity.” I believe we can adopt it pretty
> much verbatim.
>
>
> I’d like to have a forum that produces a range of documents, some very
> formal, such as a standard on OpenType text shaping (as being defined in
> the scope discussion), some less formal, such as orthography documentation
> or guides on developing fonts for specific scripts. There need to be
> different processes for different kinds of documents.
>
> While I agree in principle, I am not sure this can be easily implemented
> in practice. Almost every industry standards organization has significant
> processes and policies in place, some of them are more rigid than others
> but none of them (as far as I am aware) have processes in place that would
> allow such a broad range of output documents be published. We may end up
> facing a reality that “a forum” will end up collaborating with different
> organizations to achieve different goals and publish different documents. I
> do not really see it as a big issue, I think it would be perfectly fine to
> have a single forum for discussion where input proposals are discussed, and
> then submitted to different entities (e.g. ISO and Unicode). The mechanisms
> for such collaborations already exist (official liaisons between different
> entities), if and when these dependencies need to be formalized.
>
>
> 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].
>
>
> 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
> <https://standards.iso.org/ittf/PubliclyAvailableStandards/> 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.
>
>
> I don’t care whether standards produced by the forum eventually become ISO
> standards. I know that parts of the Unicode Standard are published as ISO
> 10646, but in my work in software internationalization, that’s never been
> relevant to my work – all I need is on the Unicode web site. Similarly I
> know that ECMA-262, the standard for JavaScript, is re-published as ISO
> 16262, but I never even looked at it while working in TC39. HTML and CSS
> seem to be doing quite well without ISO standards.
>
> Many engineers / developers may not care about official document status
> for as long as the info they need is readily available, but the industry
> (OEM) and their lawyers do care, a lot! OpenType 1.4 had seen limited
> adoption by major consumer electronic device makers, but as soon as the 1
> st edition of ISO OFF standard was published (the same exact text, with
> the only difference that OpenType references were replaced by OFF) – the
> adoption skyrocketed through the roof, and virtually all consumer devices
> became font-friendly. No technical differences whatsoever, the only reason
> is that ISO publication meant this spec is here to stay and there are
> proper IPR policies in place … voila, the world has changed! There are now
> many industry standards that mandate OFF support for conformance.
>
>
> I understand that the forum needs an IP policy and other rules to keep the
> lawyers of the participating companies happy. Copyright of any standards,
> or other jointly produced documents, must be owned by the forum. The forum
> will likely also publish documents that are contributed as inputs to the
> standardization process, or other documents, whose copyright may be
> retained by their contributors.
>
> The IP policies are there to primarily protect the implementers, not the
> contributors. In fact, they are sometimes the biggest stumbling block that
> makes participating company lawyers very concerned. This is why creating an
> IP policy and getting it approved by membership is such a difficult
> process. Using W3C as an example of organization that has very strong and
> most liberal (for implementers) IP policy – any W3C Recommendation can be
> implemented free of any IPR concerns. What it really means is that every
> member has to agree that any IP they own would be made available free of
> charge if any member representative makes a technical proposal that is
> accepted. There are caveats in place, but this is the crux of it. And, as
> far as copyrights are concerned, there must be proper arrangements in place
> that would allow a standards organization to modify, publish, maintain and
> extend a spec they produced. Forum (whatever that means) can’t own the
> copyrights independent of the organization that established that forum.
>
>
>
> Hope this helps,
>
> Vlad
>
>
>
>
> Best regards,
> Norbert
> Lindenberg Software LLC
>
>
>
> > On Aug 17, 2020, at 09:37, John Hudson <john at tiro.ca> wrote:
> >
> > On 15082020 10:28 am, Dave Crossland wrote:
> >> On Sat, Aug 15, 2020, 11:55 AM John Hudson <john at tiro.ca> wrote:
> >> what we mostly want
> >> institutions to do is get out of the way.
> >>
> >> Yet, the rubber stamping and "setting in stone" with a us patent policy
> is necessary (but not wholly sufficient) for implementation and adoption:
> >>
> >> A cycle from de facto, to de jure, to de facto.
> >>
> >> That's the essential problem with commontype.org and
> GitHub.com/Opentype
> <https://protect-us.mimecast.com/s/gZmXCL92DvfRqGQkCmfWTM> and all the
> others right now, it's all too de facto with no clear route to de jure.
> >
> >
> > I agree that having clarity over IP and a patent policy in place is
> important*, and that this is one of the attractions to collaborating under
> the auspices of an existing organisation that has such a policy and to
> which a number of participating companies and individuals may already be
> signed up.
> >
> > That said, a patent policy is one of the easier things to write and
> agree on, and I think for companies currently considering whether and how
> to engage in what we’re scoping, the IP considerations will be the same
> regardless of the organisation.
> >
> > So from that perspective, I think it makes most sense for us—as we scope
> the work—to also 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 (and will they have us?).
> >
> > JH
> >
> >
> >
> > * Was surprised to note that UFO doesn’t appear to have a patent policy.
> >
> >
> >
> > --
> >
> > John Hudson
> > Tiro Typeworks Ltd
> > www.tiro.com <https://protect-us.mimecast.com/s/TMzaCM82gJsqPwz2HQkwAI>
> >
> > Salish Sea, BC
> > tiro at tiro.com
> >
> >
> > NOTE: In the interests of productivity, I am currently
> > dealing with email on only two days per week, usually
> > Monday and Thursday unless this schedule is disrupted
> > by travel. If you need to contact me urgently, please
> > use some other method of communication. Thank you.
> >
> > _______________________________________________
> > mpeg-otspec mailing list
> > mpeg-otspec at lists.aau.at
> > https://lists.aau.at/mailman/listinfo/mpeg-otspec
> <https://protect-us.mimecast.com/s/goepCNk2jYt0LOjZT0vM5v>
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
> <https://protect-us.mimecast.com/s/goepCNk2jYt0LOjZT0vM5v>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200819/c9f32efe/attachment-0001.html>


More information about the mpeg-otspec mailing list