I can suppose two possible and not mutually exclusive explanations of the situation:
It is a bug in LO. LO fails to comply PDF specification.
As soon as a PDF can be read by a PDF viewer, the document text is available to the viewer. Nothing enforces that viewer to read/interpret/respect do not copy flag. It is up to the viewer to allow copying text to clipboard or not.
That version is literally 3 years old,now whether that makes a difference in your situation I doubt it but maybe trying a newer version for comparison's sake might be worth a shot.
Thank you, Eugene. It never occurred to me that such files had so little internal "protection".
Would that behaviour change if encryption was applied and the need for password to open would enforce the protection rules against copying/printing?
I will need to file a bug report with LibreOffice to ensure the generated document enforces the properties that it is directed to embed. When that is done, I will make note of it here.
Thank you, Norm. Since that capability was part of the Atril viewer for almost a decade, I never imagined that this "security loophole" would have been overlooked.
I've found the following Bug Report against OpenOffice and its "resolution" (NOTOURBUG) seem to confirm @ugnvs 's guess: it seems that it's up to the PDF readers / viewers to respect / honor the "do not copy" protection:
many PDF readers do not implement copy permission because it's a silly feature to begin with - you can just use a PDF reader that doesn't implement copy permissions to work around the copy permissions... AFAIK no open source PDF reader - Evince, Okular etc. implements this feature. if it works with Adobe Acrobat, then we can assume that the passwords were written correctly into the PDF file by LibreOffice, and there is no bug. setting to NEEDINFO; please set this bug to NEW if you can reproduce this problem with Adobe Acrobat, or resolve it as NOTOURBUG if nobody can do that.
As for initial report, it's is NotABug. Because LO exports properly setting restrictions, can be seen with other PDF readers: Adobe, X-change, Master PDF. I don't have Acrobat but I see that it's similar for some other programs that can make PDF restricted content. Just some don't obey that, here is reported Okular, I confirm for Xreader. This bug should be reported to them. As for comment 2, that's a different issue, which is actually not a bug, because PDF security is not to be trusted to.
Maybe what you say about where the industry has established as the "function point" for that feature is true.
HOWEVER, given the functional purpose being claimed by the authoring software, it is my personal view, and I believe that of any well-reasoned person, that the only way to guarantee the claimed functionality is at the time of document creation, and therefore it should be happening in LibreOffice.
This new bug report presents the problem's potential solution from my standpoint, with the hope that the Development Team is better positioned to leverage other like minded developers of the Reader Apps to pressure LibreOffice to act as a visionary and offer an alternative format, in parallel with the deemed industry standard, which is in fact more integrally secure.
