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.
