* Package name : fonts-fontawesome-free-legacy Version : [5 and 6] Upstream Contact: N/A * URL : https://github.com/FortAwesome/Font-Awesome * License : CC-BY-4.0 and MIT Programming Lang: N/A Description : FontAwesome free icon webfonts (legacy versions) Font Awesome is the Internet's icon library and toolkit, used by millions of designers, developers, and content creators. This package builds the font in TTF and WOFF2 formats for legacy versions of the font (versions 5 and 6). The package includes metadata files but not CSS files or NodeJS packages. The current version of the font is available in the node-forkawesome-fontawesome-* packages. The webfonts are built in a DFSG-compliant manner from the SVG sources, and are not bitwise identical to the upstream versions. The legacy versions are needed for some other packages including python3-qtawesome. It will be kept in the Debian Font Task Force area on salsa, and will be low-maintenance as the legacy versions are not being updated. The current version of the Font Awesome fonts can be found in node-fortawesome-fontawesome-free. (At the time of writing this, that package is still on version 6, but I hope to update it to version 7 in the near future.)
Hi Julian, Why don't you instead fix #902981 and add version 5 and 6 to the existing fonts-font-awesome package? Thanks, Bastian
I guess you just ask mechtilde@debian.org.
Hi Mechtilde, Bastian has a really good point here - that would be a much better and simpler solution than having a new package. Please can you reject fonts-font-awesome-legacy from the NEW queue? (I see that you are responsible for reviewing it.) Thanks, Julian
Hi Bastian, That would indeed be a better option than what I had proposed. How do I cancel a package in the NEW queue? Best wishes, Julian
Hi Bastian (cc Mechtilde), I've thought a bit more about this, and I'm inclined to stick with the fonts-font-awesome-legacy package. The advantage is significant: the fonts-font-awesome package can be updated to version 7 of the font, and can be updated every time there is a new release of the font. But the legacy package, which would offer versions 4, 5 and 6 of the font (though my current uploaded version only includes versions 5 and 6), would generally only need updating when there is a new major version of the upstream font. Bundling them all in one package means that there would have to be a new version of the legacy fonts package (including the source package) every time the current font is updated, which seems like unnecessary work. I'm not sure about the version numbering for the legacy package, though. At the moment, I've called it 5.15.4+6.7.2, but perhaps I should include a 4.7.0+ at the start of it? Either way, it would be very helpful to cancel the current NEW version so I can start again. Best wishes, Julian
Hi Julian When you are dealing with the fonts-font-awesome package please consider all its reverse (build) dependencies. You should not make it hard on other package maintainers, i.e. please do not make them transition manually unnecessarily. Thanks, Bastian
Hi Bastian, Of course! It may be somewhat complicated, though, as it depends on what the reverse dependencies are relying on. Let's see.... Best wishes, Julian
The Debian NEW review of fonts-font-awesome-legacy 5.15.4+6.7.2-1 has been completed. Decision: ACCEPTED Reviewer: Mechtilde Stehmann Review comment: Hi, for some small issues you get a bug report under https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1136366 Full review details: https://dfsg-new-queue.debian.org/reviews/fonts-font-awesome-legacy
We believe that the bug you reported is fixed in the latest version of fonts-font-awesome-legacy, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1135180@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Julian Gilbey <jdg@debian.org> (supplier of updated fonts-font-awesome-legacy package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org) Format: 1.8 Date: Mon, 04 May 2026 11:37:03 +0100 Source: fonts-font-awesome-legacy Binary: fonts-font-awesome-legacy Architecture: source all Version: 5.15.4+6.7.2-1 Distribution: unstable Urgency: medium Maintainer: Debian Font Task Force <debian-fonts@lists.debian.org> Changed-By: Julian Gilbey <jdg@debian.org> Description: fonts-font-awesome-legacy - FontAwesome free icon webfonts (legacy versions) Closes: 1135180 Changes: fonts-font-awesome-legacy (5.15.4+6.7.2-1) unstable; urgency=medium . * Initial release (closes: #1135180) Checksums-Sha1: 5c07ee983ebb7b21fa3508f63970a7e134c19ab6 2195 fonts-font-awesome-legacy_5.15.4+6.7.2-1.dsc f1e633269f5c674fc2524effe04c7bc408a26910 1149332 fonts-font-awesome-legacy_5.15.4+6.7.2.orig.tar.xz cd0659f1ab318b487ba6db737d7fe3e1745bb063 8564 fonts-font-awesome-legacy_5.15.4+6.7.2-1.debian.tar.xz e52d4d6c5dbaa738a0fc1a0a02343035763e76ff 963016 fonts-font-awesome-legacy_5.15.4+6.7.2-1_all.deb 63517165c36505958f4467708e75327062d85cb1 9435 fonts-font-awesome-legacy_5.15.4+6.7.2-1_amd64.buildinfo Checksums-Sha256: b93a849a8757b79cb58b1f8817c5eac1725b96f96e0d1e6f6477a62234fb5234 2195 fonts-font-awesome-legacy_5.15.4+6.7.2-1.dsc 9485e0da27f60ee1aa10ddba6f579fae13bf432f34bf84f55908b85711630f32 1149332 fonts-font-awesome-legacy_5.15.4+6.7.2.orig.tar.xz ed23ab75ff03c5b64f6e4ec27312a8acb50b734cb362192ee7b2ba95ce88febb 8564 fonts-font-awesome-legacy_5.15.4+6.7.2-1.debian.tar.xz a0093a0820ca670c0728ba28831beec92e538ca0bbcf41305b248e360d66c49c 963016 fonts-font-awesome-legacy_5.15.4+6.7.2-1_all.deb dccc4943d5b8154dc69595ee7fe4905927c186688bcb38707d57bb0f6d45a1cb 9435 fonts-font-awesome-legacy_5.15.4+6.7.2-1_amd64.buildinfo Files: f57f0b37340f8b0ab6368de090b190fa 2195 fonts optional fonts-font-awesome-legacy_5.15.4+6.7.2-1.dsc d3a41857787c0b1d3927f9f260634a35 1149332 fonts optional fonts-font-awesome-legacy_5.15.4+6.7.2.orig.tar.xz 183943c39a2a75a25830f43f7e6be8bf 8564 fonts optional fonts-font-awesome-legacy_5.15.4+6.7.2-1.debian.tar.xz e33f86a2cc2a5999243bbeaa68963a91 963016 fonts optional fonts-font-awesome-legacy_5.15.4+6.7.2-1_all.deb e1badf29f15fb361af7b5ad4e3fc7b66 9435 fonts optional fonts-font-awesome-legacy_5.15.4+6.7.2-1_amd64.buildinfo -----BEGIN PGP SIGNATURE----- iQJDBAEBCgAtFiEEfhrD+iemSShMMj72aVxCkxbAe/4FAmn4oPwPHGpkZ0BkZWJp YW4ub3JnAAoJEGlcQpMWwHv+ttQP+wfXGkai5MDk92ryGN4QpAluBzM35F59lAcX 1rfqxM1EinO0PFDFwcpO6ekq4rRVzr9YFVOd9l6lYiwzH2IoXmSLVmyfWPyUc5FH soCrsj0uL29y6Znk1Nt5FAMWm/HnNlM0t59dyCUGpsYLcSiXXuogkSKcvXH1agqu Dlc9eYRSLq72u+TJ7CyYzS8JbTVkjjOUxwaqyahqaYT42miTwT/JglIIYUAM81im fSAf7w+9HK7Ti+L7zlp6JqBViwkB6y+503MNhBTcxMgLCj96qN2Sh5D/T7CWpgo1 7w6Ek/b+idk5RKo7I6fvhndC7Sm1TmcmGkhQ6HhAfmXab21sGwH46E5SdFV6C2PK XltZyiyG92nXpcVxcYU5KrCXpA9zCxfYD24u2KkqO/egZM8/IQXUPV4HtgzIc1cL YjX8CVqu0o4jaABEPO2dLVExTQMy1aTDj4bvrs82wc838o4jgbdtNAobfdSvKkTX Q3QjevOJEYStbwKWhvdcQlWLoxQdi+Ia6QzABtPKLadVEM35ldk2e2y+eCmOMhRA ZPxrOAS/Te/F5Xz5VTjaxdWhXL12QN9d8PWTIzZABI8r/31zMNi1P8lQx7KjVAa6 LpvWc3jpjFhMg3neZscGJfE9fxLeviYMG/xLgujW4G5a3pWc+m/KCOWL92DcUSJI im18mWZm =DLpE -----END PGP SIGNATURE-----
affects 902981 src:aiodogstatsd src:ataqv src:bazel-bootstrap src:debci src:ipywidgets src:kanboard src:node-webfont src:orthanc-dicomweb src:pagure src:publican src:r-cran-shiny src:r-cran-visnetwork src:scaphandre src:sphinx-rtd-theme src:igraph src:mdbook src:lcdf-typetools ataqv bepasty bornagain-doc crmsh-doc debci dpdk-doc drbd-doc ford gerbera glances-doc glbinding-doc hackrf-doc icecast2 janus-demos jupyterhub kanboard libigraph-doc liblemonldap-ng-portal-perl mitmproxy mkdocs odoo-19 openmpi-doc otrs2 pagure prewikka publican python-aiodogstatsd-doc python-aioitertools-doc python-mintpy-doc python-qtawesome-common python-sphinx-mdinclude-doc python3-ase python3-cylc python3-django-hyperkitty python3-django-postorius python3-djangorestframework python3-flask-bootstrap python3-openstackdocstheme python3-xstatic-font-awesome r-cran-bookdown r-cran-rmarkdown r-cran-shiny r-cran-visnetwork reform-desktop-full rust-doc screenkey simple-whip-server sphinx-rtd-theme-common sreview-web swappy sympa texlive-fonts-extra-links tulip webext-foxyproxy weechat-doc wims wims-lti wsjtx-doc wsjtx-improved-doc thanks [Cc-ing debian-devel as there is a question about a mass bug filing at the end of this email; please Cc the bug report in any replies.] Also, in #1135180, Bastian wrote: [I have marked all of the packages in unstable which build-depend or depend on fonts-font-awesome as "affected" by this bug, as this may well affect you significantly.] I have just packaged fonts-font-awesome-legacy, containing DFSG-free versions of Font Awesome 5 and 6, and it has been accepted into unstable. I next intend to upgrade the fonts-font-awesome package itself to version 7.x of the font. I was looking at including version 4.7.0 of FontAwesome in the legacy package to support other packages which need this specific legacy version, without requiring maintainers to make any major changes to their packages except to (build-)depend on the legacy package rather than the fonts-font-awesome package. But I've hit a major stumbling block... To summarise most of the discussion in this bug report (#902981): FontAwesome's build system became closed-source in version 5.x, so Debian can't distribute it, and we have to stick with version 4.7.0. Therefore fonts-font-awesome was downgraded from 5.1.0 back to 4.7.0. However, looking at the source package for fonts-font-awesome (which is the upstream 4.7.0 version), I cannot find any evidence of a build system. Nor do I find any source for the icons in the GitHub repository or any build system there (looking at the 4.x branch). Indeed, the Debian package simply copies the compiled fonts (TTF, OTF and so on) into the appropriate directories under /usr. So it seems 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.) 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. - fonts-font-awesome-legacy provides versions 5 and 6 of the font in TTF and WOFF2 formats, again built in a DFSG-free way. This will resolve the DFSG-free nature of this package. Old package file layout (fonts only): /usr/share/fonts/opentype/font-awesome/FontAwesome.otf /usr/share/fonts/truetype/font-awesome/fontawesome-webfont.ttf /usr/share/fonts-font-awesome/fonts/fontawesome-webfont.eot /usr/share/fonts-font-awesome/fonts/fontawesome-webfont.svg /usr/share/fonts-font-awesome/fonts/fontawesome-webfont.woff /usr/share/fonts-font-awesome/fonts/fontawesome-webfont.woff2 Proposed new package file layout (fonts only): /usr/share/fonts/truetype/font-awesome/fa-brands-400.ttf /usr/share/fonts/truetype/font-awesome/fa-regular-400.ttf /usr/share/fonts/truetype/font-awesome/fa-solid-900.ttf /usr/share/fonts/woff/font-awesome/fa-brands-400.woff2 /usr/share/fonts/woff/font-awesome/fa-regular-400.woff2 /usr/share/fonts/woff/font-awesome/fa-solid-900.woff2 Those packages that require the JS/CSS files or SVG version of the font should migrate to using node-fortawesome-fontawesome-free which provides these. LESS files are no longer provided by upstream. If there is a pressing need for one of the other formats of version 7.x of the the font (EOT, SVG or WOFF), then I can use the fontcustom or node-webfont package to generate these. But if not, I can stick with the Python script written by Yadd and Roland as I used that before I discovered fontcustom. It would be good to upload a new version of fonts-font-awesome to experimental soon, but will wait a while before making any changes to unstable, in order to allow for a smooth transition. Further thoughts on removing FontAwesome 4.7.0 from Debian: * It seems that fonts-fork-awesome should be an almost drop-in replacement for those packages that require version 4.7.0 of FontAwesome; it provides (I believe) a superset of the icons, along with the CSS etc files. So making this change should be relatively straightforward (though a moderate amount of work). * Most of the binary packages that ship fontawesome-webfont.woff2 seem to have it as a static file in a local set of webpages. And this is presumably imported by something like sphinx-rtd-theme. So we can probably handle most of the cases by modifying just a handful of packages. Questions: (1) Have I understood the situation correctly regarding the DFSG-free nature of FontAwesome 4.7.0? (2) Should I do a mass bug filing against all of the potentially affected packages (as listed in the "affects" BTS command above) once I have uploaded fonts-font-awesome 7.x to experimental or to unstable, as many or all of them will need to make changes to either migrate to ForkAwesome or to accommodate the new structure of FontAwesome 7.x? Best wishes, Julian
Julian, Thank you for taking the time to do this. This is the type of work that nobody gets excited about doing, but that needs to be done to maintain Debian’s purity. On Wednesday, May 13, 2026 2:27:00 PM Mountain Standard Time Julian Gilbey wrote: sympa all not
Thanks for your diligence and the massive effort by Jonas, Vasudev, Pirate, Julian, and the rest of the team in navigating the complexities of Font Awesome over the years. I'm following up from the DFSG team's perspective, keeping the recent discussions in bug #1135180 and the history of #902981 in mind regarding a compliant path for these icons. Our look at the 5.0.10+really4.7.0~dfsg tree confirms that the exclusion of the upstream src/ directory in debian/copyright was a necessary move to purge several non-free blobs. Specifically, the upstream src/assets/js/ directory contains minified versions of prettify.js, respond.js, and ZeroClipboard.js without source, along with a compiled Flash binary (ZeroClipboard.swf). While this exclusion correctly purges non-free blobs, it highlights that the "preferred form for modification" for the icons (the individual SVG files or FontForge project) is missing from the upstream distribution. As it stands, the source package only carries generated font binaries and a combined SVG font file. This finding aligns with the goals of bug #1135180. Although the Fork Awesome project is now archived and defunct, its SIL OFL-licensed SVG assets remain a valid source for the icons. A sustainable path forward would involve using a modern, Debian-native build toolchain—such as python3-fontforge or node-webfont—to generate the font binaries directly from these SVG sources during the package build. We can provide guidance on structuring a compliant source package and are happy to review any proposed changes to ensure they meet archive standards before your next upload.
I hadn't realised that ForkAwesome was archived, but so is FontAwesome 4.7.0. The fonts-fontawesome-free-legacy package is now in unstable - I built it from the SVG sources using Yadd and Roland Mas's Python script (copied from the node-fortawesome-fontawesome-free source package, which now builds version 7.x of FontAwesome from the SVG sources). ForkAwesome builds in a DFSG-free way using fontcustom (written by the ForkAwesome team, and found in Debian main). So the issue is only about the old 4.7.0 version of FontAwesome: do I understand the situation correctly that this is not considered DFSG-free in its current state, and so needs replacing throughout the archive (and not just in this one package)? If it needs replacing, ForkAwesome is probably a perfectly reasonable way to do so, as it is close to identical, but has an open source build system. It does not matter that the ForkAwesome project is dead. Also, as I noted, this is quite pervasive, as FontAwesome 4.7.0 fonts are included in hundreds of packages, though many of those will likely be resolved if a handful of generator packages (eg sphinx-rtd-theme) can be fixed. Best wishes, Julian
On Wed, May 13, 2026 at 10:29 PM Julian Gilbey <jdg@debian.org> wrote: that the package as-is is actually not DFSG-free in the same way that I may have missed something in here, but how do you know that the SVGs in the font are not the source SVGs? 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. My proposal is therefore the following: 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. Thanks, Nate
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.
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.
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
Dear all, Thinking more about it, how about the following transition process? * Strip all of the fontawesome-webfont.* and FontAwesome.otf files from the source package except for the SVG one. * Regenerate all of these fonts using FontForge; here's a simple script that will do fine with a little tweaking:----- #!/usr/bin/python3 import fontforge SVG = "/tmp/fontawesome-webfont.svg" TTF = "/tmp/fontawesome-webfont.ttf" WOFF = "/tmp/fontawesome-webfont.woff" WOFF2 = "/tmp/fontawesome-webfont.woff2" OTF = "/tmp/FontAwesome.otf" fa = fontforge.open(SVG) fa.copyright = "Copyright Dave Gandy 2016. All rights reserved." fa.version = "4.7.0" fa.sfntRevision = 4.007 fa.ascent = 1536 fa.descent = 256 for font in [TTF, WOFF, WOFF2, OTF]: fa.generate(font) ----- Note that this does not generate the EOT font; that is fine, as it is specific to Internet Explorer and is not needed for Microsoft Edge, so is not needed on Debian systems (unless they are serving to old MS Windows machines). If really needed, we could generate that too using eot-utils. Then my suggestion is that fonts-font-awesome-legacy stores its fonts in /usr/share/fonts-font-awesome (not /usr/share/fonts-font-awesome-legacy), and includes FontAwesom 4.7.0 (with this minor change). The control fields will be roughly, for the time being: Package: fonts-font-awesome-legacy Conflicts and Replaces: fonts-font-awesome (<< 7) contains FontAwesome versions 4.7.0, 5.x, 6.x Package: fonts-font-awesome Version: 7.x Depends: fonts-font-awesome-legacy contains FontAwesome version 7.x Once these are both in testing, we file normal severity bugs against all packages that build-depend or depend on fonts-font-awesome asking them to either switch to fonts-font-awesome-legacy or to ensure that their package will continue to work with fonts-font-awesome 7.x, and close the bug when they have done so. Then in forky+1 (or perhaps sooner), we can drop the fonts-font-awesome -> fonts-font-awesome-legacy dependency. Thoughts before I proceed? Best wishes, Julian
Hey all, Stepping in again to provide some context. For those unfamiliar I’m an engineer at Font Awesome since the version 4 days. 1. SVG files that you find in any of our packages (even back to version 4) are artifacts and NOT source files. We’ve authored icons in a variety of tools over the years but no one has ever directly edited SVG files. They are always an output format that are intentionally optimized and lossy to some degree. 2. Any FontForge metadata you see is facilitated by a build system. A human never ran the desktop FontForge app to then generate files. It was always scripted. 3. The fontawesome-webfont.svg file from version 4 was also never a source file (regardless of whether the ForkAwesome folks considered it as such) It was also a generated file from FontLab _I think_. Happy to answer questions that pop up so speculation doesn’t have to win the day.
Hey Rob, Thank you *so* much for this information. That's really helpful. I don't know where that puts us now. Can we say that FontAwesome of any version is DFSG-free, given that the original sources are not available for any version of the font? How do we move forward? debian-legal - your input here would be most welcome. And Rob - if you are able to give any advice here, that would also be welcome. We *do* want to keep FontAwesome around - it is so amazing (awesome?!) and so ubiquitous! Best wishes, Julian
I don’t have any silver bullets. But I’m here to answer questions and see if we can figure something out. I’d hate to have Font Awesome removed just because you all didn’t have the complete picture. I understand the legal tension here but we use Debian all over the place at FA. If I can assist in finding a solution it’s a small way for us to say thank you. I do think the hinge is on legal here. I can’t make the build system or the source files available because we are a for-profit commercial company. If that’s a deal-breaker I respect that. But I do wonder if there’s some middle ground or exception? If it can’t have minified files I can produce an artifact that doesn’t contain this. If there has to be an uncompressed OTF part of the package I can do that. I’m willing to work within some requirements and even take some ownership of the package maintenance. Let me ask this: are there any other products like FA where there is a commercial entity and where the “source code” (I’m using this term loosely) is available for a free version of it? Has Debian solved this for another org and we can use prior art? Yes, I really don’t want users of Debian or FA to suffer here. That’s what compelled me to speak up on this VERY old bug. :)
I cannot speak for the entire debian-legal community, but as one of the more prolific posters on the list, these are my thoughts. 1. SVG is not always the preferred form of modification for fonts, but it *can be* the preferred form of modification for fonts. This is similar to HTML, which sometimes is the original file and other times was generated from something else that was the original file. 2. It is clear that SVG was not the preferred form of modification for the original FontAwesome project. 3. It isn’t clear to me without doing further research if SVG was the preferred form of modification for the ForkAwesome project. 4. Seeing as how both FontAwesome and ForkAwesome are now archived projects, they are not receiving further modifications upstream. 5. Because it is possible for us to build the ForkAwesome fonts from SVG in Debian, because SVG can be considered an valid source format for fonts, and because the upstream ForkAwesome files are no longer being modified, I don’t think there is a significant DFSG concern to using them as the source files for the purpose of packaging. 6. If someone is concerned about #5, it would be possible for someone to fork ForkAwesome, give it a new name, and, for the purposes of the fork, declare that the SVG files are now the preferred form of modification and that any future modifications will be made by directly editing those files. Then, that fork could be packaged in Debian. It is possible that I have missed something or misunderstood the situation in some way, so I would appreciate any critiques of the above.
Hi Soren, Thanks for these thoughts! A few comments interspersed. understanding, the SVG files were regarded as the master icon files in the ForkAwesome project. a *lot* of packages, is "archived" - there are no further changes to version 4. But FontAwesome continues to grow and develop, and we currently have versions 5, 6 (both legacy) and 7 (current) in Debian (in the fonts-font-awesome-legacy and node-fortawesome-fontawesome-free packages respectively). For the purpose of packaging ForkAwesome, I presume you mean? I'd personally be happy to regard the SVGs in FontAwesome (all versions) as editable source files, as the ForkAwesome project did (and they are licensed under an open source licencd), but we now know for certain that they're not the actual source files (as they weren't for ForkAwesome). Best wishes, Julian
files. The crux of this part of the discussion is the concept of “preferred form of modification”. Preferred form of modification is not a phrase that occurs in the DFSG. It appears in the GPL as part of the definition of "source code": "The source code for a work means the preferred form of the work for making modifications to it.” The DFSG does not define what source code is. It simply states: "The program must include source code, and must allow distribution in source code as well as compiled form.” https://www.debian.org/social_contract In general, Debian uses a definition of source code that aligns with the idea of preferred form of modification, which is generally understood to mean that the source files upstream modifies when they want to change the program must be available to the downstream users of Debian, and Debian must be able to build the package from those files (meaning that there needs to be DFSG-free build tools that can process those source files into the final product). The important part of this discussion is that the *file type* does not always indicate if it is the original source code or not, and the preferred form of modification can *change* over time. SVG is one of these example file types than can sometimes be the preferred form of modification and other times isn’t. When upstream wants to make changes in the font, if they are directly editing some other file and then using that file to generate a SVG and other font formats, then to be DFSG in Debian, we need to also have access to that original file under a DFSG-license and be able to generate the resulting fonts during the build process. This is important because, as has already been mentioned in this thread, when an SVG is generated from another file, there are often subtle differences in the output. So, if Debian is not using the same source as upstream, and is thus producing different output than upstream, that makes the package DFSG-non-free. But if upstream is editing the SVG file directly to make changes in the font, then the SVG file has become the preferred form of modification, Debian packages will be identical to upstream releases, and Debian users and anyone else who would like to fork the project is on equal footing with upstream in their ability to use and modify the source files. The fascinating part of this discussion is that sometimes the preferred form of modification can change. For example, consider an HTML file that for many years was generated by DocBook from an XML input file. Imagine that at some point upstream decides they no longer wanted to use DocBook, and choose to use the previous HTML output from DocBook as their new source file, which they would edit manually going forward. That HTML file would then become the preferred source of modification. In the case of these fonts, if Debian were trying to package any of the versions that were still under active development, it would be important that we could build them from the original source files that upstream uses to build them. Even if they ship SVG files, it would not be sufficient for us to build from those. However, with archived projects (or archived old versions if all we intend to do is package the old version), it becomes less of an issue because none of the files are being updated by upstream any longer, which means that upstream is no longer accepting patches, so any modification of the package would be a fork. If anyone has concerns about whether whether SVG is the preferred form of modification for FontAwesome, they can fork the project, give it a new name, state that all future modifications will be done directly to the SVG files (even if there are never actually any changes made), and all the requirements to be DFSG-free are met.
I feel like if this is the answer and SVG are perfectly fine to be treated as the preferred form of modification - then I don't understand why we are not just shipping them. If we (and users) can feasibly modify the files to patch the font, I feel like the holier than thou stance of "yes, we just happen to know that there's a proprietary toolchain to generate these, but only because upstream told us" is not very helpful. Kind regards Philipp Kern
There may still be practical concerns here that matter; if the only issues are theoretical, then what's distributed is source enough for Debian's purposes. We should (almost) always be looking at preferred form for making modifications, not just a form having feasibility of modification. Not distributing the upstream source used to build the SVG (if there is such a thing) typically means that the Debian maintainers and users have to expend more effort to fix issues in the fonts (or make derivative works of the fonts) than an upstream who has access to that source and the build toolchain. That said, if the there's a reversible transform that can turn the SVG into the equivalent of the "upstream source" (say if the upstream source was some kind of proprietary vector format like adobe illustrator) or if the SVG is what the upstream now uses to modify the font for any kind of modification, then the SVG is now the source.
I am not a lawyer, so cannot be certain on any of the following. But here is what I see in this case. The DFSG uses the term "Source Code" without making any attempt to define it. Apparently, the understanding of "Source Code" in the DFSG is that used in the GPL, version 2 (which was current when the DFSG were written): The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. In the case of software, "preferred form" is fairly unambiguous: no-one wants to be editing compiled code (be that byte-compiled, or preprocessed from some source file, or the like), and the "preferred form" is the hand-written code. But fonts are an entirely different matter. What if, for example, FortAwesome keeps their fonts in a database, with each record being an icon in some format and its associated metadata? (Rob: I'm not fishing for information! The details seem to be irrelevant here.) The "preferred form" for making modifications is then very unclear: presumably there would be some form of (proprietary) front-end to the database (and associated VCS). What would be acceptable for the purposes of the GPL definition of "source code" in this case? It would be unreasonable to require the whole design environment to be part of the "preferred form" or "source code". I'm sure there would have been discussion of this elsewhere. A related case has come up in relation to the GFDL, if I recall correctly, and fonts are closer to documentation in their nature than to compilable software source code. What we do know is that FortAwesome have made the icons themselves available as SVGs licensed under CC-BY-4.0, with metadata in a YAML file. These are generated from some private format, and details about this are not public. It might be that this private format is interchangeable with SVG, or not. But - to comment on Don's and others' thoughts - it is straightforward to build WOFF2 (and other format) fonts from these SVGs, and also to modify any of the icons if desired. And modifying them in SVG format is - for some people - the way they would prefer to modify icons. Indeed, the ForkAwesome team built their fonts from the FontAwesome SVGs. So I would be inclined in the direction of saying we can use the SVG icons, together with the YAML metadata, as the basis for a DFSG-compatible package. We might have to label it explicitly as being a DFSG-compatible fork of FontAwesome, rather than the true upstream font. Best wishes, Julian
Quoting Julian Gilbey (2026-05-25 13:27:12) Fonts may have a preferred source form that is not textual but binary. For another example of that, see etoys which is in non-free despite being DFSG-free: It is kept out of main due to concerns that its source format might be too alien for the Debian security team to reasonably do audits on the codebase. But from a legal standpoint, code either have freely licensed *source* or they don't. And that applies to fonts in the sense that either the font *is* its own source or it isn't. For font-awesome we cannot reasonably assume that the binary TrueType code is the source for the code project. Either what has been given to us includes the sources or it doesn't. If it doesn't, then we should stop distributing it, because it is not freely licensed. Or with the post 1998 terminology: It is not Open Source if its source is missing. If someone then forks font-awesome and states that from now on, $FOO is the preferred form for modification within the forked project, then the question remains: how can that new project be freely licensed (a.k.a. Open Source) if is is derived from a project where source was missing? - Jonas
That seems an understandable concern for etoys, but not particularly relevant here - the SVG format is textual and easy to audit. We have been told that none of the distributed versions of the font are the source for the fonts. But the distributed SVGs are licensed under CC-BY-4.0. And they could be used as source for a font. It is a question, indeed, but as I'm not a lawyer, I can't answer that question. But this seems no different to the question of whether we can distribute an image that is licensed under an open source license but that was created using proprietary software. Perhaps the original source is in some proprietary format, but the exported (and subsequently distributed) image is in JPEG or similar format. Debian is full of images whose creation is not questioned. Best wishes, Julian
I don’t mind sharing the details. Preferred form: is actually Figma. Our designers have an entire system developed to manage them there. Figma is the source of truth. When we need to update an icon we have to go there to do it. We export icons in SVG format that we then import into an internal web app behind our VPN. The tools we’ve used to verify SVG data, resize, convert, are all developed in-house. Even the thing that creates web font files is written in-house. (We no longer use FontForge). We then store the raw SVG path data in a relational database. This is probably obvious but this is all very un-friendly to what I’m learning about how DFSG works. We can’t share these internal tools because our company considers them a proprietary, competitive advantage.
Rob, if to are written learning company Thank you for the detailed information about the upstream preferred form of modification. I assume that all of what you have written above is describing FontAwesome, not ForkAwesome. There has been some conflation in this discussion between the two, so I want to make sure that I understand you clearly.
Correct. I’m an engineer at the company that maintains and releases Font Awesome (F-O-N-T). I’m not affiliated with ForkAwesome (F-O-R-K).
Thanks Rob! So I guessed correctly about a relational database :-) I'm now getting out of my depth when it comes to this - I don't know Figma at all (not being in the design field myself). The following questions might or might not be relevant.... Would you know: does Figma store the icons (the source of truth) in a Figma-specific format, which are then exported as SVGs? If it is Figma-specific, is it stored in a vector-graphics format that is interchangeable with the published SVG format (meaning that you could recreate the Figma format of the icons from the SVGs)? Best wishes, Julian
Dear all, I've been mulling over this, and have had a thought. I am not a font designer, but extrapolating from what Rob has been saying, I think it is a reasonable presumption that most fonts are not designed in FontForge or similar open source software. And that is surely the case for a significant proportion of the fonts distributed in Debian; we certainly don't get the "source code" for them (which, in the case of FontForge, would be an SFD file). I looked at the Debian source for a random font on my system, and all it contains is the ttf files and the OFL license text. Looking at the upstream webpage, the references there include guidance on how to use FontLab. So presumably the ttf format is not the preferred upstream format for this particular font. If we go down the route of excluding FontAwesome, it would also be incumbent upon us to do an audit of all the fonts shipped by Debian, and we would probably end up with almost no fonts at all, or have to move them all to non-free. Best wishes, Julian
On Tuesday, June 2, 2026 11:28:49 PM Mountain Standard Time Julian Gilbey wrote: Beginning many years ago, Debian used to ship a lot of fonts by simply packaging upstream TTF files. This is before my time, but from what I have read this was because open-source font systems either didn’t exist or weren’t packaged for Debian. In the intervening years that has generally been fixed. Because of that there has been a recent effort to go back and actually build all the fonts we used to just ship. As such, I think it would be appropriate for there to be a general audit of fonts and a removal to non-free of any font for which we don’t have the source or for which we can’t build it using a free toolchain.
Davi
Davi Lucca Oliveira Miott io