TrueType/OpenType and anti-circumvention laws
[I'm Cc:'ing Felix Lechner in case he is interested in this thread.
Please Cc: Felix (unless he says otherwise) and me in replies; I've set
Reply-To: to automate this.]
Hi,
I stumbled upon lintian's truetype-font-prohibits-installable-embedding
and opentype-font-prohibits-installable-embedding warning tags[1][2]
(from checks suggested[3][4] by Paul Wise and written[5] by Felix
Lechner) via an affected package. I've learned how to fix it, and I'm
also drafting a message to the fonts team about why and how to fix it
more broadly there and elsewhere in Debian. But first I have some legal
questions about the solution.
The issue, put simply, is fonts with DRM/TPM bit fields set to prohibit
activities otherwise allowed by their licenses (licenses which in some
cases actually prohibit "impos[ing]" or "apply[ing]" effective TPMs):
specifically[6][7], embedding the fonts in documents, editing documents
in which the fonts are embedded, and extracting embedded fonts from
documents and installing them for further use. Often this is a mistake
by the font designers, because their tools (for example versions of
FontForge older than 2014) restrict fonts by default.
Paul Wise mentioned[8] on the fonts team list in 2021 a couple programs
("embed"[9], a derivative "ttembed"[10], and "ttfpatch"[11]) that unset
the DRM/TPM bits, enabling full use of the fonts. "embed" was written
by a font designer who noticed that his fonts had restrictive embedding
permissions and that a tool he used (which was intended for font users,
not designers) didn't allow lowering the restrictions. "ttfpatch"
was similarly written for font designers, to either prohibit or allow
embedding and other uses, but I don't think the author is himself a
designer.
Although these tools were written (in one case by a font designer) for
use by font designers, they can also be (ab)used by others to unset
DRM/TPM bits without permission.
US law[12] (17 USC section 1201(a)(2)(A)) prohibits software that "is
*primarily designed or produced* for the purpose of circumventing"
effective TPMs (emphasis mine), and the primary purpose of these tools,
as I said, is for font designers to work around deficiencies in their
editing tools. But the primary purpose is also to unset DRM bits.
17 USC section 1201(a)(3) defines circumvention as "to descramble a
scrambled work, to decrypt an encrypted work, or otherwise to avoid,
bypass, remove, deactivate, or impair a technological measure ...".
And a TPM is defined as effective if it "requires the application of
information, or a process or a treatment, with the authority of the
copyright owner, to gain access to the work". Unlike DVD CSS for
example, there are no descrambling keys required (only a bit field that
non-compliant PDF viewers/editors or font libraries might not even
check). So I'm not sure if, under US law at least, anti-circumvention
law even applies to fonts.
Is anyone here familiar with how other jurisdictions (e.g. under
Directive 2001/29/EC) define "circumvention", "technological measures",
"effective", and "copy control mechanism", and whether simple bit fields
count? Is there any relevant case law?
I therefore wonder: should these tools be treated like regular
development tools (e.g. fontforge or dh_fixperms) or more like
circumvention tools (e.g. libdvdcss)? Specifically:
* Would it be legal or appropriate to package such a tool in Debian,
because it would help font designers and Debian package maintainers
find and fix free fonts with DRM, including possibly during package
builds (like dh_fixperms for font DRM)?
* Similarly, would it be legal or appropriate for packages containing
restricted fonts to include and build from source (but not install
and distribute binaries of) such a tool to fix permissions during
the build?
* Should Debian maintainers even be fixing the fonts themselves at all
(obviously, in general, fixes should be sent upstream when possible)
given that doing so could circumvent DRM/TPMs? Should we not go
near this issue and just tell upstream font designers to fix their
own fonts, instead of us submitting fixed fonts upstream? What if
fonts are no longer actively developed and upstream is unresponsive?
Or are the licenses sufficient permission for us to fix the fonts?
17 USC section 1201(a)(3)(A) for example defines to "circumvent a
technological measure" as "to avoid, bypass, remove, deactivate,
or impair a technological measure, *without the authority of the
copyright owner*" (emphasis mine). Are licenses like Apache-2.0,
CC-BY(-SA)-3.0, Expat, GPL-2.0, and OFL-1.1 considered to imply such
authority, or does a license have to more explicitly waive any legal
power to forbid circumvention of TPMs like CC-BY(-SA)-4.0 (section
2(a)(4)) and GPL-3.0 (section 3) do? Of course, what matters most
is font copyright holders' (potentially various and contradictory)
interpretations of the license terms they use, not the intentions of
the licenses' drafters.
(I know there's probably no single answer to these "would it be legal"
questions, since Debian has to be distributable under a variety of
jurisdictions worldwide, so I'm asking about all such anti-circumvention
laws. And to be clear, I think Paul on the fonts list in 2021 was just
citing the existence of the tools as evidence that programs somewhere
must be enforcing embedding permissions for people to care enough to
develop and use such tools, rather than suggesting that Debian use or
distribute the tools to fix fonts. But I could be wrong.)
[1]: https://udd.debian.org/lintian-tag.cgi?tag=truetype-font-prohibits-installable-embedding
[2]: https://udd.debian.org/lintian-tag.cgi?tag=opentype-font-prohibits-installable-embedding
[3]: https://alioth-lists.debian.net/pipermail/pkg-fonts-devel/2011-July/007004.html
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635068
[5]: https://lists.debian.org/debian-fonts/2019/12/msg00046.html
[6]: https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6.html
[7]: https://learn.microsoft.com/en-us/typography/opentype/spec/os2#fstype
[8]: https://lists.debian.org/debian-fonts/2021/10/msg00017.html
[9]: http://carnage-melon.tom7.org/embed/
[10]: https://github.com/hisdeedsaredust/ttembed
[11]: http://www.derwok.de/downloads/ttfpatch/
[12]: https://www.copyright.gov/title17/92chap12.html
--
Patrick "P. J." McDermott: http://www.pehjota.net/
Lead Developer, ProteanOS: http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/
Reply to: