Re: [GNU-linux-libre] Code which implements DRM in order to expose DRM-encumbered data is GNU FSDG compliant?

[Denis 'GNUtoo' Carikli]

Hi,

On Mon, 2 May 2022 18:36:09 -0500
"J.B. Nicholson" <jbn@forestfield.org> wrote:
> If free code implements a DRM scheme for the purpose of exposing the
> DRM-encumbered data to be read and copied using processes one can
> easily employ, is that code GNU FSDG-compliant?
[...]
> [1] I have no idea if this exists or could exist.
I've several real world examples.

First there is libdvdcss which manages to break the DVD encryption
relatively fast. As far as I know that doesn't conflict with the FSDG.

Though depending on the countries it might conflict with local laws and
choosing to break them or not is often a decision taken by the
individual distributions. As I understand, in France, software like
libdvdcss is legal[3].

The second example I have is quite recent and not yet understood: In
the Replicant mailing list, we were notified that there was free
software code that may implement some DRM scheme in Replicant 6.0[1][2].

I didn't manage to find the time to look at details yet though, but I
guess that if it doesn't implement extra restrictions It would probably
not really be considered a DRM even if it implements a DRM scheme.

In that case it would probably be more like libdvdcss.

If however it does implement restrictions as I understand we need to
remove these restrictions or this code.

If people have more information about how that code works I would be
very interested.

A third example would be to look how blue ray works with free software.
As I understand it here we need keys to decrypt the disks. As usual,
devices or software is broken, so it is then possible to extract the
keys, and maybe they are published online. However there is a PKI in
place, so newer disks are not encrypted anymore with the keys that have
been made public or that are easy to extract.

Here I would also see no issues with the libraries implementing that as
they don't implement restrictions. And here they enable application to
read or copy blue ray, so it's not an issue as far as I know.

A fourth example is with PDF and software like okular. Okular has a
setting to obey the PDFs DRM ("Obey DRM limitations"). Here it can
easily be disabled since it's a setting. If it could not be disabled
this would clearly constitute DRM so it would not be OK.

I also think that distributions need to not enable it by default,
otherwise some users won't find the settings and they would be at the
mercy of the DRM.

The restrictions of this DRM is probably things like preventing
printing of the PDF.

And in the case of the Linux lockdown mechanism[4] I'm unsure about it
because it implements security schemes dictated by the security
model of UEFI secure boot. What it implement is useful for security but
it also prevent users from doing certain things. Though as I understand
that behavior can (still?) be disabled by users without disabling secure
boot[5]. So as I understand for now it's probably not (yet) considered
as a DRM.

References:
-----------
[1]https://lists.osuosl.org/pipermail/replicant/2022-April/003757.html
[2]https://git.replicant.us/replicant/frameworks_av/tree/drm/mediadrm/plugins/clearkey
[3]https://linuxfr.org/news/le-conseil-detat-revoit-un-decret-de-la-loi-dadvsi-en-faveur-de
[4]https://mjg59.dreamwidth.org/55105.html
[5]As I understand more and more x86 computers are or will be shipped
   with UEFI that can't disable secure boot. So we also need to enable
   users to choose how their computer works even if they can't disable
   secure boot.

Denis.

pgpeKGoG7K82t.pgp
Description: OpenPGP digital signature