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

Soren Stoutner <[email protected]> Tue, 19 May 2026 14:11:29 -0700
Newsgroups gmane.linux.debian.devel.legal,gmane.linux.debian.devel.general,gmane.linux.debian.devel.fonts
Organization Debian
Message-ID <2228622.OBFZWjSADL@soren-desktop>
--nextPart2297406.NgBsaNRSFp
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Soren Stoutner <[email protected]>
Date: Tue, 19 May 2026 14:11:29 -0700
Message-ID: <2228622.OBFZWjSADL@soren-desktop>
Organization: Debian
In-Reply-To: <[email protected]>
MIME-Version: 1.0

On Tuesday, May 19, 2026 12:39:55=E2=80=AFPM Mountain Standard Time Julian =
Gilbey=20
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 a=
nd
> > that any future modifications will be made by directly editing those=20
files.
> >  Then, that fork could be packaged in Debian.
>=20
> 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 =E2=80=9Cpreferre=
d form of=20
modification=E2=80=9D.  Preferred form of modification is not a phrase that=
 occurs in=20
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=
=20
modifications to it.=E2=80=9D

The DFSG does not define what source code is.  It simply states:

"The program must include source code, and must allow distribution in sourc=
e=20
code as well as compiled form.=E2=80=9D

https://www.debian.org/social_contract

In general, Debian uses a definition of source code that aligns with the id=
ea=20
of preferred form of modification, which is generally understood to mean th=
at=20
the source files upstream modifies when they want to change the program mus=
t=20
be available to the downstream users of Debian, and Debian must be able to=
=20
build the package from those files (meaning that there needs to be DFSG-fre=
e=20
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 alwa=
ys=20
indicate if it is the original source code or not, and the preferred form o=
f=20
modification can *change* over time.

SVG is one of these example file types than can sometimes be the preferred=
=20
form of modification and other times isn=E2=80=99t.

When upstream wants to make changes in the font, if they are directly editi=
ng=20
some other file and then using that file to generate a SVG and other font=20
formats, then to be DFSG in Debian, we need to also have access to that=20
original file under a DFSG-license and be able to generate the resulting fo=
nts=20
during the build process.  This is important because, as has already been=20
mentioned in this thread, when an SVG is generated from another file, there=
=20
are often subtle differences in the output.  So, if Debian is not using the=
=20
same source as upstream, and is thus producing different output than upstre=
am,=20
that makes the package DFSG-non-free.  But if upstream is editing the SVG f=
ile=20
directly to make changes in the font, then the SVG file has become the=20
preferred form of modification, Debian packages will be identical to upstre=
am=20
releases, and Debian users and anyone else who would like to fork the proje=
ct=20
is on equal footing with upstream in their ability to use and modify the=20
source files.

The fascinating part of this discussion is that sometimes the preferred for=
m=20
of modification can change.  For example, consider an HTML file that for ma=
ny=20
years was generated by DocBook from an XML input file.  Imagine that at som=
e=20
point upstream decides they no longer wanted to use DocBook, and choose to =
use=20
the previous HTML output from DocBook as their new source file, which they=
=20
would edit manually going forward.  That HTML file would then become the=20
preferred source of modification.

In the case of these fonts, if Debian were trying to package any of the=20
versions that were still under active development, it would be important th=
at=20
we could build them from the original source files that upstream uses to bu=
ild=20
them.  Even if they ship SVG files, it would not be sufficient for us to bu=
ild=20
from those.

However, with archived projects (or archived old versions if all we intend =
to=20
do is package the old version), it becomes less of an issue because none of=
=20
the files are being updated by upstream any longer, which means that upstre=
am=20
is no longer accepting patches, so any modification of the package would be=
 a=20
fork.  If anyone has concerns about whether whether SVG is the preferred fo=
rm=20
of modification for FontAwesome, they can fork the project, give it a new=20
name, state that all future modifications will be done directly to the SVG=
=20
files (even if there are never actually any changes made), and all the=20
requirements to be DFSG-free are met.

=2D-=20
Soren Stoutner
[email protected]
--nextPart2297406.NgBsaNRSFp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmoM0gEACgkQwufLJ66w
tgObAA//XVOL+4UoChlUgmSGNpciW1jk6I28HJkXYoEOAzERZWWcHilv+LG5ZWe4
h8nwuMXiGQy5zEfXntnT9gXClQun99r5WRzeMKfJtJwkohG0rFSyqSaNX3Qx+vvx
RR6BVTVXiSYE5tPq3KJingkKqA8NztAJka6LzD0ZsjTB0WklLcZbQiGDe/clLmz6
cYB3FQ91g1R0YUwm31oA3q1sUQMAzZqgr8zE+tzFkxDKJSSbmTrSVBNn8I36xC2o
OOf88GIhGXoy2fSNKfB3VK0sqM0A9lcOuwzrb8UyvTgHWOhk1cA98xVI4zkTWU+Q
+HDwW2ACHwM6kJJn9zOpjDb+qETRWcNhurvZBagwoPYyo5SVk/em4Ruy5YMcwjle
gsyul3gD7Z7nAvJ2Nv2LhbrxvTlC412ybcxdYOV9NuPRoAxSwVCsiP0Bjq6zPRw+
YzxyavuJJGEq8v7HOMhgJBf8KQrY79DEKZjPrui7m1BbHTE/zWVD5bqGkJih5k1R
3Ijqeavq+L0E1MS3Qfz+6xXnkBv5lu6xGzNU42KAWs+lX9pAszFT0YG0TagPcvAq
2k7qswoWZX1u2MfX0qr8RsP3m0t1npfwlN7ukzi/IG/oEcbxCSxDK/DbwWXW+DtJ
sd/paZgfV+GC2S6Lc0mdeKekU6oaDBw+r4pktIvgAHciH6ygCVI=
=szDq
-----END PGP SIGNATURE-----

--nextPart2297406.NgBsaNRSFp--