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)?
--
Patrick "P. J." McDermott: http://www.pehjota.net/
Lead Developer, ProteanOS: http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/
