Recent Features
| |||||||||||||
Okular, Debian, and copy restrictionsOkular, Debian, and copy restrictionsPosted Jun 1, 2009 21:37 UTC (Mon) by asdlfiui788b (guest, #58839)Parent article: Okular, Debian, and copy restrictions
Indeed, I believe that compliance to standards while allowing standards to be ignored when they infringe on freedoms are the PERFECT way to go about this issue.
This is not like the Windows NT server/workstation issue where the more expensive software is simply crippled.
This is a situation where an open standard allows for user-removable copy-restrictions to be easily lifted.
I say hoorah for okular's decision to include this functionality by default.
This is a FEATURE, not a "FEATURE".
(Log in to post comments)
up-side Posted Jun 1, 2009 23:34 UTC (Mon) by ncm (subscriber, #165) [Link]
It's a "feature" that leads me to see no reason to install okular knowing that evince is not similarly broken. I notice that DVD players that obey region coding and restrictions on skipping FBI notices are distinctly missing from repositories, for identically the same reason. DVD player boxes that have been identified as easy to modify so as to remove these misfeatures are more appealing to buy, so much so that manufacturers make a point of releasing the necessary details.
It's obvious to me that Debian's rightful course is to flip the default on this program, and further to issue a slap up-side the collective head of those arguing otherwise. It would not be wrong to have it post a marginal icon advising users that the document originator had sought to restrict their use of it.
up-side Posted Jun 2, 2009 1:30 UTC (Tue) by ncm (subscriber, #165) [Link] I have now read the Debian bug report thread, and have learned that the KDE maintainers are unanimous in opposing any sort of fix for this bug.It appears the only choices remaining are: (1) Fork the project, and upload a new package "okular-free"; (2) Initiate a vote to override the package maintainers directly; (3) Initiate a vote to change the project charter so that the repository maintainers are obliged to override the package maintainers' misguided notions. Probably the last is ultimately the right course. I wonder what project these package maintainers think they are working in. Their unanimously bad judgment makes me disinclined to try KDE programs.
up-side Posted Jun 2, 2009 4:57 UTC (Tue) by jospoortvliet (subscriber, #33164) [Link]
I don't get the issue. It is incredibly easy to turn it off - so home
users won't have a problem with it. Meanwhile for certain corporations it is crucial for legal reasons. What's the problem?
up-side Posted Jun 3, 2009 1:37 UTC (Wed) by akumria (subscriber, #7773) [Link] Meanwhile for certain corporations it is crucial for legal reasons.Feel free to provide a link to some evidence with your rhetoric.
up-side Posted Jun 3, 2009 10:07 UTC (Wed) by jospoortvliet (subscriber, #33164) [Link]
Ok, you want a real example so here you go.
I've worked at KPN, the dutch largest telecom provider. The government has mandated the company to kind'a split it's operations off from the sales. The reason is that KPN has both network & services. The goverment has forced it to open up it's network, so other providers can compete with KPN on services.
To prevent any unfair competition, operations is not allowed to tell all it knows to headquarters (for example numbers about marketshare, revenue, growth, prices etc from competitors).
This division is rather dificult to maintain - obviously, as it is still ONE company. But the fines by the OPTA (goverment agency overviewing and checking KPN and other companies in the telecom area) are easily in the millions, so there is quite some pressure.
DRM, among other technologies, is used to keep certain employees from certain information. Even IF you send a doc to someone 'on the wrong side' they won't be able to open it. Or can only see but not print etcetera.
How's that for evidence with my rhetoric. I think a person (which includes a legal person like a company) should have every right to enable and enforce DRM on his/her/their own hardware and software. It's perfectly valid, legal and morally right. Imho.
up-side Posted Jun 3, 2009 11:00 UTC (Wed) by mbanck (subscriber, #9035) [Link]
The point is that the okular problem is not about DRM (even though it is worded as such in the GUI). What we are talking about is advisory locking - the PDF has a bit set and the standard says what should happen; however there is no encryption or anything going on.
You can print the PDF, you can copy the PDF, you just cannot copy&paste if the application honors the bit. So I don't see how this pertains to your KPN example (which might be a valid example for DRM or not, I will not judge on that).
Michael
up-side Posted Jun 3, 2009 12:34 UTC (Wed) by sepreece (subscriber, #19270) [Link]
It means that, if applications implement the standard correctly, an individual can't ACCIDENTALLY copy information from the document or print the document. That gives the company deniability and shifts the liability for violations to the individual who broke the rules.
This is important to many companies. My previous employer often set the no-copy/no-print flags on PDFs that were covered either by internal distribution restrictions (e.g., registered company secrets) or external restrictions (documents received from third parties with restrictions).
The point isn't to make it impossible to copy (they would love to do that, but recognize that it's impossible in an era when every mobile has a camera can take screenshots), but to make it obvious to people when they are breaking the rules.
up-side Posted Jun 4, 2009 1:09 UTC (Thu) by JoeF (subscriber, #4486) [Link]
A non-sequitur.
DRM to prevent opening or reading a file has absolutely nothing to do with this issue.
This issue is about copying only. And preventing copying is, at least for text, simply impossible. If somebody wants to copy the text, the person can always re-type it. Even for diagrams, I can just take a screenshot.
up-side Posted Jun 4, 2009 11:57 UTC (Thu) by jospoortvliet (subscriber, #33164) [Link]
Point is that preventing copying like this works just fine in most cases. Especially if you know (like in the example I gave) that you're not allowed to try to circumvent it. This is like a 'soft DRM' function. Pretty easy to circumvent, but that's no problem. Inconvenient is good enough here.
Anyway, you think the functionality is useless. I think it has it's usecases. You should ask Adobe why they wrote it, and the companies using it why they do that, not me.
up-side Posted Jun 2, 2009 7:33 UTC (Tue) by rvfh (subscriber, #31018) [Link]
Why patch/fork the program when you can just set an option!?!
up-side Posted Jun 4, 2009 0:21 UTC (Thu) by ncm (subscriber, #165) [Link]
Simple: because the package maintainers whose job it is to set the option default correctly have refused to do so.
up-side Posted Jun 2, 2009 6:02 UTC (Tue) by amit (guest, #1274) [Link]
With DVDs, there might be an issue with you not being able to view a DVD you bought on a trip somewhere in your DVD player. You certainly don't want that kind of a behaviour. On the other hand, okular's only forbidding you to copy some text from the pdf when it's marked as such. That's way different from not being able to view the pdf at all. So comparing these two isn't a good analogy.
up-side Posted Jun 2, 2009 16:33 UTC (Tue) by joey (subscriber, #328) [Link]
PDF flags can also prevent PDFs from being printed, which is perhaps more analagous (many PDFs can't be fully used without being printed out).
Evince and others readers used to honor those flags but have been fixed to ignore them. I wonder what Okular does?
|
|||||||||||||