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
