Since i took kpdf mantainership I've been quite proud of the changes Enrico, Tobias and me have made to it. But all things have its bad faces, and kpdf development have had 2 of them.
First of them happened when i introduced the possibility of running external programs on a user click on a link if the pdf specified this, that was put down by kde-cvs list readers as they said it was a security problem even if we added a dialog asking the user if he wanted to execute the command or not. IMHO that can be an interesting feature in some cases like when doing a presentation, but i can understand the security implications
The second has happened today when Enrico and me have added the DRM handling to PDF, that means, if the pdf says you can not print it, we don't let you do it, and some similar things. That has caused some controversy on #kde-devel as people said that this removes freedom from the user side and that there is no need for us to implement it. IMHO there is a need for this, i mean we don't go on opening password protected files without asking for a password, if the author put a password on it it was because he had good reasons, so if the author decided he did not like his pdf to be printed we do the same as with the password protected the file. Maybe you want to print the file, but should not blame kpdf for not being able to print it, blame the author for being an asshole.
Well i suppose being the mantainer of a program means you have to be prepared for such discussions.
13 comments:
mja, DRM... I think you should simply ask the user about this. "this document is DRM protected, the author does not want you to print it". or something like that. Imho it's not good to deny users (what I considder) fundamental rights to do what they want... they can read it, make screenshots, why not print? the author should not have distributed the document in the first place, if he only wants people to be able to look at it..
eek. DRM is definitely not good or ethical, imho. The question is, What the hell is wrong with printing something that it's okay to read on-screen? The only reason to disallow that is if you are a control freak or you want to tax everything people do.
But if you insist on doing this, I think the logical way would be to provide it as an additional (non-default) lock-down option in kiosk, rather than an always-on element of kpdf.
The reason for being able to read but not print?
Extremely easy answer:
Copyrights !!!
In the company I work, we work with standards on paper and as pdf files. With standards I mean ISO's etc...
Now, most of those papers or pdf files are copyrighted.
In the past, it happened that some co-workers copied those papers or printed those pdf files and sent them to other companies (to order something for example).
That is of course illegal, as those papers or pdf files are copyrighted.
So, the solution to this is (in case of the pdf files):
Let the people who need to use them, read them, but don't allow them to pring the text.
So, yes, in a "commercial office" situation, it's perhaps required to have these kind of protections in.
And on the otherhand...
it's open source :)
It takes just a couple of seconds to rip out the DRM :)
The problem people have with pdf security is that it isn't proper security. It relies on crippleware.
And crippleware is something that people came to Free software to avoid.
As the maintainer of Cervisia, I would say do what makes you feel better. You're doing such a great job with KPDF that I don't think anyone has the right to make you feel bad about this decision.
I mean, if you see legal problems to distribute an app that circumvents the rights set by the copyright holder, then it's okay. You're the maintainer. If someone doesn't like you decision...well it's open source. They can remove it and distribute it. But then it's their legal problem not yours.
So just ignore those people that "throw stones" because you mentioned the word DRM.
Yes, this feels wrong. When we code our own tools, not relying on contracts and the business world, we don't want to put any limitations in the tools.
We kinda see the same thing with the cover-fetching-option in amaroK; An author mentioned part of the reason for the obfuscated/hashed names saved to disk, was to avoid legal troubles with Amazon (where the covers are fetched from). That, and automatic deleting of covers after a certain amount of time, just feels wrong, and so different from the basic philosophy behind OSS.
If a patch for kpdf starts circulating, I will use it. But most of all I hope you change your mind. Or add a compile-time option (--without-evil-drm) or something to deactivate it :}
To correct some earlier posters; not being able to print has nothing to do with copyright. If you could copy or open the PDF you already broke the copyright the author put on it. Allowing you to also print it then kind of becomes irrelevant..
Like you stole that really nice car from the shops and are now having trouble if you want to drive it since that might be illegal...
To comment on the question itself; the only effect this action will have is that distros will have to keep shipping another pdf reader that can also print (like kghostview) or remove the code again prior to shipping.
IMO this is a situation you can't win.
I do not agree with the example of the ISO standards which are copyrighted. Even when you cannot print it, still you can just transfer the file by e-mail to someone else. Better make sure that your employers are honest, if they are not, nothing will stop them to do what they want, even not DRM.
I'm afraid that's the big problem with DRM, you are punishing the honest and technical limited people. People who really have bad intentions, will always find a work-around...
Copyright law cuts both ways; it also grants rights (copying for academic use, excerpts for reviews, etc.) to the end-user in the form of "fair use." The publisher/author explicitly DOES NOT have the right to prevent fair-use copying! As currently implemented, DRM allows publishers to violate copyright law by taking away rights that are not theirs to take away.
Ignoring DRM allows people to break copyright law, but implementing DRM allows other people to break copyright law. Make it optional. Let us decide.
Perhaps it makes sense to have DRM enabled in some situations (kiosks, corporate), but for the rest of us who work on our own boxes, a pop-up dialog that says "Warning: This document contains DRM, press OK to print/copy/etc. anyway," is more than enough (as commenter #2 suggested).
I'm an adult and I'm responsible for my own actions. If I say PRINT, then it should PRINT. My computer is a tool, not a babysitter, and not a policeman. It does what I tell it. It does not tell me what I'm allowed to do. Forced DRM is just the kind of thing I switched to open-source to avoid.
I can always rip out the DRM code and recompile, but that's a waste of my time. I'd much rather just uncheck a box or uncomment a line in a config file. Or switch to a different application.
I think if you want to reasonably comply then you'd have to deny it if the document says no.
Since KPDF is open source that's about all you can really do as someone will just develop some patches to work around it.
Since YOU are the author it's YOUR choice - all these people saying "DRM sucks, just ignore it" do so from a position of minimal risk whereas you are at risk.
I think if you implement it and someone publishes a patch to remove it you have the best of both worlds - in that case the end user has to make the choice.
I think if you want to reasonably comply then you'd have to deny it if the document says no.
Since KPDF is open source that's about all you can really do as someone will just develop some patches to work around it.
Since YOU are the author it's YOUR choice - all these people saying "DRM sucks, just ignore it" do so from a position of minimal risk whereas you are at risk.
I think if you implement it and someone publishes a patch to remove it you have the best of both worlds - in that case the end user has to make the choice.
DRM:
Developers decide their software functionalities, so if you like your program better including DRM, do so. And do not let anyone blame you for it. What they get is what they can, not what they want.
Do they go to the marketplace and complain because the chicken looks not like what they thought? They may complain, but the answer is: go elsewhere for it, and *if you find it*, get it.
Congratulations for taking a tough decision and doing exactly what you wanted to.
I think you did right. Actually I can think of several cases where I would like my users not to be able to print certain documents (in-house restricted documents on controlled hard+soft).
Now, I can also think of several cases where I would like to be able to ignore some DRM without resorting to silly resources like screen captures, so I think some compile or configuration option would be fine, and wouldn't do much harm if enabled by default, now would it?
Post a Comment