sorry for the typo. In my previous message I meant "anti-feature".
I'd like to mention that I am extremely annoyed by Telegram-desktop's implementation of an anti-featured which forbids the user to copy/paste or forward text (and also forbids saving images or other media included in the messages) from certain groups where the admin has enabled the restriction. It may not be exactly DRM because it does not seem to involve cryptography and also is not directly enforcing copyrights, but it is my computer refusing to obey my orders and instead subjugating me to the interests of a third party.
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.