[MPEG-OTSPEC] MATH Encumbrance

[Dave Crossland]

On Sun, Aug 23, 2020, 9:12 PM Peter Constable <pgcon6 at msn.com> wrote:

> If companies can agree to collaborate on a basis of guaranteeing
> royalty-free licenses for any essential patents, I certainly won’t have any
> objection. But I don’t know that it will be necessary to have such
> guarantees in place in order to have effective collaboration that advances
> the state of the art in regard to fonts and text for the industry as a
> whole.
>

It's not just companies, though.

The community includes companies who register patents and have used them
offensively in the past, albeit not directly on fonts stuff... but it also
includes non profits and sole proprietors and hobbyists.

It hasn't been necessary in the past, but as the influence of - and
dependency on - libre software that is developed by contributors all across
that community is growing, then it seems increasingly necessary to me.

And that community can easily eschew any formal organization and continue
to just get on with things, under the governance of a libre software
license...

As much as we here are enthusiastic about text and fonts, it simply is not
> what will add the next $20B (<1%) to Apple’s market cap, or Google’s, or
> MS’s, etc.
>
...and the companies may not be able to keep up, because they underinvest
in this space.

So, while in some respects I’m not enthusiastic with ISO processes (though
> I’ve been involved with them for 20 years), I don’t see their IP-related
> policies as an obstacle for our area. It certainly hasn’t hindered anything
> in the past 10 years during which colour fonts and variable fonts became
> real.
>
ISO policy may indeed be tolerable, in isolation. But it may also hinder
the ability of ISO to meet the competitive benchmark that any entity
seeking to drive efficient and effective advancement of the state of the
art in fonts and text needs to meet: The licensing of an editor's draft on
a public GitHub repo under the Apache license.

Can ISO provide this?

If no, it probably can't work as an upstream, and will consolidate it's
position as a downstream recipient of advances made elsewhere.

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