2. In the case of Source Sans, it isn’t just the file name that changes with
major versions, but also the font name. So, for example, if I create a
LibreOffice document and select the font, the font name is Source Sans 3. In
the future, if they ever move to version 4, the font name will become Source
Sans 4. Which will, of course, break any document that is using the font.
As I mentioned before, this seems like insanity. But upstream apparently
doesn’t feel that way. Partially because they don’t really intend the font to
be used in documents, so it doesn’t appear that they care if those break.
My recollection is that the change in the user-visible name in this case, like a lot of other variation in user-facing names, is a deliberate decision by the foundry (Adobe) in order to *not* break existing documents by having the updated font release trigger reflows of all text. The topic came up back when they changed the names upstream.
Designers and publishers would be furious if an updated font caused all of their pre-existing uses to overrun pages and bounds. Even casual users tend to get mad about that with free fonts, for that matter.
It's a bit historically novel to say "MyFont 3" rather than "MyFont Neue" or something, but it's the same idea, and I think it's just an evolution of that same concern — updated for the fact that major new releases can now happen way more easily than they did in cold metal or photosetting. People who need to ensure an important old document doesn't suddenly break can keep both versions of the font and not be confused about which is which (since you definitely don't see version numbers in drop-down Font menus...).
Assuming all the other problems get addressed, perhaps it would be best to
move the source package name back to the versioned source-sans-3. Otherwise,
it would be difficult to ship both source-sans-3 and a possible future source-
sans-4 at the same time, as the source-sans source package would move to a
future version and you can’t build both versions of the font from a single
commit tag. However, if the source packages are versioned, you could leave
source-sans-3 at the latest version 3 commit and just ignore or remove the
watch file telling you that updates are available.
But the OFL license with a reserved name makes this even more difficult, because
different versions of AFDKO are likely to produce slightly different font
outputs. So, even if the version built at the time the font ships matches
upstream, future rebuilds probably won’t.
I do not think there is any chance at all of Adobe changing its license or RFN declaration.
That being said, if the existing build script produces a font binary that is functionally identical to the font binaries (a different test than bit-for-bit identical), I believe that's enough, and if future updates to Adobe's own tools make that no longer hold true, I'm confident they would consider that a bug that needed fixing.
The more I think about this, unless I am somehow able to get Adobe to
authorize a rebuild exception (does anyone have example text of what they
would need to add to the license to do this?), the best way forward might be
the following:
"Build the font from source using tools from Debian main during the package
build but distribute the upstream build in the binary package instead. In this
case it is not required to move the font to contrib.”
I'm not sure I understand what this is proposing. Perhaps someone else who has a longer memory with how RFNs intersect with Debian policy should speak to it, though.