Re: TrueType/OpenType and anti-circumvention laws
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:
> [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: