Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome (was: Re: Bug#902981: new upstream (5.1.0))

2026-05-19 Thread Soren Stoutner 
On Tuesday, May 19, 2026 12:39:55 PM Mountain Standard Time Julian Gilbey 
wrote:
> > 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.
> 
> 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).

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.

-- 
Soren Stoutner
[email protected]

signature.asc
Description: This is a digitally signed message part.

Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome (was: Re: Bug#902981: new upstream (5.1.0))

2026-05-19 Thread Julian Gilbey 
On Tue, May 19, 2026 at 09:54:04AM -0700, Soren Stoutner wrote:
> On Monday, May 18, 2026 10:44:34 PM Mountain Standard Time Julian Gilbey 
> wrote:
> > 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.
> 
> I cannot speak for the entire debian-legal community, but as one of the more 
> prolific posters on the list, these are my thoughts.

Hi Soren,

Thanks for these thoughts!  A few comments interspersed.

> 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.

Yes, SVG was the preferred form of modification: to the best of my
understanding, the SVG files were regarded as the master icon files in
the ForkAwesome project.

> 4.  Seeing as how both FontAwesome and ForkAwesome are now archived projects, 
> they are not receiving further modifications upstream.

This is not quite correct: FontAwesome version 4.7.0, which is used by
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).

> 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.

For the purpose of packaging ForkAwesome, I presume you mean?

> 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.

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).

> It is possible that I have missed something or misunderstood the situation in 
> some way, so I would appreciate any critiques of the above.

Best wishes,

   Julian

Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome (was: Re: Bug#902981: new upstream (5.1.0))

2026-05-19 Thread Soren Stoutner 
On Monday, May 18, 2026 10:44:34 PM Mountain Standard Time Julian Gilbey 
wrote:
> 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.

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.

> 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!



-- 
Soren Stoutner
[email protected]

signature.asc
Description: This is a digitally signed message part.

Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome (was: Re: Bug#902981: new upstream (5.1.0))

2026-05-19 Thread Rob Madole 



> On May 19, 2026, at 12:44 AM, Julian Gilbey  wrote:
> 
> 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.  

Hey 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? 

> We
> *do* want to keep FontAwesome around - it is so amazing (awesome?!)
> and so ubiquitous!

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. :)

> 
> Best wishes,
> 
>   Julian

Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome (was: Re: Bug#902981: new upstream (5.1.0))

2026-05-18 Thread Julian Gilbey 
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

On Mon, May 18, 2026 at 01:38:28PM -0500, Rob Madole wrote:
> 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.
> 
>   On May 18, 2026, at 10:42 AM, Julian Gilbey  wrote:
>   Dear all,
> 
>   On Fri, May 15, 2026 at 06:39:10PM +0100, Julian Gilbey wrote:
> 
> On Fri, May 15, 2026 at 05:52:49PM +0100, Nathan Willis wrote:
> [...]
> 
>   I may have missed something in here, but how do you know that the SVGs 
> in
>   the
>   font are not the source SVGs?
> 
> Hi Nathan!
> 
> Good question; I'm not sure we do.  The SVG font file
> (fontawesome-webfont.svg) begins:
> [...]
> 
> 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.
> [...]
> 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.
> [...]
> 
>   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

Bug#902981: Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome (was: Re: Bug#902981: new upstream (5.1.0))

2026-05-18 Thread Rob Madole 
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.

> On May 18, 2026, at 10:42 AM, Julian Gilbey  wrote:
> 
> Dear all,
> 
> On Fri, May 15, 2026 at 06:39:10PM +0100, Julian Gilbey wrote:
>> On Fri, May 15, 2026 at 05:52:49PM +0100, Nathan Willis wrote:
>> [...]
>>> 
>>> I may have missed something in here, but how do you know that the SVGs in 
>>> the
>>> font are not the source SVGs?
>> 
>> Hi Nathan!
>> 
>> Good question; I'm not sure we do.  The SVG font file
>> (fontawesome-webfont.svg) begins:
>> [...]
>> 
>> 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.
>> [...]
>> 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.
>> [...]
> 
> 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
> 
> -- 
> To unsubscribe, send mail to [email protected].

Bug#902981: Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome (was: Re: Bug#902981: new upstream (5.1.0))

2026-05-18 Thread Julian Gilbey 
Dear all,

On Fri, May 15, 2026 at 06:39:10PM +0100, Julian Gilbey wrote:
> On Fri, May 15, 2026 at 05:52:49PM +0100, Nathan Willis wrote:
> [...]
> > 
> > I may have missed something in here, but how do you know that the SVGs in 
> > the
> > font are not the source SVGs?
> 
> Hi Nathan!
> 
> Good question; I'm not sure we do.  The SVG font file
> (fontawesome-webfont.svg) begins:
> [...]
> 
> 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.
> [...]
> 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.
> [...]

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

Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome (was: Re: Bug#902981: new upstream (5.1.0))

2026-05-15 Thread Julian Gilbey 
On Fri, May 15, 2026 at 05:52:49PM +0100, Nathan Willis wrote:
> On Wed, May 13, 2026 at 10:29 PM Julian Gilbey  wrote:
> 
>   that the package as-is is actually not DFSG-free in the same way that
>   the 5.x version isn't: there is no "source code".  And 4.x is even
>   worse than 5.x: while the SVG sources are included in the GitHub
>   repository in version 5.1.0 upwards (first committed to the repository
>   in June 2018), they do not appear before that, so there is no hope of
>   making a DFSG-free build of FontAwesome 4.7.0.  (The SVG sources are
>   embedded in the SVG font, but that is not the original source of the
>   icons.)
> 
> I may have missed something in here, but how do you know that the SVGs in the
> font are not the source SVGs?

Hi Nathan!

Good question; I'm not sure we do.  The SVG font file
(fontawesome-webfont.svg) begins:


Created by FontForge 20120731 at Mon Oct 24 17:37:40 2016
 By ,,,
Copyright Dave Gandy 2016. All rights reserved.


So perhaps this is the original source for the font.  FontForge is
quite happy to open it and allow editing, and this would not be a
reason to consider FontAwesome 4.7.0 to be non-DFSG free.

We do know that from FontAwesome 5.1.0, the SVGs are provided as
individual files, one per icon.  We also know that the process of
producing the other format font files (eot, woff, woff2, otf) from the
source (whether that is the SVG font file or individual SVG files) is
not documented, and that was the reason given for not allowing version
5.1.0 into Debian.

Looking further at FontAwesome 4.7.0:

* fontawesome-webfont.{eot,ttf} and FontAwesome.otf all contain the
  string "FONTLAB:OTFEXPORT", so presumably these were generated by
  FontLab (non-free software)

* I don't know how to uncompress the .woff/.woff2 files to see if
  there is any identifying information there.  But my guess is that
  these were also generated using FontLab.

> In most other SVG-in-OT fonts I have seen, there is not much done to input 
> SVGs
> before they are added to the `SVG ` table. The Adobe builder kind of
> halfheartedly compacts them (just shrinking whitespace runs), but even it
> doesn't do a full spec-compliance "cleaning" stage or so on. And that's for 
> real
> emoji fonts, too, where they arguably have more validation to worry about.

So we could take fontawesome-webfont.svg to be Open Source (which the
ForkAwesome team did), and generate the other formats from it using
open source tools (fontforge seems the obvious choice; it can be
scripted to do the conversion).  That seems a much better solution
than my original one of dropping FontAwesome 4.7.0 completely and
requiring all other packages to adapt to the change.

If we can do that, then I would also suggest that fonts-font-awesome
should continue to provide FontAwesome 4.7.0 for the time being to
avoid other packages having to do anything urgently.

What would we say about having these FontLab-converted fonts in
Debian, though?  As I observed, they are ubiquitous.

>   My proposal is therefore the following:
> 
>   - FontAwesome 4.7.0 should be dropped from Debian completely.  This is
>     a big deal, though; over 500 packages in testing ship
>     fontawesome-webfont.woff2  But if I've read the situation correctly,
>     that is the direction we should be heading in, though that's far
>     beyond my capacity to manage.  See below for some further thoughts
>     on this.
> 
>   - fonts-font-awesome is upgraded to version 7.x of the upstream font,
>     in TTF and WOFF2 formats, using a home-grown DFSG-free build system
>     (courtesy of Roland Mas and Yadd, who wrote this for the
>     node-fortawesome-fontawesome-free package); this package will no
>     longer contain any other formats of the font, nor any CSS/LESS/JS
>     code.
> 
> Can you provide a link to this tool? Or was there one earlier in the thread 
> that
> I may just have missed? That's tangential; I just hadn't encountered it.

The tool is just a script in the node-fortawesome-fontawesome-free and
fonts-fontawesome-legacy source packages (debian/build-font.py).

Best wishes,

   Julian

Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome (was: Re: Bug#902981: new upstream (5.1.0))

2026-05-15 Thread Nathan Willis 
On Wed, May 13, 2026 at 10:29 PM Julian Gilbey  wrote:

that the package as-is is actually not DFSG-free in the same way that
> the 5.x version isn't: there is no "source code".  And 4.x is even
> worse than 5.x: while the SVG sources are included in the GitHub
> repository in version 5.1.0 upwards (first committed to the repository
> in June 2018), they do not appear before that, so there is no hope of
>


> making a DFSG-free build of FontAwesome 4.7.0.  (The SVG sources are
> embedded in the SVG font, but that is not the original source of the
> icons.)
>

I may have missed something in here, but how do you know that the SVGs in
the font are not the source SVGs?

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:
>
> - FontAwesome 4.7.0 should be dropped from Debian completely.  This is
>   a big deal, though; over 500 packages in testing ship
>   fontawesome-webfont.woff2  But if I've read the situation correctly,
>   that is the direction we should be heading in, though that's far
>   beyond my capacity to manage.  See below for some further thoughts
>   on this.
>
> - fonts-font-awesome is upgraded to version 7.x of the upstream font,
>   in TTF and WOFF2 formats, using a home-grown DFSG-free build system
>   (courtesy of Roland Mas and Yadd, who wrote this for the
>   node-fortawesome-fontawesome-free package); this package will no
>   longer contain any other formats of the font, nor any CSS/LESS/JS
>   code.
>

Can you provide a link to this tool? Or was there one earlier in the thread
that I may just have missed? That's tangential; I just hadn't encountered
it.

Thanks,
Nate


-- 
nathan.p.willis
[email protected]

Bug#902981: DFSG status of fonts-font-awesome (was: Re: Bug#902981: new upstream (5.1.0))

2026-05-14 Thread Reinhard Tartler 
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.

-rt on behalf of the DFSG team

Bug#902981: DFSG status of fonts-font-awesome (was: Re: Bug#902981: new upstream (5.1.0))

2026-05-14 Thread Julian Gilbey 
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  -

Date: Wed, 13 May 2026 22:27:00 +0100
From: Julian Gilbey 
Subject: DFSG status of fonts-font-awesome (was: Re: Bug#902981: new upstream
(5.1.0))
To: Bastian Germann , [email protected]
Cc: [email protected], Debian developers list


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.]

On Mon, Mar 30, 2026 at 10:07:53PM +0200, Bastian Germann wrote:
> 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.

Also, in #1135180, Bastian wrote:

> 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.

Dear all readers of this bug report,

[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 a