sorry for the typo. In my previous message I meant "anti-feature".
Em ter., 3 de mai. de 2022 às 14:58, Felipe Sanches <j...@members.fsf.org>
escreveu:
> 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.
>
> Em ter., 3 de mai. de 2022 às 13:44, Denis 'GNUtoo' Carikli <
> gnu...@cyberdimension.org> escreveu:
>
>> Hi,
>>
>> On Mon, 2 May 2022 18:36:09 -0500
>> "J.B. Nicholson" <j...@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.
>>
>
