TrueType/OpenType and anti-circumvention laws

[P. J. McDermott]

[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/

[P. J. McDermott]

Ping? Any thoughts on whether a font DRM modification tool would be
legal to distribute and use in Debian given that the DRM is a simple bit
field rather than an "effective" TPM such as scrambling or encryption?

FontForge of course can also do this, though it's not "primarily
designed or produced" to do so. So this seems to me like a reasonable
use case that can be done with software already in Debian.

[P. J. McDermott]

[Resending to the list, as it apparently didn't go through earlier.]

Ping? Any thoughts on whether a font DRM modification tool would be
legal to distribute and use in Debian given that the DRM is a simple bit
field rather than an "effective" TPM such as scrambling or encryption?

FontForge of course can also do this, though it's not "primarily
designed or produced" to do so. So this seems to me like a reasonable
use case that can be done with software already in Debian.

On 2024-01-15 at 06:05, P. J. McDermott wrote:

[Walter Landry]

Paul Wise <pa...@debian.org> writes:

> On Fri, 2024-02-02 at 20:16 -0500, P. J. McDermott wrote:
>> Ping?  Any thoughts on whether a font DRM modification tool would be
>> legal to distribute and use in Debian given that the DRM is a simple bit
>> field rather than an "effective" TPM such as scrambling or encryption?
>

> Probably best to consult a lawyer there, but ISTR even trivial things
> are supposed to count under the DMCA.

This feels similar to pdf viewers that do not honor DRM bits like 'do
not print', which Debian distributes. Here is an old email exchange.

https://lists.debian.org/debian-legal/2005/03/msg00308.html

and a bug ticket that implemented DRM stripping.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298584

Running

pdftohtml --help

on my bookworm system includes the option

-nodrm : override document DRM settings

Cheers,
Walter Landry

[P. J. McDermott]

On 2024-02-02 at 22:18, Walter Landry wrote:
> This feels similar to pdf viewers that do not honor DRM bits like 'do
> not print', which Debian distributes. Here is an old email exchange.
>
> https://lists.debian.org/debian-legal/2005/03/msg00308.html
>
> and a bug ticket that implemented DRM stripping.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298584
>
> Running
>
> pdftohtml --help
>
> on my bookworm system includes the option
>
> -nodrm : override document DRM settings

Great example, thanks.

PDF 1.5[1] (the earliest version with this DRM, unchanged through
ISO 32000-2:2020) Table 3.20 lists user access permission bits.
Poppler represents them as follows:

//------------------------------------------------------------------------
// Permission bits
// Note that the PDF spec uses 1 base (eg bit 3 is 1<<2)
//------------------------------------------------------------------------

#define permPrint (1 << 2) // bit 3
#define permChange (1 << 3) // bit 4
#define permCopy (1 << 4) // bit 5
#define permNotes (1 << 5) // bit 6
#define permFillForm (1 << 8) // bit 9
#define permAccessibility (1 << 9) // bit 10
#define permAssemble (1 << 10) // bit 11
#define permHighResPrint (1 << 11) // bit 12
#define defPermFlags 0xfffc

It checks the bit field:

bool XRef::okToCopy(bool ignoreOwnerPW) const
{
return (!ignoreOwnerPW && ownerPasswordOk) || (permFlags & permCopy);
}

And pdftohtml (in Poppler) checks and optionally ignores it:

// check for copy permission
if (!doc->okToCopy()) {
if (!noDrm) {
error(errNotAllowed, -1, "Copying of text from this document is not allowed.");
goto error;
}
fprintf(stderr, "Document has copy-protection bit set.\n");
}

It's indeed very similar, except that pdftohtml doesn't change the
permission bit in the document like these font tools do. But this
is maybe a distinction without a difference, as I note in the last
paragraph below.

[1]: https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/pdfreference1.5_v6.pdf

On 2024-02-03 at 13:42, Paul Wise wrote:
> On Fri, 2024-02-02 at 20:16 -0500, P. J. McDermott wrote:
>

> > [Resending to the list, as it apparently didn't go through earlier.]
>

> It did go through.

Oops, you're right. Sorry for the noise.

> > Ping?  Any thoughts on whether a font DRM modification tool would be
> > legal to distribute and use in Debian given that the DRM is a simple bit
> > field rather than an "effective" TPM such as scrambling or encryption?
>
> Probably best to consult a lawyer there, but ISTR even trivial things
> are supposed to count under the DMCA.

I guess there's another issue here. 17 USC subsection 1201(a) (which I
quoted previously) covers "circumventing a technological measure that
effectively controls access to a work". Subsection 1201(b) covers
"circumventing protection afforded by a technological measure that
effectively protects a right of a copyright owner".

FontForge circumvents such "protection afforded" by a TPM under
subsection 1201(b); should it be removed from Debian? Maybe it's OK
because it's not "primarily designed or produced" for that purpose?

As I said, I think tools like embed/ttembed and ttfpatch are fine under
subsection 1201(a) since they don't circumvent (e.g. by descrambling or
decryption) a TPM that "effectively controls access", but maybe 1201(b)
presents an issue with "circumventing protection afforded by" a TPM that
"effectively protects a right".

To "circumvent protection afforded by a technological measure" is
defined as "avoiding, bypassing, removing, deactivating, or otherwise
impairing" it. These font tools I guess remove or deactivate a TPM,
and pdftohtml I guess avoids or bypasses a TPM. What makes pdftohtml
acceptable in Debian? Is it only the "primarily designed or produced"
language, and if so, how far does that extend (does it cover an intent
that a tool be used by font designers or others licensed to fix fonts)?

[P. J. McDermott]

On 2024-02-05 at 10:34, Paul Wise wrote:

> On Mon, 2024-01-15 at 06:05 -0500, P. J. McDermott wrote:
>
> > 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.
>

> PS: for thread completeness, I note the embed author recieved DMCA
> legal threats, but did not remove the tool from their website:
>
> http://carnage-melon.tom7.org/embed/dmca.html

Thanks, that's a very interesting read.

I'm surprised to see that Paul F. Stack alleged that embed violates
subsection 1201(a) (circumvention by descrambling, decrypting, etc.
of a TPM that "effectively controls access". Tom Murphy 7 clearly
explains why that doesn't apply per the definitions in 1201(a)(3): a bit
field doesn't "[require] the application of information" etc. (e.g. a
descrambling or decryption key). Instead, it actually requires other
programs (not embed) to proactively check and obey the bit field. So
even if embed didn't exist, unauthorized exercise of a right (1201(b),
not unauthorized access to a work under 1201(a)) could be performed
simply because another program lacks the extra code to check the bit
field).

Only subsection 1201(b) (circumvention of not a TPM, but of "protection
afforded" by a TPM that "limits the exercise of a right") could apply
here. However, 1201(b) doesn't prohibit the act of circumvention itself
like 1201(a)(1) does. It only prohibits trafficking in technology etc.
that circumvents, like 1201(a)(2) does.

Stack seemed to pretend (or somehow believe) that 1201(a) applies,
specifically to rely on the prohibition of the act of circumvention (not
focusing on the trafficking in embed), in an attempt to scare Murphy
into believing he's vicariously liable for contributory infringement in
every (non-specified) act of circumvention by embed users (with a threat
that the statutory damages of each act add up). It's not until his last
"memorandum" in which Stack ever mentioned 1201(b) at all, let alone
alleging any violation of it. Further, Stack oddly quoted from 1201(b)
and at the end of that same paragraph made a remark about the DMCA not
affecting contributory infringement, as if to suggest (flat out wrongly)
that Murphy could be liable for acts of circumvention under 1201(b)
(which as I noted does not actually prohibit such circumvention). Stack
was careful to not explicitly say that Murphy is liable for contributory
infringement by embed users under 1201(b) (there cannot possibly be any
such infringement by users in the first place) but apparently wanted
Murphy to believe that he could be liable. That is either a bad faith
scare tactic or ignorance of the law (which is not good for a lawyer).
Either way, this seems like an unserious legal threat, which if brought
in court, any decent copyright defense attorney could probably have
dismissed, perhaps even summarily and/or with prejudice.

The DeCSS case cited by Stack could have been relevant here, except
that it alleged misappropriation of the CSS descrambling key as a trade
secret, and DVD CCA never alleged violation of the DMCA (1201(a), which
in that case would have been relevant).

Back to the matter at hand, subsection 1201(a) doesn't apply because no
information (e.g. a descrambling or decryption key) is needed to access
a font. Subsection 1201(b) could apply, making distribution of a
program like embed or ttembed possibly illegal. But 1201(b) (unlike
1201(a)) doesn't prohibit the use of such a program. Does anyone know
whether other jurisdictions have laws stricter than the US DMCA, i.e.
laws that prohibit the use of programs like embed and ttembed (the
act of circumventing "protection afforded" by a TPM that "limits the
exercise of a right")?

Has there ever been a legal threat (let alone a court case) alleging
that a program like embed or ttembed violates subsection 1201(b) (or
an international equivalent thereof)? Perhaps such a threat isn't
financially worthwhile, because statutory civil damages (1203(c)(3)) are
at most $2,500 per device/product/etc. (i.e. one program), and there can
be no contributory infringement that multiplies such damages for each
act of circumvention by users. And actual damages (which can be sought
instead of, not in addition to, statutory damages) would be hard if not
impossible to prove.