Nathan,
Your comments into why a font would want to change its name were insightful.
On Tuesday, February 27, 2024 5:35:58 AM MST Nathan Willis wrote:
> 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.
This is what SIL’s website says about rebuilding the fonts.
https://openfontlicense.org/how-to-modify-ofl-fonts/
"5.9 Do font rebuilds require a name change? Do I have to change the name of the font when my packaging workflow includes a full rebuild from source?"
"Yes, all rebuilds which change the font data and the smart code are Modified Versions and the requirements of the OFL apply: you need to respect what the Author(s) have chosen in terms of Reserved Font Names. However if a package (or installer) is simply a wrapper or a compressed structure around the final font - leaving them intact on the inside - then no name change is required. Please get in touch with the author(s) and copyright holder(s) to inquire about the presence of font sources beyond the final font file(s) and the recommended build path. That build path may very well be non-trivial and hard to reproduce accurately by the maintainer. If a full font build path is made available by the upstream author(s) please be aware that any regressions and changes you may introduce when doing a rebuild for packaging purposes is your responsibility as a package maintainer since you are effectively creating a separate branch. You should make it very clear to your users that your rebuilt version is not the canonical one from upstream.”
Does anyone know any way to check if the fonts have the same “font data” in any other way besides checking if they are bit-for-bit identical?
In describing this problem, the wiki says the following:
https://wiki.debian.org/Fonts/Bugs/rfn-violation
"The fonts seems to be modified, or has been rebuilt in a way that is
not bitwise identical to the upstream build, and your font name
includes Reserved Font Names (RFN) stated in the license."
> > 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.
The above wiki page proposes five ways to handle OFL fonts with a Reserved Font Name.
"Rebuild identical to the upstream build using packages in main.”
That doesn’t seem to be possible, especially with rebuilds over time.
"Work with upstream to resolve the license issue by having an rebuild exception or remove RFN from the license."
I don’t think it is likely Adobe will remove their RFN. They may authorize a rebuild exception, but I think that is unlikely.
"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.”
This is doable from a technical perspective, but I haven’t yet decided if I care enough about the font to persue it.
"Change the font name to avoid RFN being used as the primary name. This makes the font incompatible with the upstream font.”
This would make it hard for programs and users to recognize this as the same font, which would mostly defeat the purpose of including it in Debian.
"If the font cannot be built from source using only packages in Debian main, move this package to contrib and use the upstream build.”
This could be done fairly easily by just shipping the compiled fonts that upstream ships. But I am not sure I want to invest energy into a font that isn’t part of main.
https://github.com/adobe-fonts/source-sans
--
Soren Stoutner
soren@debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part.