Re: SIL OFL 1.1 plus "reserved font name" is DFSG?

--nextPart2133787.8dbBeuWlQP
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Soren Stoutner <[email protected]>
To: [email protected]
Subject: Re: SIL OFL 1.1 plus "reserved font name" is DFSG?
Date: Fri, 17 Apr 2026 21:12:19 -0700
Message-ID: <4164096.NbLGIdUMDz@soren-desktop>
Organization: Debian
In-Reply-To: <[email protected]>
MIME-Version: 1.0

On Thursday, April 16, 2026 3:35:33=E2=80=AFPM Mountain Standard Time Nicho=
las D=20
Steeves wrote:
> That's an interesting point, because it means the font can be rebuilt
> and then other metadata potentially added back in with a binary patch.
> I presume that you mean bits and not typographically identical (ie:
> rendering the upstream font to an image, rendering the Debian-built copy
> to an image, then comparing the images pixel-for-pixel).

This is what the OSL FAQ says about this topic:

"5.9  Do font rebuilds require a name change? Do I have to change the name =
of=20
the font when my packaging workflow includes a full rebuild from source?"

"Yes, all rebuilds which change the font data and the smart code are Modifi=
ed=20
Versions and the requirements of the OFL apply: you need to respect what th=
e=20
Author(s) have chosen in terms of Reserved Font Names. However if a package=
=20
(or installer) is simply a wrapper or a compressed structure around the fin=
al=20
font - leaving them intact on the inside - then no name change is required.=
=20
Please get in touch with the author(s) and copyright holder(s) to inquire=20
about the presence of font sources beyond the final font file(s) and the=20
recommended build path. That build path may very well be non-trivial and ha=
rd=20
to reproduce accurately by the maintainer. If a full font build path is mad=
e=20
available by the upstream author(s) please be aware that any regressions an=
d=20
changes you may introduce when doing a rebuild for packaging purposes is yo=
ur=20
responsibility as a package maintainer since you are effectively creating a=
=20
separate branch. You should make it very clear to your users that your rebu=
ilt=20
version is not the canonical one from upstream.=E2=80=9D

https://openfontlicense.org/ofl-faq/
=20
> I looked into this and found that ttf-bitstream-vera is packaged as-is
> from upstream.  Fonts-dejavu is built from source.  Both have a
> restriction that is more strict than a reserved name (neither
> "Bitstream" nor "Vera" may be used anywhere in the derivative font) as
> well as the discrimination against selling the fonts.

Requiring forks to use a different name is a common practice and considered=
=20
DFSG-free.  In some cases, this is a requirement of trademark law, which is=
 a=20
slightly separate subject from copyright law.

Regarding the restriction of some of these fonts to not allow people to sel=
l=20
them by themselves, this feels like it is DFSG-non-free to me, but Debian=20
appears to have decided to accept this restriction.  That was a decision ma=
de=20
before my time and I am not aware of the particulars of it.  In addition to=
=20
the examples you list in the paragraph above, this is also a restriction of=
=20
the OFL (even without reserved names).

This restriction was probably accepted because it only applies to selling t=
he=20
fonts when they are distributed by themselves and not when they are=20
distributed with other software.  This does not directly impact selling Deb=
ian=20
or any Debian derivatives, as a Linux distribution will always include othe=
r=20
software with the fonts.

If someone does know the history of how this decision was make, I would be=
=20
interested in reading it.

=2D-=20
Soren Stoutner
[email protected]
--nextPart2133787.8dbBeuWlQP
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+wufLJ66wtgMFAmnjBKMACgkQwufLJ66w
tgMrSRAAglSf9bTCLYmMRqUoYXe8mLMqyO9jP5b3v/UpnzhyiA02RCJ+3m9wGKlg
VkYadfGgCgETNVrkerkIojhhgT3A7LCW+USXgivDODL2DSiV+6te3+MeDFfqkWkT
YkaouiTJCuXMH9kqETktMUEgX+0aOXGbA/rdklT03dXiloy/SoUJCIlDC3oXxjJI
6CkCrklgMWXDKZAcZe72s1wa3toEd5jx641gGtKMJUS9Lz4iO2Ad2gWimP82LyfR
v9gRHrTSpJM0NvjWijALfKuls0bxSNOx87WV2cVFnW92GbRnypoNB/qYvse98+4s
8FuBc+d2+DL0TC1RUX85rEo8JlY9Udm1mcU7SCZAaQDF13qSHmpz6LP0UkTUtjz6
cY7pssk6Ti0Px/E2blGzEkjILT/ewHXDAPeygNF3oCfJcA8qpFzOA485/7D0OQNI
WomJM4i9APSD36+jDieuocGWekqTlcr/MS8wUx5YO2ls4azk4jbuj6WzntwqZEnh
BsgE134j0AtlVRGES3zsxvee6R36CxOV8ELrmkTzqc1prPewecj0FFeA1JWIXJj0
W6/WSFmFuSgtQUL/6ByHj5KH681FDoynEEtXkJw9FPi/T/QGP1zI0ECz3NT6/eBO
9v/uWB8sWduU22u1YAe3aYyh6cNPeWBnzFCX/JHL0RYQoCIr7pc=
=hDv5
-----END PGP SIGNATURE-----

--nextPart2133787.8dbBeuWlQP--