[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: TrueType/OpenType and anti-circumvention laws



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/


Reply to: