On Fri, May 15, 2026 at 05:52:49PM +0100, Nathan Willis wrote:
> On Wed, May 13, 2026 at 10:29 PM Julian Gilbey <[email protected]> wrote:
>
> that the package as-is is actually not DFSG-free in the same way that
> the 5.x version isn't: there is no "source code". And 4.x is even
> worse than 5.x: while the SVG sources are included in the GitHub
> repository in version 5.1.0 upwards (first committed to the repository
> in June 2018), they do not appear before that, so there is no hope of
> making a DFSG-free build of FontAwesome 4.7.0. (The SVG sources are
> embedded in the SVG font, but that is not the original source of the
> icons.)
>
> I may have missed something in here, but how do you know that the SVGs in the
> font are not the source SVGs?
Hi Nathan!
Good question; I'm not sure we do. The SVG font file
(fontawesome-webfont.svg) begins:
<metadata>
Created by FontForge 20120731 at Mon Oct 24 17:37:40 2016
By ,,,
Copyright Dave Gandy 2016. All rights reserved.
</metadata>
So perhaps this is the original source for the font. FontForge is
quite happy to open it and allow editing, and this would not be a
reason to consider FontAwesome 4.7.0 to be non-DFSG free.
We do know that from FontAwesome 5.1.0, the SVGs are provided as
individual files, one per icon. We also know that the process of
producing the other format font files (eot, woff, woff2, otf) from the
source (whether that is the SVG font file or individual SVG files) is
not documented, and that was the reason given for not allowing version
5.1.0 into Debian.
Looking further at FontAwesome 4.7.0:
* fontawesome-webfont.{eot,ttf} and FontAwesome.otf all contain the
string "FONTLAB:OTFEXPORT", so presumably these were generated by
FontLab (non-free software)
* I don't know how to uncompress the .woff/.woff2 files to see if
there is any identifying information there. But my guess is that
these were also generated using FontLab.
> In most other SVG-in-OT fonts I have seen, there is not much done to input
> SVGs
> before they are added to the `SVG ` table. The Adobe builder kind of
> halfheartedly compacts them (just shrinking whitespace runs), but even it
> doesn't do a full spec-compliance "cleaning" stage or so on. And that's for
> real
> emoji fonts, too, where they arguably have more validation to worry about.
So we could take fontawesome-webfont.svg to be Open Source (which the
ForkAwesome team did), and generate the other formats from it using
open source tools (fontforge seems the obvious choice; it can be
scripted to do the conversion). That seems a much better solution
than my original one of dropping FontAwesome 4.7.0 completely and
requiring all other packages to adapt to the change.
If we can do that, then I would also suggest that fonts-font-awesome
should continue to provide FontAwesome 4.7.0 for the time being to
avoid other packages having to do anything urgently.
What would we say about having these FontLab-converted fonts in
Debian, though? As I observed, they are ubiquitous.
> My proposal is therefore the following:
>
> - FontAwesome 4.7.0 should be dropped from Debian completely. This is
> a big deal, though; over 500 packages in testing ship
> fontawesome-webfont.woff2 But if I've read the situation correctly,
> that is the direction we should be heading in, though that's far
> beyond my capacity to manage. See below for some further thoughts
> on this.
>
> - fonts-font-awesome is upgraded to version 7.x of the upstream font,
> in TTF and WOFF2 formats, using a home-grown DFSG-free build system
> (courtesy of Roland Mas and Yadd, who wrote this for the
> node-fortawesome-fontawesome-free package); this package will no
> longer contain any other formats of the font, nor any CSS/LESS/JS
> code.
>
> Can you provide a link to this tool? Or was there one earlier in the thread
> that
> I may just have missed? That's tangential; I just hadn't encountered it.
The tool is just a script in the node-fortawesome-fontawesome-free and
fonts-fontawesome-legacy source packages (debian/build-font.py).
Best wishes,
Julian
