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

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Soren and Dave,

Very belated thank you for taking the time to explain the historical
precedents as well as a (potential) workaround. (lots of reasons for the
delay, including hardware failure).  Reply follows inline.

Soren Stoutner <[email protected]> writes:

> On Friday, February 13, 2026 12:57:38=E2=80=AFPM Mountain Standard Time G=
ioele=20
> Barabucci wrote:
>> 2025-01-29 16:17:47 -0700 Soren Stoutner:
>> > There is documentation here:
>> >=20
>> > https://wiki.debian.org/Fonts/Bugs/rfn-violation
>>=20
[snip]
>> IN GENERAL, no: rebuilt fonts must be distributed with a different name
>> because rebuilding them will cause changes in their font data (at least
>> timestamps, minor float rounding differences). The OFL website [1]
>
> Yes, this is why fonts-adobe-sourcesans3 is rebuilt during packaging, but=
 then=20
> the rebuilt font is discarded and the upstream binary fonts are shipped.
>
> https://salsa.debian.org/fonts-team/fonts-adobe-sourcesans3/-/blob/master/
> debian/README.Source?ref_type=3Dheads

Thank you for sharing this workaround!  So this is sufficient to fulfill
our goal to build fonts on Debian infra (thus proving they're buildable
with DFSG tools), as well as the OFL 1.1 "reserved name" restriction
(because the upstream copy is shipped to users in our package), without
needing to rename the font?

It doesn't insulate our users against a hypothetical supply chain attack
where upstream's copy is modified to contain a payload that
executes-on-rendering, which is unfortunate, but off topic to
debian-legal.

>> explicitly states:
>> > 5.9 Do font rebuilds require a name change? Do I have to change the
>> > name of the font when my packaging workflow includes a full rebuild
>> > from source?
>> >=20
>> > Yes, all rebuilds which change the font data and the smart code are
>> > Modified Versions and the requirements of the OFL apply. [...]
>>=20
>> HOWEVER, if one can ensure that the rebuilt font file will be
>> bit-for-bit identical to the one distributed by its author, then the
>> font in the Debian package may continue using the original/reserved name.

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).

Dave Crossland <[email protected]> writes:

> At the highest conceptual level, I see that the OFL exists to bridge
> between the worlds of type design and libre software, so it is bound to
> "feel non-DFSGish". The tallest nail sticking out is the sales restrictio=
n,
> and https://wiki.debian.org/DFSGLicenses#The_SIL_Open_Font_License says,
>
> The following restriction on distributions, which is part of OFL, has
> been widely accepted by open source projects when it is applied to fonts:
> "1) Neither the Font Software nor any of its individual components, in
> Original or Modified Versions, may be sold by itself."
>
> The RFN nail also sticks out but is rarely discussed, but I think its fair
> to question it - imHo when we talk about 'the' license it is a bit muddli=
ng
> in a way, because there are really two concurrent flavors of the SIL Open
> Font License version 1.1, one with and one without any RFN(s) asserted in
> the copyright notice. (To Charles' point, the mere inclusion of the licen=
se
> term text about this doesn't surface this dual nature.)

Thank you, that's exactly what I am concerned about!  It's like how GDFL
is DFSG so long as it's doesn't include any of the invariant sections,
cover texts, etc.  As a practical concern this makes it impossible to
translate a book cover, which makes all the documentation DFSG-nonfree.
So there are multiple flavours of GDFL licenses.

> So, to Nicholas' original question, I think the answer is that it does FE=
EL
> that way, but it is DFSG compliant CLEARLY when there are no RFNs and
> BARELY when there are; and Soren nicely explained the practicalities of h=
ow
> its just 'over the line'.
>
> I seem to recall that the RFN terms were inspired both by the Bitstream
> Vera license made for GNOME's commission of those fonts (
> https://dejavu-fonts.github.io/License.html) and early versions of the LP=
PL
> (eg https://www.latex-project.org/lppl/lppl-1-0/) and I believe packages
> under both licenses are in 'main' (e.g. ttf-bitstream-vera and fonts-deja=
vu
> - I'm guessing the Vera package uses the same packaging technique as Soren
> used for Adobe Source) and the principle #4 that Sune mentioned is there
> because such terms go back a long way in libre licensing.

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.

Thank you again for taking the time to write this, and it is a privilege
to have received a reply from someone with so much experience in this
field.

Regards,
Nicholas

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

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

iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmnhZDYQHHN0ZW5AZGVi
aWFuLm9yZwAKCRBaiDBHX30QYaOeD/9BBVR/H0E5zmw5hY6ZXR5HX+ekmg/Pmp/q
ZIOBEttPN7hgcmCcWsBwZyVJabcnHKlwNi++Rk3SSUJ9fmxrnQXbxtiYkAcO7+No
IaFo3NwsRK/gxwracAxj/GEOmBRGMiz8C/DnhH08fcCB7csH/Xj8d8FP7vYLJGIA
nh+sNFVCAffLCWb6ybqQtWlk/hPmQO6KofcYeYYm6ILlrTX0+tYXR/qeg7iq//X3
V27A/sXmDEZUMx2d3+DT5Hw9vE0EJkAiB2VnUHCyG34g3DT65TGVh/zxVLm+oMxV
I9JFAHiOadOmi9ORmDAjpphg8JIPbmfowmenzkKnpY/JgJ7mGe3LhakcAPi4VL7Y
SCVKssvrYkgCYLReSvpiXQRRnL4617dl5SjVCH65jmUNnZKWdhJabLBbbAxigZ7B
/g6gn875b1RHj0QBnBvDNBoetaal+T2S3tPJVqQBi1RnfOWC79rC0Bfh2luYWIVn
ZOoS21XtTTfsQJjAIKa4m1UEyD3htyROPRcN+ze0hpn9XuBqfXykebrAakJd+R6n
Ws/Y4tmeAMl6zIKk1v+FQiIhtYdTa0MrZkBExRTA3yFHnJq/LjWR+xonbrqxYCIW
3pXDWZnSG5oxDUYXnL0AeJbeCeJn4Wu4xn386/ir8F5TApofFKSd3DOnD+WxPPTk
/MZIaHJ2Vw==
=o4v9
-----END PGP SIGNATURE-----
--=-=-=--