Hi,

font-awesome 5.1 is available, it would be nice if you could upgrade to
this version.

Regards,
Daniel

Hi,

Do you need fonts-font-awesome 5 for one of your package ?
fonts-font-awesome is stuck to v4 because of breaking changes in v5 that
break many packages (see #899124).

fonts-font-awesome v5+ will be added as a new package later.

One potential issue with fonts-font-awesome 5 is that upstream changed
their build system and now, the build system is closed source while the
actual sources files (otf font, js, svg, less, sass and maybe other) are
available.
The upstream repository contains a mix of source files and generated
files so I asked them which file are the source and which files are
generated (see [0]) to be able to rebuild the generated files from sources.

[0] https://github.com/FortAwesome/Font-Awesome/issues/13467

Hi,

please remember to CC the submitter explicitly, sending a message only
to the bug does not notify the submitter.

regarding font-awesome 5: I use the package in my own things as well as
some (unimportant) packages I maintain.

How about having fonts-font-awesome5 in parallel to 4.x?

Regards,
Daniel

Ok thanks, I wasn't totally aware of that.

This is the idea to have it as a separate package with "5" suffix.
But since v5 upstream does not chip build system files, only source and
generated files are available on github without a way to rebuild them.
I asked them a first question about which files are actual sources and
which are generated.
I will ask debian-legal about this, if this cause an issue regarding DFSG.

Hi,

I have a question regarding the font-awesome v5 [0] and the DFSG.

Since version 5, font-awesome upstream repository contains both source
files and generated files but not the build system [1].

So it is not possible to regenerate generated files from source files
without guessing which file are generated and which are sources.
I've asked upstream about that [2] (but no response yet).

It's a bit as if this upstream repository was a tarball containing
binaries and sources but without makefiles used to generated the
binaries, just being a git repo instead of a tarball file.

Considering DFSG #2:

is font-awesome 5 upstream repository DFSG compatible ?

Thanks for your help :)

----
[0]: https://github.com/FortAwesome/Font-Awesome
[1]:
https://github.com/FortAwesome/Font-Awesome/issues/12199#issuecomment-363168281
[2]: https://github.com/FortAwesome/Font-Awesome/issues/13467

Font-awesome 5 licensing is [3]:

[3]: https://fontawesome.com/license/free
[4]: https://creativecommons.org/licenses/by/4.0/
[5]: https://scripts.sil.org/OFL
[6]: https://opensource.org/licenses/MIT

I think this is a technical issue, but not a DFSG violation; and I think
it would be appropriate to track it as a bug, but not a release-critical
bug.

The same situation exists in any package where some hard-to-modify,
non-executable data file (perhaps an icon) is accompanied by its
easier-to-modify source form (perhaps in GIMP format or as a SVG) but
a manual export step is required to transform the source form into the
modifiable form.

We generally hold executable code (must be compiled at build time,
with some rare exceptions) to a higher standard than "pure data" (not
necessarily recompiled at build time), because in practice it is far
more likely that we will find ourselves in a position where we need to
exercise our right to modify for executable code, to be able to fix bugs
in that code; and because in most cases fixing bugs in executable code
by direct modifications to a generated format is much les practical than
doing the same with many non-executable data formats (for instance if
you need to, you can perform many edits to an icon in its bitmap form
without going back to its source form).

We do not require that packages are modifiable by people who do not
know how to modify that particular language or format. People with the
necessary knowledge presumably know which file is in a preferred form
for modification and which file is generated from it; if they didn't,
then that would preusmably have to be because the generated file was a
reasonable form for modification in its own right.

The license allows distribution of that source code: [x]

So yes I think this is fine for the DFSG.

    smcv

Simon McVittie <smcv@debian.org> writes:

You may or may not consider this dispositive, but the definition of
source code from GPL v3 is

  The "Corresponding Source" for a work in object code form means all
  the source code needed to generate, install, and (for an executable
  work) run the object code and to modify the work, including scripts to
  control those activities.

So a makefile or equivalent is required.

On a more practical level, Debian has to be able to rebuild all of the
binaries from source.  If you can not do that, then that would be an RC
bug.

Cheers,
Walter Landry

Actually, many files are text files and could be considered as sources
files (excluding minified files which are obviously generated).

But many of them contains the same thing:
 - javascript code:
   - js files meant to be used with node.js [0]
   - js files for svg webfont [1]
 - glyph data (shape paths):
   - single svg containing all glyphs [2]
   - multiple svg containing only one glyph each [3]
   - glyphs metadata contain glyph svg in a "raw" field [4]
   - js files for node.js contains glyph path data [5]
 - typescript files (*.d.ts) for node.js seem to be all the same, see 2
examples:
   [6], [7]
 - advanced-options/use-with-node-js/fontawesome-free/ [8] folder seems
to contain many files also in web-fonts-with-css/ [9] and in
advanced-options/use-with-node-js/fontawesome-free-webfonts/ [10]
 - [11] and [12] seems to be the same (beside the version in comments)
 - There are multiple fonts format (otf, ttf, woff2, ...), by reading
trough issues on github, it seems that there are all generated from the
.otf ones, but using an online website ([13])
 - There are also svg files containing all glyphs along with webfonts
[14], maybe same as [2]

There are probably other files duplicated.

All files are just text files that can be patched easily beside fonts
and .min.* files.
I mean, there are not opaque binaries that can't be patched without
specialized tools and knowledge.

But one issue in one of them will probably require modification in some
other files too.

This can be OK though ("just" a maintenance burden to remember that a
bug might span multiple files)
Not sure what to think about generated webfonts.

At least, minified files can be regenerated at package build time with
known tools that does this (maybe upstream can help to use the same tool
as them)

I also think of the many potential reverse dependencies once
python3-sphinx will move to font awesome 5. It would be great to have
font awesome 5 in main avoiding them to move to contrib.



Keeping minified files appart, given the nature of generated files
(either correctly indented files or font files), I'm leaning toward
Simon's way to think about this.

What do you think Walter ?

Thanks

[0]
https://github.com/FortAwesome/Font-Awesome/blob/master/advanced-options/use-with-node-js/fontawesome/index.js
[1]
https://github.com/FortAwesome/Font-Awesome/blob/master/svg-with-js/js/fontawesome.js

[2]
https://github.com/FortAwesome/Font-Awesome/blob/master/advanced-options/svg-sprites/fa-solid.svg
[3]
https://raw.githubusercontent.com/FortAwesome/Font-Awesome/master/advanced-options/raw-svg/solid/address-book.svg
[4]
https://raw.githubusercontent.com/FortAwesome/Font-Awesome/master/advanced-options/metadata/icons.json
[5]
https://github.com/FortAwesome/Font-Awesome/blob/master/advanced-options/use-with-node-js/fontawesome-free-solid/faAddressBook.js

[6]
https://github.com/FortAwesome/Font-Awesome/blob/master/advanced-options/use-with-node-js/fontawesome-free-solid/faAddressBook.d.ts
[7]
https://github.com/FortAwesome/Font-Awesome/blob/master/advanced-options/use-with-node-js/fontawesome-free-solid/faAddressCard.d.ts

[8]
https://github.com/FortAwesome/Font-Awesome/tree/master/advanced-options/use-with-node-js/fontawesome-free
[9]
https://github.com/FortAwesome/Font-Awesome/tree/master/web-fonts-with-css
[10]
https://github.com/FortAwesome/Font-Awesome/tree/master/advanced-options/use-with-node-js/fontawesome-free-webfonts

[11]
https://github.com/FortAwesome/Font-Awesome/blob/master/advanced-options/use-with-node-js/fontawesome-svg-core/styles.css
[12]
https://github.com/FortAwesome/Font-Awesome/blob/master/advanced-options/use-with-node-js/fontawesome/styles.css

[13] https://www.fontsquirrel.com/tools/webfont-generator

[14]
https://raw.githubusercontent.com/FortAwesome/Font-Awesome/master/web-fonts-with-css/webfonts/fa-solid-900.svg

Simon McVittie writes ("Re: Font-Awesome 5 no build system DFSG compatibility"):

I have a different analysis, at least, as far as I currently
understand the situation.

What is going on here is that upstream are keeping some of the actual
source code (and yes, I think the Makefiles count - I agree with the
GPL's definition of source in this context) secret (perhaps
unintentionally).  We need to obtain it.  If we can't, then perhaps we
can produce an equivalent build sequence to replace the missing parts.

IMO for files which are built automatically by upstream, they should
be built automatically in Debian too.

This is quite different.  In those cases there is no other build
system.  When there is no other build system, then upstream are doing
the same manual thing that we are expecting ourselves, our users, and
our downstreams to do.

Thanks,
Ian.

I agree with Ian on this; build systems can have extra code in them that we may need (e.g., a build system that generates new files for a given computer that are then compiled into the final executable).  They aren't optional, not in Free software.

My personal rule of thumb is that if a human being generated the file, then we need that file.  Anything that is generated from human generated files (e.g., the icon that was generated from the GIMP file, or the executable from the original source files), doesn't need to be included.

From a security point of view, I'd prefer **not** to have any of the generated binaries as I can then look at all the sources (code, icon files, build system files, etc.) and choose if I'm going to run the final output or not.  A convenience binary that claims to be the output of a compilation step may or may not be, and it may be difficult to prove one way or the other (if the creator is caught, they may claim that they compiled using 'better' flags than the build system supplies).

Moreover, where do we draw the line?  I've written code generators before that generate VAST amounts of highly optimized code (think on the order of a million lines of C code in one file).  I could create a project where I open source the generated code, but keep the code generator to myself.  At that point, there is no simple method of checking the file; I might have hand-edited a few of the generated functions to do something 'extra'.  If you had the code generator in hand, you could check it, then compare its output against the file I supply to see if there are any differences.  The important thing here is that one human being is approximately equal to another human being in terms of level of effort required to generate or check material; if someone else had access to my code generator, it would take them approximately as long to check it as it took me to write it, so my ability to hide anything nefarious is dramatically limited[1].

So, I vote for requiring the build files **and anything else created by a human** before accepting it as open source.

Thanks,
Cem Karan

[1] Yes, you can do some really, really clever things to obfuscate what you're doing; witness The International Obfuscated C Code Contest (https://www.ioccc.org/), or The Underhanded C Contest (http://www.underhanded-c.org/).  However, you can't do the equivalent of a DOS attack on all people that are checking your code; I believe that the time to check human generated code versus create it is O(1) (although the constant that is hidden in there may be high).  A computer can generate infinite amounts of code in relation to the amount of input.  At that point, no human checker (or even team of checkers) can verify the output.

I would like to point out here that the build system exists, but is
both secret and proprietary, because upstream have a proprietary
version of the fonts that they are selling:

"Because Font Awesome sales a Pro version our build system will for
the time being remain private (we've got all of our for-pay icons in
there)."

Personally, I don't consider things proper Free Software unless they
are built using an automatic, repeatable and
reproducible/deterministic mechanism from freely licensed source using
only tools that are themselves proper Free Software. Modification of
that source also must be possible using only tools that are themselves
proper Free Software. In addition I don't accept something as proper
Free Software if upstream has created one form of data from another,
truer, source form, thrown away the source form (or never saved it)
and then distributes only the prebuilt form, which they use as if it
were source but in truth intend to keep it read-only.

Debian's standards are somewhat lower, we require source be available
and DFSG-freely licensed. In addition the ftp-master policy (not sure
about the rest of Debian) has a policy that packages be buildable (but
not necessarily built) using tools only in main. We don't yet require
an automated build process, we don't yet require rebuilding from
source by Debian, we don't yet require reproducible/deterministic
builds, we don't have a policy about tools to modify the source, we
err on the side of taking upstream's word for it about source and we
don't have any policy about what counts as proper source.

Hi all,

In case you didn't see it, their is a fork of font-awesome here:
https://forkawesome.github.io/Fork-Awesome/

It could perhaps solve DFSG potential problem ?

Cheers,
Xavier

 > In case you didn't see it, their is a fork of font-awesome here:
 > https://forkawesome.github.io/Fork-Awesome/
 >
 > It could perhaps solve DFSG potential problem ?

I have contacted the guys from forkawesome to ask about fontawesome v5
compatibility:
  - https://github.com/ForkAwesome/Fork-Awesome/issues/112

Cheers,

I’m one of the core developers on the Font Awesome project. I can answer any specific questions and I’ll try and help where I can.

Probably the first question to get out of the way is: “Will Font Awesome open source their build tool?”

And the answer is no for the time being.

What are the other obstacles to getting version 5 added as a package?

Le 27/09/2018 à 23:11, Rob Madole a écrit :

I think a good start is to answer to these questions:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902981#57

Remember that DFSG is a guidelines (not a set of rules), so Debian
community will decide if version 5 is free/acceptable or not. You may
have to convince us that your package is "libre" ;-).

Personally, I stopped font-awesome upgrade to version 4.7 in my projects
(https://lemonldap-ng.org Web-SSO for example).

Another solution is to use "non-free" branch. This is not part of Debian
release but is distributed in parallel. Note also that in this case,
every package which depend on version 5 will be forced out of Debian
release to fall back to "contrib" branch.

Cheers,
Xavier

Thank you for getting in touch!

There are no other obstacles.

To catch you up on the situation, here is a summary:

For software to be considered to be included in Debian, it must be free
software. We try to evaluate whether or not something is free software
by using the Debian Free Software Guidelines (DFSG)[1].

Font Awesome matches the DFSG on all points except one:

 > The program must include source code, and must allow distribution in
source code as well as compiled form.

Font Awesome v5 is only available in compiled form, without the build
tool. This makes it incompatible with our definition of Free Software.

To help explain our definition of source code, we often refer to "All
sources in their preferred form of modification".

For example, minified JavaScript would fail that definition, even if it
could technically be considered as modifiable code.

Is there something that could be done so that Font-Awesome v5 can match
this interpretation of what is free software?

1. https://www.debian.org/social_contract#guidelines

Thanks again,

Ah, thanks for summarizing for me, Alexandre. There isn’t anything more we can do at the moment. While the license is compatible (MIT, SIL OFL 1.1, CC BY 4.0) if our build tool is required we can’t provide that. I’ll stay subscribed to this issue if there is any follow up.

Rob

Could you provide some details about why this is? It might be that we
can offer some ideas for ways forward if given more information.

For example you could adopt a new build toolchain for the open source
version of the font, while keeping the existing build tool for the
proprietary version.

Hello,

I have been in touch with the guys at Fork-Awesome and I have exposed
them the following problem[1]:

 - We want to package Font-Awesome v5 projects in Debian, however, the
migration from Font-Awesome V5 to Fork-Awesome can be cumbersome.

In response to this, they have developed a compatibility layer, helping
Font-Awesome v5 users migrate to Fork-Awesome with minimal efforts:
 - Font-Awesome V5 icon names that also exist in Fork-Awesome are
   supported as aliases
 - Font-Awesome V5 classes are aliased to their equivalent Fork-Awesome
   class.

The only icons that would stop working after such a migration are icons
that are only available in Font-Awesome V5.

It may be that Fork-Awesome has very similar icons that can be used as a
replacement. In that case, it may even be worth to add a new alias,
which we did for the Font Awesome Sync icon that looked very similar to
the Fork Awesome Refresh.[2]

I have been in touch with Syncthing and they have merged my patch that
transitions Syncthing to Fork-Awesome[3]. As you can see, the diff is
very minimal and the transition was seamless. Upstream understood the
problem and was happy to move to Fork-Awesome.

Even if the patch wasn't merged by Syncthing, it would have been
reasonable to maintain the patch in Debian.

I suggest that the next step are:
 - We package Fork-Awesome for Debian
 - We patch Debian packages that require Font-Awesome v5 so that they
   use Fork-Awesome, and submit the patches upstream.

1. https://github.com/ForkAwesome/Fork-Awesome/issues/112
3. https://github.com/ForkAwesome/Fork-Awesome/issues/115
3.
https://github.com/syncthing/syncthing/commit/a4d27282aee2fe63758dd020bc91be30c6a70469

Cheers,

Hello,


I just wanted to mention that I have uploaded Fork-Awesome to new.

Thanks for the Font-Awesome packaging, this was quick and easy.

The ITP bug is here:
 - https://bugs.debian.org/910256

Cheers

X-Debbugs-Cc: sebastic@xs4all.nl

When you search Debian it turns out, Font Awesome 5 is around in A LOT of packages.
A good starting point is https://lintian.debian.org/tags/font-in-non-font-package.
It will take a lot of effort to get it out. I have started at #1025000.

I agree with Alexandre here but there seem to be people that ignore this sentiment
as you can see at #1027982. How would we go about it?

Quoting Bastian Germann (2023-01-24 16:28:59)

Thanks for looking into this, Bastian.

You are correct in filing such bugs with high severity.

If the reaction as seen with bug#1027982 is more widespread, you might
consider adding a usertag to those bugreports, to ease later raising as
a general concern to debian-devel the issue of relaxed treatment of
licensing violations.

 - Jonas

I am waiting for node-webfont to be accepted into the archive (it is
currently sitting in NEW).  Once that happens, I believe that I will
be able to take the DFSG-free SVG files and some other data files from
the upstream FontAwesome GitHub repository and build the FontAwesome 5
and 6 fonts from source.  I will base my code heavily on
https://github.com/Templarian/MaterialDesign-Font-Build; see what I've
done in a draft new version of the Material Design Icon font in my
experimental packages at
https://salsa.debian.org/debian/fonts-materialdesignicons-webfont
(though the change in version -2 getting rid of the fontname
distinctions turns out to be wrong and I will revert to the version -1
scheme some point soon).

This will mean that we will be able to ship a DFSG-free version of
FontAwesome 5 and 6 in Debian; the webfonts may well not be
byte-identical to the upstream versions, but they should be
functionally identical.  We can then ask the maintainers of the
packages shipping these fonts to replace the embedded fonts with links
to the DFSG-free versions.

If you would like me to go ahead and work on this, please say.
Practically speaking, this will be for bookworm+1 as there is no hope
of getting any new version of FontAwesome into bookworm at this point
- node-webfont is still waiting in NEW, and may not itself make it
into bookworm, so I won't try to do it until after the bookworm
release.  (I would add myself to the Uploaders, and make the source
package produce separate binary packages for FontAwesome 4.7, 5 and
6.  I would also ask for a review from the Debian Fonts Team list
before uploading.)

Best wishes,

   Julian

Quoting Julian Gilbey (2023-01-29 12:03:30)

Sure I would like you to go ahead - why would I not want that?

Sounds like a fun project, and Free, and beneficial to Debian.

One thing you might consider is to name the resulting package something
(similar but) different than fontawesome, to not upset upstream
developers by hijacking their name for something arguably different.


 - Jonas

Great!

A good point.  I was thinking of creating a GitHub project called
FontAwesome-DFSG, with a README explaining what is it, how it was
created and how it is not endorsed by the FontAwesome "owners".  But
I'm not sure what to call the Debian package - it is essentially just
a repackaging of the FontAwesome fonts.  Perhaps we could call the
source package fonts-font-awesome-dfsg, and the binary packages
fonts-font-awesome-4.7, fonts-font-awesome-dfsg-5,
fonts-font-awesome-dfsg-6 and fonts-font-awesome-dfsg (for the current
version of the upstream font)?

I'm open to ideas!

Best wishes,

   Julian

Hi Julian,this is highly appreciated, thanks for all the effort you put into this!I'd recommend to avoid the "awesome" part of the name altogether. Font Awesome upstream apparently changed his mind and had become rather hostile towards open development, so we shouldn't give them more reason to feel under attack. How about "font-dfsgsome" or "font-handsome" or whatever wordplay you like? - Fabian Von meinem/meiner Galaxy gesendet
-------- Ursprüngliche Nachricht --------Von: Julian Gilbey <jdg@debian.org> Datum: 29.01.23  13:21  (GMT+01:00) An: Jonas Smedegaard <jonas@jones.dk> Cc: 902981@bugs.debian.org, Bastian Germann <bage@debian.org> Betreff: Bug#902981: Font Awesome v5 in Debian On Sun, Jan 29, 2023 at 12:21:29PM +0100, Jonas Smedegaard wrote:> Quoting Julian Gilbey (2023-01-29 12:03:30)> > If you would like me to go ahead and work on this, please say.> > Sure I would like you to go ahead - why would I not want that?> > Sounds like a fun project, and Free, and beneficial to Debian.Great!> One thing you might consider is to name the resulting package something> (similar but) different than fontawesome, to not upset upstream> developers by hijacking their name for something arguably different.A good point.  I was thinking of creating a GitHub project calledFontAwesome-DFSG, with a README explaining what is it, how it wascreated and how it is not endorsed by the FontAwesome "owners".  ButI'm not sure what to call the Debian package - it is essentially justa repackaging of the FontAwesome fonts.  Perhaps we could call thesource package fonts-font-awesome-dfsg, and the binary packagesfonts-font-awesome-4.7, fonts-font-awesome-dfsg-5,fonts-font-awesome-dfsg-6 and fonts-font-awesome-dfsg (for the currentversion of the upstream font)?I'm open to ideas!Best wishes,   Julian

Please don't take the following info as stop-energy (which it's not), but
there is already an active project doing the task of liberating the
no-longer-free symbols from Font Awesome, called ForkAwesome:
https://github.com/ForkAwesome/Fork-Awesome ... which has also added a fair
number of new glyphs since it was founded (6+ years ago).

It's also already packaged for Debian. I certainly agree that it's a
problem that too many other packages pull in FoNT Awesome as a dependency,
but the harder work is in persuading maintainers to switch. Convincing them
to utilize a package that is already available to them would, I think, be
quicker. ForkAwesome certainly hasn't reached 100%, so maybe some people
will never make that switch.

But perhaps I misunderstand what you're wanting to do; if you are wanting
to do something different than what ForkAwesome already does, like just
build a new build script to show it can be done, I may be missing the
nuance.

However, If it's just about fixing the dependent packages, having two forks
of the original runs some risk of confusing people, and it does kind of
divide the community momentum.

Nate

Hi Nathan,

We have switched to ForkAwesome for (python3-)qtawesome following the
bug report about FontAwesome not being free.  Unfortunately, it has
not had a commit since December 2021 and no new icons since September
2021.  It has many, many fewer icons than FontAwesome, and in many
cases cannot be used as a replacement for it.

My proposal is *not* to create fonts which mimic FontAwesome.  The
only issue for Debian (as evidenced by the discussion in this bug
report) is that the fonts cannot be recreated from the SVG files.  The
license that upstream have used on their fonts and SVG files is
generously open, and their only (public) reason for not sharing their
build process publicly is that their commercial offerings use the same
infrastructure.

Therefore the only thing that I am proposing is writing an open-source
build structure for recreating the FontAwesome webfonts from the SVG
sources.  As most of the work has already been done by other people,
this should be relatively straightforward, and will be able to keep
up-to-date with upstream's font offerings.

The resulting webfonts should be drop-in replacements for the upstream
versions, offering exactly the same icons.

I hope that makes a little more sense.

Best wishes,

   Julian

Hi Fabian,

That's a good point; I'm not sure about this, though, as I don't want
to suggest that this is a different font - it isn't, it's just a DFSG
packaging of the same font.

If there's a trademark issue, though, then of course that's a
different matter.

Best wishes,

   Julian

Please note that node-fortawesome-fontawesome-free builds the
fortawesome v6 from source now. So there is a chance that we can update
this package as well.

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

Hi Debian legal list!

I'd appreciate your suggestions on how best to manage this issue that
I've discovered, and a judgement call on whether it is an issue - see
below.  I've cc'd the current bug report.

Best wishes,

   Julian

----- Forwarded message from Julian Gilbey <jdg@debian.org> -----

Date: Wed, 13 May 2026 22:27:00 +0100
From: Julian Gilbey <jdg@debian.org>
Subject: DFSG status of fonts-font-awesome (was: Re: Bug#902981: new upstream
	(5.1.0))
To: Bastian Germann <bage@debian.org>, 902981@bugs.debian.org
Cc: 1135180@bugs.debian.org, Debian developers list
	<debian-devel@lists.debian.org>

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
----- End forwarded message -----

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

It is very Figma-specific. We’re using lots features in our system that only work in Figma (like symbols) and it would be very lossy to export to SVG and then re-import to Figma. For example, our individual shapes are not combined into a single compound path until the SVG export. That’s not something you can reverse.

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.

clone 902981 -1
retitle -1 "fonts-font-awesome: DFSG status of FontAwesome fonts"
thanks

I realise that the original focus of this bug report - upgrading
fonts-font-awesome - has become intertwined with questions of the DFSG
status of the fonts.  So I'm splitting this into two separate bug
reports.

My plan is to upgrade the package, as requested originally, and close
the original bug with that (#902981), leaving the DFSG question in a
separate, open bug report.

Best wishes,

   Julian

retitle 1140315 "fonts-font-awesome: questionable DFSG status of FontAwesome fonts"
severity 1140315 important
tags 1140315 - fixed-upstream
notforwarded 1140315
severity 1136707 important
merge 1136707 1140315
thanks

The arguments given in these bug reports currently seem a bit ad hoc
to me - there seems no strong reason to regard the licensing of
ForkAwesome as any better or worse than that of FontAwesome.  So I'm
marking both of these bugs as severity "important" and merging them
for now, until we can come up with a genuine, workable resolution.

(Note that #1140315 is a clone of #902981, focusing on the DFSG status
of the font package.)

Best wishes,

   Julian