I'm CCing this to Debian-devel because I think it speaks to a larger issue. I just downloaded a PDF, and tried to copy and paste a bit of text from it. I used the selection tool, and Okular offered to speak it to me, but said "Copy forbidden by DRM." pdftotext was able to convert the entire file to text format in an instant. So what I want to know is: why are people putting code into Debian that limits our freedom? Why are people putting such code into KDE? And can we please patch it to stop that?
Indeed, the program is clearly broken by design and needs to be fixed.
Hi, Okular maintainer (upstream, and cooperating in Debian) speaking here. This means the author of the PDF set that users shouldn't (in their will) copy the text from their PDF. You can disable the usage of document permissions by disabling the related option from the preferences. Most probably pdftotext just ignores user permissions. If you feel limited in "your freedom", then go complaining about Adobe and the ISO 32000, aka the standardization of the PDF format, because, in case you don't know, those permissions are features of the PDF format, nothing Okular enforces on its own. And given that it is a feature of a file format just like annotations or sounds, people could use it (for example in corporate environments to avoid documents or parts of them being leaked or so). Option is there, you have also the freedom to use it. The program is just following a file format in that regard AND providing the option to not to, so nothing to be fixed.
+ John Goerzen (Sat, 30 May 2009 19:09:11 -0500): I'll mention it here for the benefit of those reading along: obeying DRM is a configurable runtime option in Okular, so it's just a matter of going to the preferences dialog and unchecking the "Obey DRM" check box. Now I have no idea why it would default to obeying it (or, for that matter, why it would have such an option). I'm CC'ing Pino whom I'm sure will be able to help. (My guess would be that it protects upstream against some shit or whatever, at least by their reckoning, or the person that added it in the first place.) Cheers,
It's not clear to me why this should not be the default, but anyway I think that the interface could be improved by mentioning this in the error dialog.
I checked, and do see that option. But why is it on by default? Or even there at all? False. I'm not running Adobe code on my system. I'm running Okular code on my system. It is entirely within the power of the developers of Okular to decide whether or not to implement this "feature". The cheaper option in terms of developer time would have been to ignore that flag. But we all know it's trivial to work around. pdftotext will do it, and Okular will even do it if you untick that box. It's no real security at all. It's a bit in a file, not some sort of encryption scheme. Why are we honoring it? It should be off by default, then, and the error message should clearly state where to go to turn it off. Pfft. You are causing incompatibility with nothing if you ignore that flag. You are causing incompatibility with things if you honor it. What is the point to honoring it?
tag 531221 wontfix thanks So. you want Okular to by default help you with violating conditions of use of the document you downloaded? Is the next step to make Debian help more active to by default violate the conditions of use of software? If you download files with license issues that you don't like, I'm not sure you should blame it on the software use to view the files. You even have a check box to make it possible for you to violate the conditions of use of the document if you really really want it. Why are you downloading files that limits your freedom? (I don't like DRM, but the right way to fight it is not to ignore the terms, but to get the people providing the content to stop using it) /Sune - who are putting such code into Debian. 1d488450ffb075c1d844b032952f3202faa6ff3dba9d8069f742a300bad92f99 ddtext
Hi, Because Okular by default respect the PDF format. Why it is there? Exactly to give you the freedom to choose, to respect both the ideas of people who just shiver at listening the "DRM" word, and people who make a use of that PDF "feature". You're missing the point. It is not matter of "Adobe code", but "format which was totally in the hand of Adobe until one year ago" (when ISO 32000 was standardized). If tomorrow a corporate person complains that Okular does not respect the PDF format in that sense and that they cannot make use of it because of that, what should I tell them? They would be right. Look, having the "power of developers" does not imply developers should feel like crackers, disabling restrictions just because they can or in the name of some "freedom". Speculating on what how we should had spent our time won't work, sorry. Because it is part of the file format, and some people can make use of it (as told just in the sentence you quoted)? If everything we do cases problems, then I don't see how it is worth changing anything.
Le dimanche 31 mai 2009 à 11:47 +0200, Pino Toscano a écrit : You tell them to enable the “feature” if they want to follow the dumb spec. But you do not bother the 99.99% of people who don’t care about that shit.
I've just read Pino Toscano's answer, and I found it a reasonable choice from an *upstream author point of view*. They want okular to fully implement the spec, to be able to sell it as a feature. Of course, downstream distribution editors (i.e., us) can make different choices, to better implement the philosophy of their distro. Considering that upstream already implemented the mechanism for choosing at runtime, I see an easy way out. - If okular has a system-wide setting "Obey DRM" which acts as a default for user choices, we have already won: the Debian package maintainer is fully in charge of making the choice of what that default should be. - If it has not, I guess adding support for such system-wide setting should be easy enough to do. FWIW If I were the package maintainer, my choice would be not to "Obey DRM" by default, but I'm not. Cheers.
Hello, Package maintainers have already stated their decision (marked the bug wontfix). So there is no need to keep posting to the bug report.
Philipp Kern wrote: That would seem a quite reasonable compromise to me, as a default option. You can still have a checkbox in preferences for complete enforcement if there is somebody that really wants it, and leave it off by default. What do you think, Pino?
Stefano Zacchiroli wrote: Interestingly enough, we patch this stuff out of xpdf already, for presumably the same reasons. evince either never had it, or it is patched out in Debian. I would be happy with us patching okular to simply have a different default on Debian. In any case, I think it was very premature to tag this wontfix. There are many trivial things you could do to improve the situation, in order of preference: 1) Remove the DRM feature entirely 2) Patch the default to have it disabled 3) Patch the prompt to have an "allow/deny" option 4) Patch the text to tell people where to go to turn it off #2 and #4 especially should be exceptionally trivial patches. Why are you tagging it wontfix, Sune?
... I do not see this as premature at all. We, KDE maintainers, have talked about it and we all have decided we are ok as it is now. Then tagged your wishlist report as wonfix accordingly. Ana
Correct, this is what I would like it to do (but I use evince instead, which by default does not bother users with this sillyness). Users can still legally have rights even if they are forbidden by license terms which are effectively void. DRM deprives users of such rights. I will offer an opinion about such a situation when this will actually be proposed. Since I do not believe in following copyright as a religious matter I cannot provide a blanket statement on this issue. It is being argued that it has an inconvenient default and that it is not well documented. Properly documenting the existence of this configuration option in the error dialog would go a long way in solving this issue. Why do you care? I don't like people who think they know better than me what I need.
Ana Guerrero wrote: Could you share your reasoning with us, specifically why you don't like each of the four options I mentioned? (Reproduced below) 1) Remove the DRM feature entirely 2) Patch the default to have it disabled 3) Patch the prompt to have an "allow/deny" option 4) Patch the text to tell people where to go to turn it off
Marco d'Itri wrote: While completely agreeing with you, Marco, I would like to add a couple of points. First off, this is just a flag, and is not really DRM in the sense we normally understand it: some sort of encryption, etc. It is easier to write a PDF viewer that does not honor the flag than to write one that does, since there is no decryption or anything needed. Honoring the flag is an optional "feature", not a prerequisite. The other point is that the flag has nothing to do with the law. I can perfectly well set a flag on a PDF that I generate for myself, and that doesn't make it illegal to copy text out of the PDF I generate for myself. Similarly, just because someone sets the flag on a PDF they give me, doesn't make it illegal to copy text from that PDF. Copyright law, at least in the USA, provides "fair use" rights to copy and distribute small portions of a work. Being able to cut and paste just makes that process slightly faster. And copyright law does not prevent you from copying the entire thing, if you keep the result to yourself. As, of course, cp and the KDE file manager can do (just keeping it in the same format). If it is illegal to do something with the document, that is orthogonal to whether Okular obeys this flag by default, in my mind. Okular is run by the Debian user. As our social contract states, "Our priorities are our users and Free Software." We can, and should, take the high road on this and make sure our users have maximum functionality by default.
Where you offers solutions for a problem, I firstly do not see the problem. Because for me the current default is ok. I consider this is a wishlist bug that does not bother me at all, if it did then i might use my time in patching it and maintaining it in the future, but it is not the case. The only thing I can do here is telling you this is a wontfix and that is what you got. If you get upstream adding a notice here, I will be fine with that too, and debian will carry that. Finally, I only took the time of answering firstly to the bug report because I thought you deserved to know we did not ignore you issue slightly and we packagers talked about it. But I am not going to mail further to this bug report just to say one time and again exaclty the same... Ana
John Goerzen writes: Please don't call it DRM. It's just advisory locking. IMHO not enabling it or omitting it entirely has no legal implications. (I think it should be off by default with an option to turn it on but that's just my irrelevant opinion. I don't use the package.)
It clearly has no legal implication (in jurisdictions having such a clause, like the USA) because it is not an *effective* technological protection measure.
Hi, This will not be done until ISO 32000 changes in that regard. Nope. Which prompt are you speaking about? The text is currently shown as an entry in the popup menu of the page view. Setting a long text in a popup menu is a big no-no in every HIG possible. Because KDE maintainers decided to not change anything, simply. A final remark; John Hasler (and other people) wrote: opinion on it? This for sure doesn't help about the current discussion.
We, the maintainers as a collective, are building a distribution, we are free to have (and express) opinions on whatever we want, if we believe it may make it better, even if we do not use a specific package ourselves. You are, of course, just as free to ignore those you don't deem worthy. Does it make sense?
Pino Toscano writes: I commented on the misuse of the term DRM to describe the advisory locking that is the subject of this discussion. I added the parenthetical to make it clear that I was not thereby endorsing the present arrangement. BTW "Settings->Configure Ocular" offers a "Obey DRM limitations" checkbox. This will confuse many users as the feature seems to be normally referred to as "securing" or "locking". To most people "DRM" has to do with music and videos. I just wanted to clarify the point that this advisory locking is not DRM.
John Hasler wrote: You are quite correct on all of it. I didn't even think to look in that box to start with, because KDE's text referred to DRM, and where do you ever find a DRM disable box?
tags 531221 patch
thanks
Sune Vuorela wrote:
Here's the patch:
jgoerzen@katherina:/tmp/kdegraphics-4.2.2/okular/conf$ diff -d -u
okular.kcfg.orig okular.kcfg
--- okular.kcfg.orig 2009-05-31 13:27:25.310927480 -0500
+++ okular.kcfg 2009-05-31 13:27:32.258926063 -0500
@@ -148,7 +148,7 @@
</group>
<group name="General" >
<entry key="ObeyDRM" type="Bool" >
- <default>true</default>
+ <default>false</default>
</entry>
<entry key="ChooseGenerators" type="Bool" >
<default>false</default>
I don't want to be a thorn in anybody's side here, but are you seriously
telling me that this 1-word patch is too much to maintain? It's in a
default config file, not even in a .cpp or .h source file.
I'm sure that there are i18n templates elsewhere in KDE with similar
language that could be copied. It is rather fallacious of you to assume
I'm making an anglo-centric remark by suggesting a dialog be improved.
Right now it sucks for everyone. It could be made better for everyone.
First off, if upstream ever drops the patch, it is no worse than the
current situation.
Secondly, this is an incredibly trivial patch. It is changing one word
"true" to "false" in a config file. If only all the patches I had to
maintain were so simple!
... Hi John, I hope at least you read this email and get the whole map. Why this bug report is tagged as wontfix and why your patch won't be applied. You have got answers from several people from the KDE team and you seemed to stick only to the aggressive ones (i guess because they annoyed you). okular belongs to the official KDE modules, in Debian those modules are maintained for a variable group of people. No everybody is the same active, and we usually have time with more and less activity. This is good because in theory there is always somebody around, the truth is the team is always lacking of people. We all have very different points of view, and we almost never agree on something, and always have to search for some compromise. This time we all agreed on something after a lot of time, this was nice, thanks for this :D About this option in okular, call it protection bit, DRM or whatever you want, there are 2 options: enabled or disabled. I think this is clear for everybody. And you have to choose one. Personally, I think there are good reasons for having it enabled and for having it disabled, like it happens with any setting in KDE (in some cases it is more complicated because you do not choose between 2 options, more like 10). This is usually just a technical decision, and in KDE you always can change this options, but here it got mixed with something social, people's feeling towards DRM or copy restrictions. They exist and they are there, when we disagree against such laws, we should try to not get them in our respective countries (if you are lucky enough to live in a democratic country). We tend to respect upstream's defaults, this is important for consistency across distros, and we patch only what is needed for fixing big bugs or integration with the Debian system (in the sense of using proper paths for stuff, libraries that are somehow different in debian, changes for archs we support, ...). I think we are one of the distros that is patching less. I am sorry, but I am not going to change a default because you think something should be differently. I also think that having konsole by default with limited scroll is a bad idea and i do not patch away. I do not feel empowered to decide what is better or worse for the users, so I will keep upstream defaults except when there is a good reason for change them, and there is not good reason here. I think this copy restrictions stuff could be improved in okular itself, because software _always_ can be improved, but I do not know how. So if you have a good idea, report it upstream. If the idea is good, okular authors will be glad to improve their software. Debian will carry with that. Finally, today I have seen you quoting in IRC the usual "Our priorities are our users and free software". John, if you are really worried about our users, you should wonder why Debian skip the release 4.2.3 of KDE or if your KDE team needs helps with upcoming 4.3. That will serve all of the users. Ana
Ana Guerrero wrote: Hi Ana, Thanks for the email. I don't actually know who is on the KDE team. But in general, I don't reply to posts with "I agree" because it just creates noise on the list. If there's something I disagree with, then I may post. So I may be agreeing with quite a few KDE team members and never know it. DOH! <grin> I don't see it that way. I think there are a multitude of options: 1) Remove the misfeature entirely (as Debian did with xpdf) 2) Change the default so it's disabled 3) Change the alert mechanism so that the user gets a dialog asking if they want to respect the bit or copy anyway, with a chance to save the preference for all future sessions 4) Change the text that the user sees to make it clear how to disable the thing 5) Others, I'm sure. Some of these are more or less appealing to me; the most appealing to me are at the top of the list. You may sort the list differently. My personal opinion, as you may gather, is that this is not a feature at all, but anyhow... This is an integration bug, in my mind. As far as I know, none of the other PDF readers in Debian respect this bit by default. evince, xpdf, pdftotext, gs, gv, etc. all ignore it. KPDF respected it, but without any information, so I (and apparently several others) switched to evince or xpdf thinking KPDF sucked because it wouldn't let us copy text from documents that others would. This bug isn't here because *I* want it different. I've already unchecked that box on my machines. The bug is here because: 1) The behavior is inconsistent with other PDF readers in Debian; 2) The behavior is inconsistent with the liberating ideals of Free Software; 3) The behavior is inconsistent with our social contract; 4) As it stands, it is completely non-obvious that this behavior can be disabled, or how. To expand on these each, a bit: #1: I already discussed above, but I would add that whatever rationale leads us to remove this misfeature from xpdf should also lead us to remove it from Okular. #2: The behavior restricts, by default, ability to manipulate a document I possess. Freedom to use my computer to the best of its abilities is what Free Software is all about. Restricting my abilities artificially is opposed to that ideal. #3: Our social contract states that our priorities are our users and Free Software. The users of Debian are not served by an intentionally crippled PDF reader. #4: When a program tells you "I can't do something", especially if that "something" contains the word "DRM", it is not at all natural to go thinking that the program is a liar and try to find a configuration option to override it. Again, I don't care about it for me. I know about this now and it won't trip me up again. But if I ran into this problem, many more people will to, and not all of them will know how to solve it easily. Therefore, ideally we should remove this bug. But if we can't do that, we should at least make it easy for our users to do so. I have seen some proposals on IRC along the lines of suggestions #3 or #4 above to do just that. I think this is really a low insult. It feels to me like you are saying that the work I do for Debian doesn't help our users. Frankly, I think it's pretty clear that I do work for Debian that helps our users too; I maintain quite a number of Haskell libraries and applications, and wrote a number of libraries and applications from scratch that are part of the Debian distribution. Just because my passions and skills lie in an area apart from KDE development does not mean that I contribute nothing. I have neither the time nor the expertise to help with KDE packaging; and I suspect you have neither the time nor the expertise to help our understaffed Haskell team. Let us each contribute where we can the best, and spare the insults, please.
Peter Samuelson wrote: Yep, an in fact some people were discussing such a solution on IRC as well. There was some indication it might be accepted.
Hello, You seem to think somebody from KDE team shares your POV. Although Ana's mail made it pretty clear, *nobody* from KDE team agrees with you (and have pretty strong feelings about it). Everybody is fine with current default option and overall situation in a sense that nobody supports locally patching okular to solve your pet bug. You do not have to agree with us but please respect opinion of others who happen to have the last word on this issue.
John Goerzen dijo [Sun, May 31, 2009 at 08:24:17AM -0500]: I have seen arguments on this (very long) thread by Pino and other members of the KDE team regarding the undeniable disadvantage of having to maintain a patch basically forever. I have not seen indication of this mailing reaching the upstream developers for Okular — Yes, Pino is addressed at a @kde.org, but I understand he is addressed as he is listed as the Debian maintainer for Okular. Has this suggestion been pushed upstream? Don't you think we would do a greater service to the KDE users if we convinced the authors instead of just the Debian maintainers? (or at least, if we listened at their arguments as well) Greetings,
Over one year+ and still "Will not fix". Is this Debian?? Alan
Did you read the whole discussion? All opinions were stated and a decision was made. What is there still to be done from your point of view?
I read all of the opinions in the long thread. But I saw little respect or weight given to Debian's very reason for existence. ALL the justifications for "won't fix" are not Debian-ian. Alan
I see it this way: 1) there is a standard, so it's nothing the Okular guys invented. 2) the argument, this limitation endangers our freedon also stands for the GPL. It clearly endangers my freedom to just sell the software modified without opening the sources. I mean ... why do I not have the freedom to do that? Well, I do not want to do it but this discussion reminds me a bit of some GPL haters that also argue it is a restrictive and thus non-free license because of the "limitations". We want all the world to respect our GPL limitations to keep things free. So we should respect other people's right to restrict their works. If you disagree, discuss it with the author who applied that limitation. As a disclaimer: I am neither a KDE packager nor an Okular developer, so it's just another opinion.
Aside from the already mentioned options, anyone who'd like to have a different default on their systems (globally for all users) can simply create a minimal Okular config with that parameter set to false. I.e. creating a file /usr/share/kde4/config/okularrc or /usr/local/share/config/okularrc with the following content [General] ObeyDRM=false Cheers, Kevin
Thank you, this is useful, perhaps better than the other already mentioned options. And I note in passing that I do not find any documentation concerning okularrc, not even a man page. This entire discussion is rather old, going way back, and I am surprised by okular for re-inventing a problem. Alan
/usr/share/kde4/config.kcfg/okular.kcfg Cheers, Kevin
There's a crucial difference. GPL is based in copyright law, so others cannot choose under law whether to respect the copyright. However no law gives the PDF authors the alleged right to restrict its use in this way. There are very specific rights equally recognized by law, like some fair use rights, that DRM restrictions tend to hinder. There's also the very important difference between being legally forbidden from doing something and being technically prevented from doing it (whether doing it would be legal or not - and in most cases printing a PDF where this stupid DRM bit is set would still be legal). So DRM in software means it's intentionally crippled for the users, preventing them from exercising even their very rights under the law. That's not something to support. Not that I consider this a major issue, because there's the configuration option. Sami
A new fax document for you. To view it please open the attachment. Filesize: 133 Kb Processed in: 39 seconds File name: document_0000642889.doc Pages number: 7 Date: Mon, 26 Oct 2015 13:14:52 +0300 Scan quality: 600 DPI From: Karl Byrne Thanks for using Interfax service!
Dear Customer, Courier was unable to deliver the parcel to you. Please, download Delivery Label attached to this email. Yours sincerely, Warren Hanson, Sr. Delivery Agent.
Dear Customer, We could not deliver your item. You can review complete details of your order in the find attached. Regards, Ralph Albert, FedEx Delivery Manager.
Dear Customer, Courier was unable to deliver the parcel to you. Shipment Label is attached to this email. Thank you for choosing FedEx, Daniel Benson, FedEx Delivery Manager.
Dear Customer, We could not deliver your parcel. Delivery Label is attached to this email. Thanks and best regards, Brian Ritchie, Station Agent.
HELLO, Går du igennem økonomiske vanskeligheder, eller du har brug for et presserende lån for at forbedre din forretningsstandard. ... Vi tilbyder også både personlige lån, virksomhedslån, realkreditlån, studielån og payday lån.