Re: Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome
On Tuesday, June 2, 2026 11:28:49 PM Mountain Standard Time Julian Gilbey wrote: > On Mon, May 25, 2026 at 02:14:14PM +0200, Jonas Smedegaard wrote: > > [...] > > 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. > > [...] > > 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. 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. -- Soren Stoutner [email protected] signature.asc Description: This is a digitally signed message part.
Re: Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome
On Mon, May 25, 2026 at 02:14:14PM +0200, Jonas Smedegaard wrote: > [...] > 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. > [...] 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
Re: Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome
On Mon, May 25, 2026 at 02:14:14PM +0200, Jonas Smedegaard wrote: > [...] > > 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. That seems an understandable concern for etoys, but not particularly relevant here - the SVG format is textual and easy to audit. > 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. 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. > 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? 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
Re: Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome
Quoting Julian Gilbey (2026-05-25 13:27:12) > On Sat, May 23, 2026 at 01:55:55PM -0700, Don Armstrong wrote: > > On Wed, 20 May 2026, Philipp Kern wrote: > > > 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. > > > > 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. > > Dear all, > > 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. 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 -- * Jonas Smedegaard - idealist & Internet-arki
Re: Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome
On Sat, May 23, 2026 at 01:55:55PM -0700, Don Armstrong wrote: > On Wed, 20 May 2026, Philipp Kern wrote: > > 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. > > 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. Dear all, 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
Re: Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome
On Wed, 20 May 2026, Philipp Kern wrote: > 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. 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. -- Don Armstrong https://www.donarmstrong.com [T]he question of whether Machines Can Think, [...] is about as relevant as the question of whether Submarines Can Swim. -- Edsger W. Dijkstra "The threats to computing science"
Re: Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome
On 5/19/26 11:11 PM, Soren Stoutner wrote: 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
Re: Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome (was: Re: Bug#902981: new upstream (5.1.0))
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.
Re: Bug#1135180: Bug#902981: DFSG status of fonts-font-awesome (was: Re: Bug#902981: new upstream (5.1.0))
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
