| |||||||||||||
|
| |||||||||||||
up-sideup-sidePosted Jun 2, 2009 1:30 UTC (Tue) by ncm (subscriber, #165)In reply to: up-side by ncm Parent article: Okular, Debian, and copy restrictions 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.
(Log in to post comments)
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 (guest, #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.
|
|
||||||||||||