This may be a bit pie-in-the-sky, but I wonder if all this discussion is a symptom of a broader problem about updating and revising fonts. And a related issue is that the difficulty of updating and revising fonts leads to a situation where fonts do take ages to develop and release because this can't be done iteratively and bug fixes can't be easily fielded.
Let's imagine a situation where, when you install a font, the OS's font manger checks to see if the font is already installed. If it isn't already installed, no problem. If it is already installed, it compares the glyph outlines, coverage and metrics with the previously installed font, and makes the following determinations:
Is the new font a superset of the old? Does it merely add new glyphs, without changing existing ones?
Does it change the metrics of existing glyphs or global font metrics? If so, warn the user that this could cause document reflow.
Does it change the outlines of existing glyphs? If so, warn the user that the font will be visually incompatible.
Having determined the nature of the update, you can now offer the user a choice:
Cancel the install
Overwrite the old font
Rename the old font
Rewrite the name of the new font to add a custom suffix. ("FooFont for SomeClient Project 2017-05")
We are far from that situation at the moment but it's technically possible; wouldn't it fix most of these issues?
I did some more tests and it seems that indeed it is enough to store one point delta per contour plus the RSB phantom point delta for each glyph. The rest of the points follows along.
I’ll see if this could be an automatic optimisation in varLib, though it is probably a rare case. If the proposed spacing axis is widely used, it could be built into a font without preparing separate TTFs that would have to be optimized again. It would be easier to make a separate script that could apply this kind of spacing modification to any font.
We tag our web fonts. The order number is included in a namerecord similar to how Font Squirrel does it.
We've found it useful for checking to see if a website is using a properly licensed font, or for diagnosing font problems (i.e. customer made some dumb modification and now the kerning is gone).
We don't tag our desktop fonts, but I wish we did. I can think of several times where being able to verify the legitimacy of a license, or even knowing an approximate date when the font was issued, would have been very helpful.
Slightly off topic: I LOVE that FontForge and Font Squirrel include breadcrumbs in the fonts they produce. Being able to crack a font and see that it's been modified is super helpful for tech support.
One cannot practically do that with a font. With fonts it is more like trying to find who removed the proverbial needle in the haystack after it has been found and moved elsewhere. Unless a license holder admits to releasing a font in the wild, it would be incredibly difficult (impossible) to identify the perpetrator.
Again, and as I said, serialisation is not about identifying a 'perpetrator' responsible for distributing a font illegally. It is about being able to say to someone using the font 'Excuse me, but this font is not licensed to you. Please pay for a license.'
I think the problem of a EULA is that most EULAs are written in English which presents a problem for a majority or users. No? I agree that being as explicit as possible is good, but I also agree that erring on the side of restrictive is good for business. When you err on the side of restrictive you can always make case-by-case exceptions for clients who reach out to you with specific needs. But if you err on the side of less restrictive you will find it difficult to back track.
Additionally make the user feel that they can reach out to you if they need questions answered.
Be aware it's always best to err on the side of more restrictive EULA than less restrictive one as customers always assume with rose colored glasses, if something isn't expressly restricted it must otherwise be granted. Feel free to look at our EULA for ideas of things you may wish to consider restricting: http://www.fontdiner.com/fd_license.html