Okular, Debian, and copy restrictions
| Please consider subscribing to LWN Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net. |
One of the biggest advantages of free software is that it is usually written with the needs of its users in mind. Proprietary software, instead, has more of a tendency to reflect the interests of its owners. Thus, free applications do not normally implement "features" which allow their users to do less. One might think that the consensus against "antifeatures" in free software is nearly universal, but, as the case of the okular PDF reader in Debian shows, there are still exceptions.
The PDF file format includes a number of protection flags which specify whether the reader is allowed to print the file, make changes, or to copy out excerpts. There is nothing in the format which actively prevents such activities; these flags are simply instructions which any application operating on PDF files is expected to observe. If the "no copy" flag is set, cutting and pasting text from the file should - by the standard - be disabled in any reader application. Developers of free applications have, as a general rule, never quite gotten around to implementing this kind of restriction - even though the low-level poppler PDF-processing library makes such support possible. Applications which do implement this "feature" tend to disable it by default.
![[Okular]](https://static.lwn.net/images/ns/okular-drm-sm.png)
This is not the case with Okular, though. An attempt to select text from a
suitably-marked PDF file yields a rather confusing dialog which reads "copy
forbidden by DRM" (see the image to the right). Amusingly, the application
will still allow the selected region to be saved as an image file, but
sending the text to the clipboard is not allowed. There is a configuration
option which disables this behavior, but the default setting is to enforce
the copy restriction flag.
John Goerzen encountered this behavior in Debian's Okular package; suffice to say he was not pleased. He filed a bug and asked:
And can we please patch it to stop that?
One of the important roles played by distributors is to serve as an intermediary between upstream projects and their users. If a development project does something which is not in the interests of its users, distributors have the opportunity, thanks to free licensing, to fix the problem. A look at a typical distributor's source packages will reveal that a number of applications have been patched in ways which change their behavior and generally make them fit in better. This final bit of finish is part of the value that distributors add.
Given that it's hard to find users who are asking for copy restriction features, one might think that this would be an ideal place for the Debian developers in charge of Okular to provide a more friendly default. But they do not want to do that. Okular developer Pino Toscano justifies the copy-restriction antifeature by saying that it's part of the PDF format specification. Since Okular is meant to follow the standard, it must do so in this case as well. Beyond that, Pino says:
Additionally, Debian KDE maintainer Sune Vuorela claims that the overhead of maintaining a patch to Okular would exceed the value gained - though it has been pointed out that the patch is trivial - and that the real problem is that people are downloading PDF files with restrictions in the first place. He states that Okular should not help users to "violate the conditions of use" associated with the file, but does not say why, if that is a concern, the ability to ignore copy restrictions is not patched out altogether.
Beyond that, others have raised concerns that failure to enforce copy restrictions could lead to legal problems in some jurisdictions. It is not clear which jurisdictions those would be, though. The copying of excerpts is allowed by fair use rules almost everywhere. Even the DMCA should not come into play here; the "do not copy" flag is simply a piece of advice found in the file which does not constitute an "effective technological measure" in any way. There has been a distinct shortage of legal problems (or even threats) associated with any of the other PDF readers which fail to implement this particular behavior. And, if such threats did exist, the existence of an option to ignore copy restrictions would be problematic regardless of its default value.
The evince PDF reader ran into this issue back in 2005. It is now rare to find a distributor shipping a version of evince which implements copy restrictions. Xpdf implements copy restrictions unconditionally, but Debian patched that code out in 2002, and that patch has spread to other distributors as well. In general, as one would expect, free PDF readers tend not to implement this behavior. Okular is about the only exception that your editor can find; it's interesting to note that the version of Okular shipped with Fedora Rawhide also implements copy restrictions by default. Perhaps this behavior is result of the relative newness of this application; as it accumulates more users, the pressure for more user-friendly behavior is likely to grow.
As that pressure mounts, Okular's developers and packagers may find it hard
to justify keeping copy restrictions in place. Linux, at all levels, has
felt free to ignore standards when following them makes no sense. And one
could argue that the copy-restriction flag - which interferes with fair-use
rights while doing nothing to prevent copying of the file or its contents -
makes little sense indeed. This is not a feature which adds value for
Linux users; such features still tend to disappear over time.
(Log in to post comments)
Okular, Debian, and copy restrictions
Posted Jun 1, 2009 21:09 UTC (Mon) by danielpf (guest, #4723) [Link]
Okular, Debian, and copy restrictions
Posted Jun 1, 2009 21:36 UTC (Mon) by drag (guest, #31333) [Link]
I would not have a problem with programs that make people aware of licensing or other use issues with a file.
Like say you get a mp3 song that is distributed under a no-derivatives license or something like that. If you try to load the song up into a sound editing program I would not have issue with that sound editing program to notify the user that the author of that file has certain wishes on how the content of the file should be handled.
Same thing with P2P applications and stuff like that.
I wouldn't go out my way to impliment notifications and volentary restrictions, but it may still be useful. It would be a nice feature if applications tried to help users from accidently breaking laws or agreements.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 4:56 UTC (Tue) by jospoortvliet (guest, #33164) [Link]
companies it might even be mandatory. I know a company which would
appreciate the possibility of enforcing this company-wide for legal
reasons.
It is easy to turn of as home users (it's in the preferences: Obey DRM
limitations, has been there for 4 years) and provides value to corporate
customers. I don't see the issue...
I also don't understand why mr Corbet does not mention how easy it is to
turn it off.
Okular, Debian, and copy restrictions
Posted Jun 3, 2009 16:35 UTC (Wed) by jospoortvliet (guest, #33164) [Link]
Okular, Debian, and copy restrictions
Posted Jul 1, 2009 3:10 UTC (Wed) by ggw (guest, #59386) [Link]
third paragraph.
"There is a configuration option which disables this behavior, but the
default setting is to enforce the copy restriction flag."
Okular, Debian, and copy restrictions
Posted Jun 5, 2009 7:44 UTC (Fri) by liljencrantz (guest, #28458) [Link]
Okular, Debian, and copy restrictions
Posted Jun 1, 2009 21:38 UTC (Mon) by ana (guest, #41598) [Link]
Anyway:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531221#143
Okular, Debian, and copy restrictions
Posted Jun 1, 2009 22:07 UTC (Mon) by johnflux (guest, #58833) [Link]
Okular, Debian, and copy restrictions
Posted Jun 1, 2009 22:35 UTC (Mon) by elanthis (guest, #6227) [Link]
(not saying it isn't simple in Okular as I haven't used it)
Okular, Debian, and copy restrictions
Posted Jun 1, 2009 22:46 UTC (Mon) by sune (subscriber, #40196) [Link]
That's four clicks. The checkbox is checked by default.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 7:31 UTC (Tue) by rvfh (guest, #31018) [Link]
In ~/.kde/share/config/okularpartrc: ObeyDRM=false
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 14:00 UTC (Tue) by nix (subscriber, #2304) [Link]
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 15:01 UTC (Tue) by rvfh (guest, #31018) [Link]
I think the article can be read in two ways: I read it first as please Okular guys remove that feature from the code, and the second time (after reading your comment) realised that it could (should?) be read as please Okular/KDE/Debian guys set the default option to not enforce the restriction, which they don't want to do.
Okular, Debian, and copy restrictions
Posted Jun 4, 2009 1:00 UTC (Thu) by JoeF (guest, #4486) [Link]
Useless denigrating comments
Posted Jun 4, 2009 7:09 UTC (Thu) by rvfh (guest, #31018) [Link]
Thanks for sharing this invaluable experience, your comment was most useful.
Also, I do hope the 'F' in TFA meant 'featured', because over here at LWN people usually tend to be polite to each other.
But I do realise that, although this did not use to be too much the case on LWN, people like to tell others off and punish them, rather than trying to understand them. I can see that on the road to work every day.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 7:20 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 15:18 UTC (Tue) by engla (subscriber, #47454) [Link]
1. Most users would realise there was an option
2. Most users would understand what "DRM" was and what obeying it meant
3. There wasn't fair use and other perfectly valid reasons to not let technology but policy set the limits.
Okular, Debian, and copy restrictions
Posted Jun 1, 2009 21:37 UTC (Mon) by asdlfiui788b (guest, #58839) [Link]
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".
up-side
Posted Jun 1, 2009 23:34 UTC (Mon) by ncm (guest, #165) [Link]
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 (guest, #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 (guest, #33164) [Link]
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 (guest, #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 (guest, #33164) [Link]
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 (guest, #9035) [Link]
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 (guest, #19270) [Link]
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]
DRM to prevent opening or reading a file has absolutely nothing to do with this issue.
You'd have to encrypt the file to prevent unauthorized people from reading the contents.
That's the only way to enforce DRM.
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.
All this flag does is making things more inconvenient.
up-side
Posted Jun 4, 2009 11:57 UTC (Thu) by jospoortvliet (guest, #33164) [Link]
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 (guest, #31018) [Link]
up-side
Posted Jun 4, 2009 0:21 UTC (Thu) by ncm (guest, #165) [Link]
up-side
Posted Jun 2, 2009 6:02 UTC (Tue) by amit (subscriber, #1274) [Link]
up-side
Posted Jun 2, 2009 16:33 UTC (Tue) by joey (guest, #328) [Link]
Evince and others readers used to honor those flags but have been fixed to ignore them. I wonder what Okular does?
Okular, Debian, and copy restrictions
Posted Jun 1, 2009 21:39 UTC (Mon) by atai (subscriber, #10977) [Link]
Is this true? Free Software is great, but we also heard that free software reflects the itch of the authors, rather than some other users?
Okular, Debian, and copy restrictions
Posted Jun 1, 2009 22:03 UTC (Mon) by ikm (subscriber, #493) [Link]
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 7:43 UTC (Tue) by rvfh (guest, #31018) [Link]
Okular, Debian, and copy restrictions
Posted Jun 1, 2009 21:40 UTC (Mon) by madcoder (guest, #30027) [Link]
As that pressure mounts, Okular's developers and packagers may find it hard to justify keeping copy restrictions in place. Linux, at all levels, has felt free to ignore standards when following them makes no sense. And one could argue that the copy-restriction flag - which interferes with fair-use rights while doing nothing to prevent copying of the file or its contents - makes little sense indeed. This is not a feature which adds value for Linux users; such features still tend to disappear over time.FWIW okular is the successor of kpdf that had exactly the same UI, understand that you can (in the configuration dialog) chose to disregard the so called DRM restrictions, but this configuration is disabled by default. John just happened to notice it recently that is all. Unlike poppler or evince did, the option to disregard DRMs is left to the user, but is disabled by default, which is not worth the fuss it generated.
Okular, Debian, and copy restrictions
Posted Jun 1, 2009 22:14 UTC (Mon) by pr1268 (subscriber, #24648) [Link]
FWIW okular is the successor of kpdf that had exactly the same UI, understand that you can (in the configuration dialog) chose to disregard the so called DRM restrictions, but this configuration is disabled by default.
And I've noticed that checkbox in KPDF for several years now. Disabling (unchecking) the "Obey DRM limitations" option is just a few clicks away.
John just happened to notice it recently that is all.
I believe it's Jon, not John. :)
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 13:53 UTC (Tue) by utoddl (guest, #1232) [Link]
I believe it's Jon, not John. :)
He has an "h", but you are not licensed to view it in the public forums.
Okular, Debian, and copy restrictions
Posted Jun 4, 2009 7:58 UTC (Thu) by madcoder (guest, #30027) [Link]
Okular is doing the right thing
Posted Jun 1, 2009 21:48 UTC (Mon) by MattPerry (guest, #46341) [Link]
Okular is doing the right thing
Posted Jun 1, 2009 22:20 UTC (Mon) by tzafrir (subscriber, #11501) [Link]
The "DRM" bit is not directly related to any usage and/or distribution license of the document.
(I personally normally use evince to view PDF files)
Okular is doing the right thing
Posted Jun 2, 2009 1:01 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
I wonder if somebody actually did something of that sort...
Okular is doing the right thing
Posted Jun 1, 2009 23:32 UTC (Mon) by jspaleta (subscriber, #50639) [Link]
Is it okay for a tool to attempt to enforce usage restrictions? There's no algorithmic way to determine if a particular intended usage is protected under the fair use doctrine or not. The flags on the content can't take fair use into account at all. If strictly enforced they are guaranteed to restrict reasonable fair use.
I can't recall any serious discussion among FLOSS licensing supporters about toolizing enforcement of the licensing terms in such a way that it would also restrict fair use of the code or executable carrying the FLOSS license. You have to remember that FLOSS licensing only grants you rights that you do not have by default under copyright law without a license.
It's not strictly the wishes of the original author that is the question. The question is the wishes of the original author insofar as those wishes are not more restrictive than legal doctrine allows. Content usage flags can't accurately encode fair use and any such flagging will be overly restrictive. There's no a flag can no if I'm cutting and pasting a section for scholarly research and thus protected by fair use.
But that isn't to say that the flags should be silently ignored. I think there's real value in making people explicitly aware when there is a use restriction in place, so they can decide for themselves whether their use warrants fair use or criminal activity. The biggest problem with our content consumption culture is that we haven't made any allowances for content licensing in the interfaces we are using to select and use digital content. It all gets lumped together and users of the content have no way to make informed choices based on licensing restrictions. Being able to present the flagged use restrictions as advisory information in the pdf user interface would be more inline with a model of informed decision making.
-jef
Okular is doing the right thing
Posted Jun 2, 2009 5:59 UTC (Tue) by MattPerry (guest, #46341) [Link]
> restrictions and the enforcement thereof.
I agree that there is a subtle point. You are the one who is missing it.
> Is it okay for a tool to attempt to enforce usage restrictions?
Yes, because the flags for said usage restrictions are part of the spec and the program is implementing the spec as designed. The programmers should be commended for such thoroughness.
> There's no algorithmic way to determine if a particular intended usage is
> protected under the fair use doctrine or not.
Nor should there be. Fair use is a legal concept. It protects the user of the content from legal liability. It doesn't mean that you have a right to access that content in the most convenient manner possible.
Is Okular doing the right thing?
Posted Jun 2, 2009 8:04 UTC (Tue) by PO8 (guest, #41661) [Link]
"Implementing the spec as designed" is not an excuse for putative bad behavior here. If some portion of a spec called for program behavior that was racist or sexist, or would intentionally damage the user's software, computer or person, you surely would be willing to disregard that portion of the spec?Specifications capture intent; implementors with different intent must choose whether to respect a specification. Disregarding a spec is not to be done lightly—the willingness to faithfully implement specs is a form of social contract that makes the spec model work. But the broader social contract sometimes takes precedence.
In this case, the decision to be made is whether a spec clause that will to some degree restrict the fair use activities of less-knowledgeable users is a serious enough problem to warrant deliberately violating the specification. I can see the argument for both sides here, but certainly the issue deserves more serious consideration than "one must always blindly follow specifications."
Is Okular doing the right thing?
Posted Jun 2, 2009 14:16 UTC (Tue) by MattPerry (guest, #46341) [Link]
> behavior here.
There's nothing bad about the behavior. Please elaborate if you disagree.
> If some portion of a spec called for program behavior that
> was racist or sexist, or would intentionally damage the user's software,
> computer or person, you surely would be willing to disregard that portion
> of the spec?
You are comparing apples to oranges. There's is nothing malicious or harmful by setting a flag that says "I don't want this to be able to be printed, or text to be copyable."
There are legitimate reasons for restricting the copying and printing of documents. I work for a medical device manufacturer and we restrict the copying of text and printing of PDFs of our standard operating procedures. These are not restricted to prevent fair use by our employees but to make sure that there are not printed copies of older documents that are filed away and used by people for procedures. Such use of old documents can and have caused much expensive trouble with the FDA in the past. If an employee needs an older version to print, or needs text from an older version of a document, they can contact the document owner to get a copy of the content they require.
In this case, restricting the copying and printing enforces policies in our company that is intended to minimize costly mistakes.
> In this case, the decision to be made is whether a spec clause that will
> to some degree restrict the fair use activities of less-knowledgeable
> users is a serious enough problem to warrant deliberately violating the
> specification.
No fair use rights are being affected. You can still take a screenshot of the content. You can still type in the text that you cannot copy. As I stated before, fair use does not mean convenience.
Is Okular doing the right thing?
Posted Jun 2, 2009 19:58 UTC (Tue) by ncm (guest, #165) [Link]
Is Okular doing the right thing?
Posted Jun 2, 2009 21:51 UTC (Tue) by sepreece (guest, #19270) [Link]
Free software ideals don't define what the software does out of the box, just that you're allowed to change it.
Okular has kindly provided a configuration bit to let you change it without doing any programming. Say, "Thank you", don't say "But, you should do it my way by default and if you don't you're violating the ideals of free software."
Is Okular doing the right thing?
Posted Jun 3, 2009 18:19 UTC (Wed) by ncm (guest, #165) [Link]
Is Okular doing the right thing?
Posted Jun 3, 2009 23:28 UTC (Wed) by sepreece (guest, #19270) [Link]
But, as noted, I'm an outsider, and if the Debian community feels violated by the default setting of a user-changeable option, by all means, change it...
Is Okular doing the right thing?
Posted Jun 4, 2009 1:15 UTC (Thu) by JoeF (guest, #4486) [Link]
And how exactly does that enforce "to make sure that there are not printed copies of older documents that are filed away and used by people for procedures"?
Anybody can just re-type the text in any text editor if they are so inclined.
You have a nice example of using an unsuitable tool to enforce behavior.
Is Okular doing the right thing?
Posted Jun 6, 2009 1:24 UTC (Sat) by pjm (guest, #2080) [Link]
(So the answer to the question “how ... does that enforce ...” is: it “urges” or “causes” (to quote one dictionary) that result both by informing the user that an author of the document has requested that the text not be copied or printed, and by requiring the user to go to extra effort to copy or print the document.)
The question under discussion is not whether copying is absolutely prevented (that question has already been answered both in the original article and in the post to which JoeF replies), but whether the software is effective in reducing costly mistakes, and whether there are any practical steps we can take to improve the tradeoff of preventing rare but costly mistakes against the cost of making it less convenient to copy when it is appropriate to copy.
(In this case, without yet having read the discussion in the bug report, I'd suggest that the dialog box could be improved by changing the text to ‘An author of the document has requested not to copy text from this document.’, and going on to inform the user how they can nevertheless copy from the document. Adding a button to the dialog box would be something to consider, though the trade-off is that users don't then get much chance to think about the reason for the request. Again, I haven't read the discussion in the bug report.)
And more generally under discussion is how one might handle other cases where there is some desire to hinder some user actions ("limit freedom") to prevent harm or achieve some other desirable result.
Is Okular doing the right thing?
Posted Jun 3, 2009 9:35 UTC (Wed) by jzbiciak (guest, #5246) [Link]
There can be a great many reasons why someone might want to force their way into a bathroom (the vast majority of them having to do with emergencies). In general, it's to handle circumstances unforeseen by the person who set the lock.
The same goes here. Someone sets a lock on a PDF, and it's an advisory measure. (If it really, really mattered, they would have encrypted it.) The lock says "Hey, I don't think you should copy this." It's an advisory mechanism, though, and easily bypassed. And that's how it should be. The person bypassing the lock at least has a chance of knowing the intent and desires of the author.
If I were to propose a change, it would be this: Convert the "DRM says you cannot do this" dialog that has a global, sticky override flag stored elsewhere to a "DRM asks that you not do this" dialog that has a per-instance override button that says "Copy anyway." That way, the user at least gets informed of the author's intent, even if they choose to override it. Overriding is easy, but not so easy that the user never learns of the author's desires. If you want to get fancy, remember the decision per-document, but don't make it global by default.
The current mechanism of simply disabling DRM checks across the board would be equivalent to banishing courtesy locks on bathroom doors in my analogy above. It totally disables and removes the mechanism provided for stating intent.
Is Okular doing the right thing?
Posted Jun 3, 2009 12:40 UTC (Wed) by sepreece (guest, #19270) [Link]
Is Okular doing the right thing?
Posted Jun 3, 2009 15:25 UTC (Wed) by Los__D (guest, #15263) [Link]
If we need language like this, the second option should of course be "That's MY choice, not his"
Is Okular doing the right thing?
Posted Jun 3, 2009 23:29 UTC (Wed) by sepreece (guest, #19270) [Link]
Is Okular doing the right thing?
Posted Jun 11, 2009 6:13 UTC (Thu) by huaz (guest, #10168) [Link]
> behavior here.
And who are you to decide which behavior is bad?
Come on, there is a standard and the code implemented it.
There is an option for you to turn it off if you care.
So spend five seconds clicking it off and stop whining!
Okular is doing the right thing. NOT.
Posted Jun 2, 2009 8:31 UTC (Tue) by smurf (subscriber, #17840) [Link]
>Yes, because the flags for said usage restrictions are part
>of the spec and the program is implementing the spec as
>designed. The programmers should be commended for such thoroughness.
One might argue that usage restrictions have no place in a spec in the first place. Those restrictions tend to be specious(sic). People click the "don't copy" button when creating these files for some arcane reason, but not because there's a real requirement to not be able to copy anything. Besides, there's Fair use.
The problem is even worse in DVDs. I'm not talking about DVDCSS here, but about the idea that disabling the Stop or Fast-Forward buttons makes any sense whatsoever. Yet, that's exactly what's done on quite a few DVDs. Not on the whole disc, of course -- just during the annoying "copyying is theft" 'message'. Oh, and during the previews for any other DVDs you might want to buy. Skipping commercials is some sort of libertarian leftie commie whateverie idea that needs to be eradicated, after all.
I digress. To summarize, my Fair Use right (usually) trumps your Set-Random-Bits-in-the-PDF rights.
I know that there are some exceptions. But: while you can certainly aggravate social or legal problems with technology, yon can't solve them that way.
Okular is doing the right thing. NOT.
Posted Jun 2, 2009 14:25 UTC (Tue) by MattPerry (guest, #46341) [Link]
> arcane reason, but not because there's a real requirement to not be able
> to copy anything.
How do you know that? You cannot predict the requirements of every user in the world. I just gave one example here (http://lwn.net/Articles/335669/) of a legitimate use.
> Besides, there's Fair use.
Your fair use rights are unaffected by this. You can take a screenshot. You can type in the text that you cannot copy. Fair use doesn't mean it has to be convenient for you.
> The problem is even worse in DVDs.
We are not talking about DVDs we are talking about PDFs. Please don't change the subject.
> I digress. To summarize, my Fair Use right (usually) trumps your
> Set-Random-Bits-in-the-PDF rights.
Again, your fair use rights are not affected. Stop whining because you might have to spend a few more minutes of work than you expected to exercise your fair use rights.
Okular is doing the right thing. NOT.
Posted Jun 2, 2009 15:17 UTC (Tue) by GreyWizard (guest, #1026) [Link]
Fair use doesn't mean it has to be convenient for you.
True, but the fact that the program is free software does. I expect a PDF viewer that I run on hardware I lawfully own to obey my instructions unconditionally, regardless of any "specifications" to the contrary. If I were willing to let other people decide what my computer does I would run Microsoft Windows or Mac OS X.
If your organization needs to restrict printing on its workstations and you feel that implementing that restriction in the PDF viewers installed on workstations it owns is the best solution I have no objection. Go ahead and install a modified package tailored to the needs of medical device manufacturers. If there is no such thing then modify the settings yourself.
Maybe an option for locking things down in this way does belong in a general purpose distribution like Debian. But if so it certainly must be off by default. Don't expect me to accept restrictions that are of no value to me. That's now how free software works.
Okular is doing the right thing. NOT.
Posted Jun 2, 2009 15:31 UTC (Tue) by MattPerry (guest, #46341) [Link]
> True, but the fact that the program is free software does. I expect a PDF
> viewer that I run on hardware I lawfully own to obey my instructions
> unconditionally, regardless of any "specifications" to the contrary. If I
> were willing to let other people decide what my computer does I would run
> Microsoft Windows or Mac OS X.
You point is moot as Okular has a configuration option to disable the feature/bug in question. Free software, like all software, is not a one size fits all proposition. You'll have to adjust settings and configurations to fit your definition of convenience.
Okular is doing the right thing. NOT.
Posted Jun 2, 2009 16:12 UTC (Tue) by GreyWizard (guest, #1026) [Link]
You point is moot as Okular has a configuration option
No, you have merely missed my point. A configuration option is reasonable (as I stated plainly abov) but the only tolerable default for a general purpose distribution is off. Expecting the most numerous users to fiddle with a setting to make things more convenient for a small group (medical device manufacturers in your example) is backwards.
Okular is doing the right thing. NOT.
Posted Jun 2, 2009 21:40 UTC (Tue) by sepreece (guest, #19270) [Link]
The point of free software is, as you say, that you control your machine. So, go control your machine! Set the configuration option or rebuild the package with your preferred default. That's what GPL freedom is about, not whether or not the default options suit your preferences.
Okular is doing the right thing. NOT.
Posted Jun 3, 2009 2:39 UTC (Wed) by GreyWizard (guest, #1026) [Link]
Your point seems to be that default settings can be chosen arbitrarily because users are prepared to spend unlimited time tuning their systems. Wrong. Changing configuration settings has a cost, including the possibility that a user will never discover the option at all. Therefore defaults are important and should be sensible for as many users as possible. People or organizations who wish to be bound by PDF restrictions are a tiny minority and so they should bear the cost of altering the configuration. Is that so hard to understand?
Okular is doing the right thing. NOT.
Posted Jun 3, 2009 10:18 UTC (Wed) by anselm (subscriber, #2796) [Link]
You're wrong. Free software is about you being able to scratch your own itches if required, not about having all your itches proactively scratched for you by others.
Free software authors (or distributors) are under no obligation whatsoever to cater to the wishes of »as many users as possible«. If they don't, they may have to accept the fact that nobody but themselves may be interested in their output, but if they're cool with that then it is totally their option. The whole point of free software is that you are (or anyone is) free to change a free program to suit different preferences than those of its original author, and to pass the changed program on to others.
So if the Debian KDE people won't uncheck that box for you, then you will unfortunately have to do it yourself, or else find another distribution that comes with it unchecked. You could even create your own Debian derivative that is 100% identical to Debian in every respect except that it has that box unchecked, and distribute that for the benefit of all the other users who aren't prepared to bear the cost of figuring out how to uncheck the box themselves. This is what free software is about, not getting everything perfect for everybody out of the box, which is obviously impossible.
Okular is doing the right thing. NOT.
Posted Jun 4, 2009 6:05 UTC (Thu) by GreyWizard (guest, #1026) [Link]
Okular is doing the right thing.mostly.
Posted Jun 3, 2009 13:23 UTC (Wed) by sepreece (guest, #19270) [Link]
You did correctly state one implication of my point. The complete point was that the essence of free software is that software creators can scratch their itch in whatever way they please and if downstream re-distributors and users don't like it, they're free to change it. That does imply that default settings are arbitrary, at the will of their creator.
Since neither of has any evidence as to the distribution of opinions across the user base, your estimate of a "tiny minority" has as good a chance of being right as any other. My own guess is that most users would be comfortable with supporting the flag by default if the warning behavior was changed to allow an override action as part of the dialog and to provide a better message (without the misleading word "DRM" - a simple statement that the author has disabled copying text from the document). I, for one, DO appreciate knowing when I'm breaking the author's expressed rules for using the document.
Okular is doing the right thing.mostly.
Posted Jun 4, 2009 5:49 UTC (Thu) by GreyWizard (guest, #1026) [Link]
That does imply that default settings are arbitrary, at the will of their creator.
No, it most certainly does not. Free software is not incompatible with striving for excellence. That means attempting to make the best decisions possible at every level, including making the defaults sensible for as many users as possible.
Since neither of has any evidence as to the distribution of opinions across the user base,
There is plenty of evidence on my side. But I don't care to present it because your challenge is not an intellectually honest one. You could apply this pattern to any statement, no matter how reasonable or self-evident. Do you have evidence that there is more light during the day than at night? Have you actually collected time series data of light measurements? Are you sure your instruments are calibrated properly? And so on. Would you waste time trying to convince me of the obvious? I hope not.
Therefore if you insist that there might be more users who prefer to be constrained by PDF flags than not we will have to agree to disagree.
I, for one, DO appreciate knowing when I'm breaking the author's expressed rules for using the document.
Wanting to know the author's preference is not the same as wanting to be constrained by it.
Okular is doing the right thing. NOT.
Posted Jun 2, 2009 15:42 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
At best enforcing the flags in the document in a software reader will prevent casual breaches in workplace protocol. They certainly aren't enough by themselves to prevent malicious intent.
My question is, would notification about the flags be just as effective as default enforcement? If there was space in the UI that communicated that the document was flagged no-copy but the software reader itself made no effort to prevent you from copying it by default..would the no-copy notification be just as effective at preventing casual protocol breaches?
-jef
Okular is doing the right thing. NOT.
Posted Jun 2, 2009 14:31 UTC (Tue) by sepreece (guest, #19270) [Link]
None of these sources believed the flag made it impossible to copy the document. However, the use of the flag means that a user copying the document has to be knowingly circumventing the flag. That makes it MUCH harder to argue in court that you didn't know you were breaking the rules when you copied a paragraph from a draft marketing announcement into a tech blog's rumor column.
I think supporting the flag, but allowing the user to circumvent it, is a nice balance between interests.
[NOTE: I'm less convinced than Jon that a court couldn't hold the flag to be considered to "effectively control access", but I don't think copyright is the real intended use of this flag.]
Okular is doing the right thing. NOT.
Posted Jun 3, 2009 0:13 UTC (Wed) by xilun (guest, #50638) [Link]
Okular is doing the right thing. NOT.
Posted Jun 3, 2009 12:45 UTC (Wed) by sepreece (guest, #19270) [Link]
Okular is doing the right thing. NOT.
Posted Jun 4, 2009 1:20 UTC (Thu) by JoeF (guest, #4486) [Link]
No, it doesn't. It just makes it more inconvenient. I can still open a text editor next to the PDF and re-type the snips.
As long as you can view the document, you can take snips out of it. If some PHB thinks otherwise, well, that's why he is a PHB.
Okular is doing the right thing. NOT.
Posted Jun 4, 2009 14:28 UTC (Thu) by sepreece (guest, #19270) [Link]
The point (from my perspective) is just to make sure the user knows he's breaking the author's rules.
Okular is doing the right thing. NOT.
Posted Jun 23, 2009 12:51 UTC (Tue) by Baylink (guest, #755) [Link]
I, personally, am on the side of the developer straight down the line here, and I think that the people whining about this need to go take a cold shower.
It'd be real interesting to hear rms's opinion on this: do you violate the spec in the name of "freedom!!!", or do you respect the spec? I'm sure he'd say violate it... but I think that knocks just a little chink in his armor, myself.
We *need* people like rms, don't get me wrong.
Just like we need lawyers.
But that doesn't mean we should do everything either of them say to.
The point is not so subtle and it's pointless to discuss it
Posted Jun 17, 2009 6:35 UTC (Wed) by khim (subscriber, #9252) [Link]
Yes, because the flags for said usage restrictions are part of the spec and the program is implementing the spec as designed.
Such behaiour is form of sabotage. It's called Italian strike. Recently Microsoft employed it and was rightfully condemned for it. I see no reason to applaud in this case too.
Specs are not objects of worshipment. Specs are just tools. The end goal is usefullness of software. When specs damage this goal - they should be ignored and/or fixed. Here is such a case.
The programmers should be commended for such thoroughness.
Are you masochist? Why will you commend someone for strike against you?
Okular is doing the right thing
Posted Jun 2, 2009 11:52 UTC (Tue) by epa (subscriber, #39769) [Link]
That's our Chandler allright
Posted Jun 2, 2009 18:41 UTC (Tue) by ikm (subscriber, #493) [Link]
It would be, unless they are morons. But since the latter is always true, it won't. So the better way to implement this option is to pop up a box saying: "The authors of this PDF don't really want you to copy anything to clipboard. Most probably they like it more when you type it all back yourself, since this is apparently better for your fingers. Would you care to [honor it] [ignore it] [and don't ever show this again!]"
Okular, Debian, and copy restrictions
Posted Jun 1, 2009 22:11 UTC (Mon) by johnflux (guest, #58833) [Link]
You can easily turn off, but in corporate settings the administrator can override and force the protection on or off (through the kiosk tool).
I can't believe that people are complaining about this.
Okular, Debian, and copy restrictions
Posted Jun 1, 2009 22:52 UTC (Mon) by quotemstr (subscriber, #45331) [Link]
My only gripe is the default setting: DRM should be off by default. These "restrictions" are in practice just advisory, and the user should opt into them.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 0:06 UTC (Tue) by briangmaddox (guest, #39279) [Link]
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 0:17 UTC (Tue) by bjacob (subscriber, #58566) [Link]
This article is massively skewed as it implies that Okular tries to force DRM onto the user.
The truth, as explained in a comment above, is that DRM can be disabled most easily in 4 clicks at the most obvious place in Okular's configuration dialog.
Moreover, it is up to the linux distros and/or sysadmins to define the default configuration. By making this a regular KDE configuration entry, okular makes it most convenient for the distros and sysadmins to decide.
Thus the whole discussion about "should be opt-in" is moot. At the very worst, Okular can waste the user's time doing 4 obvious clicks. Doesn't the author have anything more important to write about?
It is unfortunate that the article failed to mention this very important fact and thus gives an impression of Okular that just doesn't match reality.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 0:30 UTC (Tue) by bjacob (subscriber, #58566) [Link]
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 0:47 UTC (Tue) by corbet (editor, #1) [Link]
I'm sorry you're not happy with the article. I do think it is an interesting and relevant topic, though. As a community, we have to make decisions like this; it's good to expose them widely and think them through.The article talked about the configuration option and the discussion over what the default value should be. But, do me a favor: look at the screenshot and tell me how an average user will know that this option exists? Unless they've been told that there's an "unbreak this application" option available, all they will see is that they are being prevented from carrying out a natural action which, in all likelihood, infringes on nobody's rights at all.
Should we extend cp to make it refuse to copy such files? I hope you would say "no." So there's a line to be drawn somewhere. How do we decide where that line is?
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 1:41 UTC (Tue) by bjacob (subscriber, #58566) [Link]
> As a community, we have to make decisions like this; it's good to expose them widely and think them through.
I think that the reason why this article made me react is that this is a sensitive issue as it can easily make Okular look bad ("boo DRM-enforcers"), I can imagine how Okular developers feel reading your article (by the way see Albert's and Aaron's blog posts currently on PlanetKDE) as it makes them look like they try to help DRM enforcement -- a very unenviable position for a FOSS developer.
My point, I think, is that linux distros usually depart massively from the default configuration as far as KDE is concerned (not even mentioning that they often use many custom patches against KDE), so I don't see why this should be an exception in this case -- in other words: this is mostly an issue for linux distros rather than for the end-user.
> But, do me a favor: look at the screenshot and tell me how an average user will know that this option exists?
I do agree that it would be an improvement if the message there had a button to open the relevant configuration dialog to disable DRM.
But I think that any user who knows what FLOSS is, will guess by himself that there must be a configuration option for this, hence will open the configuration dialog and will find the relevant checkbox right away.
The other users, who don't understand what FLOSS is, probably use standard packages from their distro with the distro's default config choices, and it is then, as said above, entirely up to the distro: the default choice made by Okular developers hardly matters there, as distros very frequently override KDE's own defaults.
> Should we extend cp to make it refuse to copy such files? I hope you would say "no." So there's a line to be drawn somewhere. How do we decide where that line is?
I never said that any program, either okular or cp or any other program, "should" honor DRM restrictions. I only ever disputed the idea that it was bad that okular defaulted to.
I didn't say either that it was a good thing that okular does; i only said that it isn't a bad thing. In other words: it's pretty much irrelevant as it's the distro or sysadmin who should decide; and in the worst case the configuration dialog makes it easy to toggle. I agree that it would be a nightmare if every program required one(either user or distro) to change that setting separately, so ideally there should be a way to set that once and for all with a global setting that all applications would then honor.
But of course there is no way that it would make sense of "cp" to honor that, "cp" is just a lowlevel filesystem operation and by definition only honors filesystem-level permissions.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 2:54 UTC (Tue) by ncm (guest, #165) [Link]
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 8:51 UTC (Tue) by jamesh (guest, #1159) [Link]
> their nutty opinions ought to be equally of no practical interest to
> anybody.
As an upstream developer who has dabbled a bit in packaging, I disagree quite strongly with this.
If the upstream developer uses defaults that are not appropriate for the majority of users, then that sounds like a bug. The fact that a distribution packager can cover up the problem for a large number of users doesn't change that.
If the distribution packager isn't in a position to communicate the need for such changes with the upstream, then you've got more problems. If they can't forward bugs and patches upstream then they'll be stuck maintaining fixes locally (which is a maintenance problem, and doesn't benefit any other distros).
Looking at it from the upstream point of view I accept that distros might make some changes to the code for the purpose of integration with the rest of the system, but would prefer to see other patches forwarded upstream.
Changing this option doesn't seem related to system integration so I'd expect the distro packager to discuss it with upstream. It isn't clear whether this happened in this case though -- just the packager saying he doesn't want to maintain the patch himself.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 20:07 UTC (Tue) by ncm (guest, #165) [Link]
Hence, I don't see what you're disagreeing with. We seem to agree that it's a bug, and it's clear that upstream has refused to fix it. What's anomalous here is that the packagers have also refused to fix it, under what might or might not be the same process (which I refuse to call reasoning) used by upstream.
Ultimately this only matters if the infection spreads.
Okular, Debian, and copy restrictions
Posted Jun 3, 2009 15:12 UTC (Wed) by nye (guest, #51576) [Link]
I use Okular all the time and I've yet to come across a PDF with this option set, but I'd find it quite interesting I think.
Certainly I can't imagine a corporation ever wanting to change the default because with the default as it is, the blame is squarely on the user, who can't claim that they weren't notified. In that case it seems like this safer default is the most sane choice.
Or are you simply trolling? All of your posts in this thread have sounded like the ravings of a madman so it's hard to tell.
FAIL
Posted Jun 3, 2009 18:36 UTC (Wed) by ncm (guest, #165) [Link]
Let the record show that nye was the first participant in this discussion to rely on ad hominem remarks.FAIL.
FAIL
Posted Jun 3, 2009 22:20 UTC (Wed) by nix (subscriber, #2304) [Link]
and energy you've spent doing stuff with C++ would have driven any man
mad.
But now you've implied that in fact you are not mad, and we must take you
at your word ;)
(FWIW I agree with you, less vehemently: attempting to copy from a
copy-prohibited document should warn about the prohibition *and let you
turn it off*, for good or for that one document. The current situation
isn't good enough. Prior art: browser cookie management options.)
not FAIL
Posted Jun 4, 2009 0:30 UTC (Thu) by ncm (guest, #165) [Link]
FAIL
Posted Jun 4, 2009 1:26 UTC (Thu) by JoeF (guest, #4486) [Link]
copy-prohibited document should warn about the prohibition *and let you
turn it off*, for good or for that one document. The current situation
isn't good enough. Prior art: browser cookie management options.)"
Yes, that would be a very sensible approach.
If the developers implement that, this article would have proven to be very useful ;-)
FAIL
Posted Jun 4, 2009 10:30 UTC (Thu) by nye (guest, #51576) [Link]
Tch.
Okular, Debian, and copy restrictions
Posted Jun 3, 2009 11:05 UTC (Wed) by mbanck (guest, #9035) [Link]
Michael
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 6:32 UTC (Tue) by amit (subscriber, #1274) [Link]
But that's not a direct analogy: No one's restricting you from viewing that pdf or distributing it. BTW password-protected pdfs encourage such 'for-your-eyes-only' behaviour. That should be cause for more concern as far as free speech is concerned.
Okular, Debian, and copy restrictions
Posted Jun 3, 2009 0:45 UTC (Wed) by rlk (guest, #47505) [Link]
A better design, in my view, would be for the program to pop up a notification ("the creator of this file has chosen to forbid copying data") if one tried to do something forbidden, along with options "don't do this", "allow this once", "always allow this for this file", and "always allow this" (or whatever).
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 0:54 UTC (Tue) by pr1268 (subscriber, #24648) [Link]
Doesn't the author have anything more important to write about?
Ususally. Perhaps it was a slow news day. Our editor (Jon) writes brilliant articles, mostly about the Linux kernel and contemporary issues facing Linux and Open Source. Perhaps it was a slow news day, or perhaps the release of Okular (and its default configuration of enabling DRM) was a topic Jon felt pertinent to write about.
I can't believe that I just paid for a 6 month subscription to LWN, only to read this.
Rest assured that your subscription money was well-spent. Keep coming to LWN—I'm certain that you'll find the quality of the articles and commentary is worth it.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 1:10 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
We also want to provide the best default configuration without a few weeks spent on fine tuning.
> Moreover, it is up to the linux distros and/or
> sysadmins to define the default configuration.
Actually the Debian maintainer of the respective package also claimed here he does not want to deviate from the upstream package.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 1:17 UTC (Tue) by bjacob (subscriber, #58566) [Link]
As far as I can see, the article only says that he doesn't want to patch Okular for that. But changing the configuration is not the same thing as patching.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 3:56 UTC (Tue) by jamesh (guest, #1159) [Link]
Granted this is a small change, but it isn't necessarily simpler to maintain than a small code change.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 1:01 UTC (Tue) by 0b11101 (guest, #57638) [Link]
While there are people who rightly do not want any DRM framework on their GNU-Linux distributions, there is a growing number of users who legitimately demand access to these file types.
Pino brings up another valid point that a perfect implementation of a restrictive technology necessarily means putting those restrictions in for all users, even those who choose not to partake in the copy-restricted media files.
One might say that a distribution could just strip out any DRM framework, but then would it be acceptable to use a distribution without PDF and Flash Video support? Unless you are willing to (illegally?) circumvent the digital restrictions in the specification, seems like you have to accept the DRM with the file support.
Worse, people with any stake in the debate want the restrictions in place for everyone: the copyright publishers who fanatically guard their copyright monopoly, the computer users hungry for all they can eat media content, and the developers who want to write their code to the exact specification. And while users, like Goerzen, can completely reject digitally restricted files, they can still be effected by the unrelated use of those popular file formats.
This is an issue that is going to rise up very soon specifically in GNU-Linux distributions, as both more media content is distributed with digital restrictions and more users demanding access to that media content. I perceive DRM frameworks (in both proprietary and free software) rolling out for text, audio, and video, as well as the multinational legislation and hardware solutions needed to enforce those restrictions. Scary stuff.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 1:37 UTC (Tue) by ncm (guest, #165) [Link]
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 1:49 UTC (Tue) by 0b11101 (guest, #57638) [Link]
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 2:57 UTC (Tue) by ncm (guest, #165) [Link]
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 4:20 UTC (Tue) by 0b11101 (guest, #57638) [Link]
The Okular application says specifically, "copy forbidden by DRM".
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 6:34 UTC (Tue) by ncm (guest, #165) [Link]
Okular, Debian, and copy restrictions
Posted Jun 16, 2009 13:43 UTC (Tue) by zenaan (guest, #3778) [Link]
My god it's good to be involved with the gang at LWN!
Made my day. Nothin like a regular dose of rationality. With class.
And Jon - excellent article! Clearly a timely raising of these issues.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 4:39 UTC (Tue) by foom (subscriber, #14868) [Link]
It seems pretty much like DRM to me.DRM generally uses encryption, with the distinguishing feature of having the decryption key widely known to all viewer software/hardware in the world. By thus controlling access to the encrypted data by requiring use of the special software with the decryption key, the content creators prevent users from accessing the content in objectionable ways. (or so they'd like to think).
This is exactly what the copy-prohibit flag in PDF is doing, except that the default decryption key is actually documented in the PDF format documentation! That part is a little unusual for DRM, and I suppose might make ignoring this flag not trigger the anti-DRM-bypass laws.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 4:58 UTC (Tue) by 0b11101 (guest, #57638) [Link]
http://thomas.loc.gov/cgi-bin/query/F?c105:6:./temp/~c105...
Circumvention
Posted Jun 2, 2009 14:56 UTC (Tue) by man_ls (guest, #15091) [Link]
The very easy answer is: users do not want DRM restrictions and providers must cater to those users. DRM has failed in mp3 downloads, in DVD players, in protected documents, and in the few areas where it is still tolerated (iPhone apps, DVD CSS, console games) enforcement is quite lax.Circumvention is a valid possibility. AFAIK it is not illegal in the EU or elsewhere, so it can only be a problem in the US.
Circumvention
Posted Jun 2, 2009 16:33 UTC (Tue) by 0b11101 (guest, #57638) [Link]
Plus, a quick read of the Directive 2001/29/EC seems to specifically prohibit circumvention of technical copyright restrictions. In Article 6, Section 1: "Member States shall provide adequate legal protection against the circumvention of any effective technological measures, which the person concerned carries out in the knowledge, or with reasonable grounds to know, that he or she is pursuing that objective."
Circumvention
Posted Jun 16, 2009 13:52 UTC (Tue) by zenaan (guest, #3778) [Link]
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 11:37 UTC (Tue) by nelljerram (subscriber, #12005) [Link]
Where does free software play between the interests of the copyright owners and the users who want to use the copyrighted material with all the restrictions set by the owners?Abide by the copyright. No question about it. Free software fundamentally depends on that.
We can criticize the law on what is allowed to be copyrighted, and for how long, and try to get that law revised, but that's a completely different matter.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 14:06 UTC (Tue) by k8to (guest, #15413) [Link]
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 15:07 UTC (Tue) by nybble41 (subscriber, #55106) [Link]
In any event, this isn't about enforcing or violating copyrights. This is about resisting the user's efforts to employ their documents in ways which they may well have every legal right to use them. An unobtrusive notice that restrictions were requested might be reasonable, but the purpose of software is to assist users in accomplishing their goals. Any software so perverted as to deliberately hinders its users is an abomination.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 21:29 UTC (Tue) by sepreece (guest, #19270) [Link]
Well, what about the goals of the other users - the ones who wrote and distributed the documents? Their goals may well include, for instance, sending documents out for comment or distributing internal corporate documents that they don't want to see copied into rumor-site postings.
Sure, it's not a serious impediment to copying by people who want to do so, but at least you're making sure they know that they're violating the rules governing your distribution of the document. MANY documents are NOT subject to fair use, because they are distributed under other conditions, to which the user has agreed before receiving the document.
Okular, Debian, and copy restrictions
Posted Jun 3, 2009 18:06 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
What about them? They're users of other software, not Okular. Okular should cater to the needs and wants of its own users. If others want to set these bits in documents they write, their authoring software should likewise allow them to do so.
As I said, it would be reasonable to passively inform the user that these bits are set. Describing the content of a document is, after all, Okular's primary purpose. It is the fact that Okular actively resists its users' obvious intent which I find objectionable. It goes against the entire spirit of Free Software, which is that users should have full control over the software they use.
Okular, Debian, and copy restrictions
Posted Jun 3, 2009 18:18 UTC (Wed) by sfeam (subscriber, #2841) [Link]
which I find objectionable."
What on earth are you talking about? Okular provides a toggle for the
user to express their intent, i.e. honor or ignore the copy restriction
flag, and honors the setting chosen by the user.
I hit this "problem" during my first day of using KDE4, which uses Okular.
I was confused for the approximately 5 seconds it took to read and
comprehend the greyed-out message, and then another 10 seconds to find and
toggle the setting. That's utterly trivial compared to, say, figuring out
how to make Gnome honor my intent as a user to respond to single
right-mouse clicks rather than double left-mouse clicks :-)
Okular, Debian, and copy restrictions
Posted Jun 3, 2009 19:25 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
Furthermore, while you and I might not have any issues locating it without help, that would not be true for many of Okular's other users. A surprising number of computer users find themselves intimidated by standard configuration dialogs, and those unfamiliar with (or insecure in their knowledge regarding) software design could easily find themselves wondering whether disabling the restrictions might have unwanted, and possible irreversible, side-effects.
In short, the default assumption should be that users both know what they are doing and have all the necessary authority to do it, unless they deliberately disavow such knowledge or authority. On that basis, the default setting should have been to ignore any restriction requests present in the document, aside from possibly displaying them unobtrusively to the user.
"That's utterly trivial compared to, say, figuring out how to make Gnome honor my intent as a user to respond to single right-mouse clicks rather than double left-mouse clicks."
Perhaps so, but there is a world of difference between presenting a default interface which, while full-featured, may not match a specific user's preferences, and going out of one's way to completely disable standard functionality.
Okular, Debian, and copy restrictions
Posted Jun 3, 2009 22:22 UTC (Wed) by nix (subscriber, #2304) [Link]
configuration dialogs, KDE is not the desktop for you :)
Any software to toggle this flag?
Posted Jun 2, 2009 1:18 UTC (Tue) by foom (subscriber, #14868) [Link]
my poor Windows Acrobat-using compatriots? I use software which simply ignores it, but for others
it's not so easy.
Last time I looked, I couldn't find any such software which worked without knowing the "Admin"
password for the PDF, but I find it rather hard to believe nobody's written that tool.
Any software to toggle this flag?
Posted Jun 2, 2009 1:34 UTC (Tue) by ncm (guest, #165) [Link]
Any software to toggle this flag?
Posted Jun 2, 2009 2:55 UTC (Tue) by foom (subscriber, #14868) [Link]
including even basic things like the "cat" command.
pdftk test.pdf output test.output.pdf allow AllFeatures
Error: Failed to open PDF file:
test.pdf
OWNER PASSWORD REQUIRED, but not given (or incorrect)
Errors encountered. No output created.
Done. Input errors, so no output created.
Any software to toggle this flag?
Posted Jun 2, 2009 3:57 UTC (Tue) by foom (subscriber, #14868) [Link]
http://newsgroups.derkeiler.com/Archive/Comp/comp.text.pd...
The source says:
input_pdf_p->m_authorized_b= ( !reader->encrypted || reader->passwordIsOwner );
But of course I want:
input_pdf_p->m_authorized_b= true;
Hooray for DRM.
I submitted http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531529 for this.
Any software to toggle this flag?
Posted Jun 2, 2009 1:52 UTC (Tue) by bronson (subscriber, #4806) [Link]
A while ago I had a ton of PDFs that I needed to fix so I wrote this:
http://github.com/bronson/pdfdir/blob/a6d78e9db4d0db20d73...
Not pretty but it worked great.
Any software to toggle this flag?
Posted Jun 2, 2009 2:19 UTC (Tue) by foom (subscriber, #14868) [Link]
links, and end up a lot larger than the original. (unless that's changed recently?)
Over the top
Posted Jun 2, 2009 2:25 UTC (Tue) by BrucePerens (guest, #2510) [Link]
So, if the PDF format provides a way for the author to insert a "please don't make unauthorized copies" message at relevant points, and we don't honor that, aren't we going over the top? It's not as if it were real DRM.
Over the top
Posted Jun 2, 2009 2:55 UTC (Tue) by ncm (guest, #165) [Link]
Over the top
Posted Jun 2, 2009 3:01 UTC (Tue) by foom (subscriber, #14868) [Link]
In my particular case, I get a large collection of pdf documentation from another company. *Some*
of it is randomly copy-prohibited, for no discernible reason. Sometimes I request that they
regenerate the affected PDFs without the prohibitions, but it takes a while for that to be done,
because it's of course not a priority. It'd be a lot easier to just run the pdfs through an automated
user-prohibition-remover program...if one existed.
Over the top
Posted Jun 2, 2009 12:53 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
Over the top
Posted Jun 2, 2009 3:02 UTC (Tue) by BrucePerens (guest, #2510) [Link]
When the copyright holder sets the flag, that's like saying it isn't authorized.
Over the top
Posted Jun 2, 2009 3:06 UTC (Tue) by jake (editor, #205) [Link]
> authorized.
So, the copyright holder can dictate that fair use rights can't be exercised?
jake
Over the top
Posted Jun 2, 2009 3:18 UTC (Tue) by BrucePerens (guest, #2510) [Link]
Can you show me what law defines Fair Use?
Over the top
Posted Jun 2, 2009 3:42 UTC (Tue) by k8to (guest, #15413) [Link]
Are you now trying to claim that case law doesn't exist?
Over the top
Posted Jun 2, 2009 3:49 UTC (Tue) by BrucePerens (guest, #2510) [Link]
I know the case law exists. But there is no affirmative fair use right. There is something in 17 USC 107 that essentially makes fair use a valid defense in an infringement case. But it is really vague, because it wasn't intended to give you any more than case law existing in 1976 had already given you.The result is that you can't really say that turning off that flag is a fair use right. And whatever balance Open Source arrives at with content owners, if we are going to be able to operate in the future world, isn't going to be "I won't even display your notices because I feel even those violate my rights".
Perhaps you haven't noticed the success of the Kindle. And now here comes Google with their own scheme. And slowly we are being swept into a corner where we will be an uncommunicating island within the internet, walled off from content.
Free software dies at its own hands.
Over the top
Posted Jun 2, 2009 3:59 UTC (Tue) by jake (editor, #205) [Link]
And the solution is that we default the behavior of PDF readers to disallow cut-n-paste if the copyright holder says we can't?
I fail to see how that makes these rights holders particularly happy. And Jon's example in the screenshot was the ALI document that he wrote about a week or two ago. Pretty obvious fair use in my opinion.
The rights holders who think they should be able to control every last use of their so-called property won't be happy until they have fully locked-down systems anyway. Pushing back is the only way the public (who, after all, grants the copy 'right') can show that there are perfectly legitimate uses that the rights holders are trying to prevent.
jake
Over the top
Posted Jun 2, 2009 4:53 UTC (Tue) by BrucePerens (guest, #2510) [Link]
Sure, Jon's example was non-infringing because it was his own work and deliberately engineered to turn on the notice he wanted to display. But it's silly to claim that's the common use.Sure, we want concessions from rights holders, so that Free Software / Open Source can participate in tomorrow's media. They want something too. There are concessions that we can't make to them, because that would make the software not Free any longer. "My way or the highway" isn't going to be a valid strategy because we're not running the show - we hardly even have a seat at the meeting. So, let's not throw away the few concessions that we can make.
Over the top
Posted Jun 2, 2009 5:04 UTC (Tue) by jake (editor, #205) [Link]
> deliberately engineered to turn on the notice he wanted to display.
What I meant, and obviously didn't make clear, was that Jon quoted from that ALI PDF file in his article. *That* was, imo, fair use. And would have been 'prevented' by the copy bit.
In another comment you said:
> if we want to have some role for Open Source in society's future other
> than supporting locked-down systems, respect other folks rights as we
> would have them respect ours.
But I haven't seen anyone arguing otherwise. They just need to respect our rights (or defenses) as well. And, by and large, they don't.
jake
Over the top
Posted Jun 2, 2009 5:25 UTC (Tue) by BrucePerens (guest, #2510) [Link]
Nothing was preventing Jon from typing in a few lines.The problem is that we haven't done anything to convince the media producers, or legislators, that we have any rights worth protecting. Because we are not, in general, representative of their customers, who are perfectly happy with what they have.
Over the top
Posted Jun 2, 2009 4:06 UTC (Tue) by foom (subscriber, #14868) [Link]
It's interesting that the Kindle's DRM scheme had been broken at least a few years before the Kindle
was even released. And yet that doesn't seem to have bothered anyone.
I'm not sure what to think about that -- perhaps content owners consider it good enough, if it
takes users 4 clicks to bypass the restrictions?
Over the top
Posted Jun 2, 2009 4:56 UTC (Tue) by BrucePerens (guest, #2510) [Link]
If they do, we really, really, want them to keep doing so. I think people are under-estimating the value of that.
Over the top
Posted Jun 2, 2009 4:14 UTC (Tue) by ncm (guest, #165) [Link]
If you are arguing that some recognition of that flag is advisable, then having only the option to turn it off permanently is, equally, inadvisable. Everyone is motivated to turn it off, and then they never learn that the distributor of any given document turned it on. A reasonable implementation of the standard would display an icon indicating the flag is on, and might, on occasion, post a dialog box with a button to indicate that I know I have the right to perform the action anyhow.
Under not uncommon circumstances I really do have a right to actually turn off that flag in the file. It's neither KDE's nor Debian's business to make it hard for me to exercise that right.
Over the top
Posted Jun 2, 2009 4:42 UTC (Tue) by BrucePerens (guest, #2510) [Link]
The biggest difference between affirmative rights defenses is that you can't sue someone for violating your defense. You can only use it to defend yourself if you get sued.What I am arguing is that we should, if we want to have some role for Open Source in society's future other than supporting locked-down systems, respect other folks rights as we would have them respect ours.
Over the top
Posted Jun 15, 2009 5:12 UTC (Mon) by Arker (guest, #14205) [Link]
What I am arguing is that we should, if we want to have some role for Open Source in society's future other than supporting locked-down systems, respect other folks rights as we would have them respect ours.
I dont think anyone disagrees with that. I also dont think it is at all on point. No one has any right to take control of my computer from me, period, end of story.
Many people clearly believe they have such a right but they are mistaken. This is not a conflict between my rights and their rights, it's a conflict between my rights and their desires. My rights win.
The Okular maintainers are not violating my rights - they are in no way forcing me to use their software, and they have the right to make it however they think right. Although their choice in this situation makes it clear they are dangerous lunatics, that is their right.
The same can be said for the Debian maintainers, although it is much more disturbing given the long commitment from Debian to respecting users rights. But in the end, we dont have to use Debian either.
But really, if this becomes more than an isolated incident but a harbinger of how Debian looks to move forward, then Debian will die, or morph into some sort of corporate controlled fifth column. I dont want to see either of these things happen.
Over the top
Posted Jun 15, 2009 8:44 UTC (Mon) by nix (subscriber, #2304) [Link]
Debian Policy anytime soon, and that Debian is basically a mass of chaotic
independent arguing maintainers except inasmuch as constrained by Policy,
I'd say your fear of a (ha!) corporate-controlled Debian is needless.
Over the top
Posted Jun 2, 2009 6:16 UTC (Tue) by 0b11101 (guest, #57638) [Link]
As long as there is open access to the network, there will be sufficient media available, with a permissive copyright license for unrestricted duplication. Enough for lifetimes of text, music, and videos. If that means being locked out of the latest 90 minute animated video, then it may be a sacrifice that some will choose for their freedoms.
Over the top
Posted Jun 2, 2009 12:53 UTC (Tue) by BrucePerens (guest, #2510) [Link]
I worked in the film industry for 19 years total. But I can't really believe this is an issue for Pixar - they're not in danger from downloading. I was also a book series editor, but my books were always under an open publication license.I do think I can see both sides of the argument. And I believe that having some empathy for the people they are arguing with would only help Free Software developers win the fight instead of shooting themselves in the foot.
Over the top
Posted Jun 4, 2009 8:41 UTC (Thu) by liljencrantz (guest, #28458) [Link]
Quite the opposite, the content industry has continually tried to block free software from accessing their content in any way they can, no matter what we do. If proprietary software keeps prioritizing partners over users, while open source does not, that will ensure free software use will increase, and content providers will be forced to take notice of us by sheer force of market share. We don't owe content producers anything, we owe it to ourselves and our users to ignore them and stay true to our ideals.
Over the top
Posted Jun 4, 2009 20:18 UTC (Thu) by nix (subscriber, #2304) [Link]
starts really using the TPM and things like HDMI that move decryption into
the display/sound hardware :(
Over the top
Posted Jun 5, 2009 7:50 UTC (Fri) by liljencrantz (guest, #28458) [Link]
I know of no major DRM implementation that has not been quickly cracked - have you actually looked?
Posted Jun 17, 2009 7:05 UTC (Wed) by khim (subscriber, #9252) [Link]
I know of no major DRM implementation that has not been quickly cracked, and I strongly believe that the reason for this is that the concept of DRM is technically flawed.
Have you actually tried to find such an implementation or are you living in your own phantasy world? The very first DRM implementation designed with help of cryptoanalysts - Cell - was successfully used for working DRM protestion of PS3 titles. The solution is on the market for 2.5 years, there are ove 20 millions players and 100 millions disks, yet DRM is holding? Will it work forever? Probably not - but then it has no need to: 20-30 years from now disks will deteriorate and the fact that DRM will be broken will have no practical significance...
Over the top
Posted Jun 2, 2009 9:09 UTC (Tue) by paulj (subscriber, #341) [Link]
Next..
Over the top
Posted Jun 2, 2009 16:51 UTC (Tue) by shmget (guest, #58347) [Link]
"Can you show me what law defines Fair Use? "
No problem:
Art. L. 122-5. Lorsque l'oeuvre a été divulguée, l'auteur ne peut interdire :
1° Les représentations privées et gratuites effectuées exclusivement dans un cercle de famille ;
2° Les copies ou reproductions strictement réservées à l'usage privé du copiste et non destinées à une utilisation collective, à l'exception des copies des oeuvres d'art destinées à être utilisées pour des fins identiques à celles pour lesquelles l'oeuvre originale a été créée et des copies d'un logiciel autres que la copie de sauvegarde [1] établie dans les conditions prévues au II de l'article L.122-6-1 ainsi que des copies ou reproductions d'une base de données électronique ;
3° Sous réserve que soient indiqués clairement le nom de l'auteur et la source :
a) Les analyses et courtes citations [3] justifiées par le caractère critique, polémique, pédagogique, scientifique ou d'information de l'oeuvre à laquelle elles sont incorporées ;
b) Les revues de presse ;
c) La diffusion, même intégrale, par la voie de presse ou de télédiffusion, à titre d'information d'actualité, des discours destinés au public prononcés dans les assemblées politiques, administratives, judiciaires ou académiques, ainsi que dans les réunions publiques d'ordre politique et les cérémonies officielles ;
d) Les reproductions, intégrales ou partielles d'oeuvres d'art graphiques ou plastiques destinées à figurer dans le catalogue d'une vente judiciaire effectuée en France pour les exemplaires mis à la disposition du public avant la vente dans le seul but de décrire les oeuvres d'art mises en vente.
e) La représentation ou la reproduction d'extraits d'œuvres, sous réserve des œuvres conçues à des fins pédagogiques, des partitions de musique et des œuvres réalisées pour une édition numérique de l'écrit, à des fins exclusives d'illustration dans le cadre de l'enseignement et de la recherche, à l'exclusion de toute activité ludique ou récréative, dès lors que le public auquel cette représentation ou cette reproduction est destinée est composé majoritairement d'élèves, d'étudiants, d'enseignants ou de chercheurs directement concernés, que l'utilisation de cette représentation ou cette reproduction ne donne lieu à aucune exploitation commerciale et qu'elle est compensée par une rémunération négociée sur une base forfaitaire sans préjudice de la cession du droit de reproduction par reprographie mentionnée à l'article L. 122-10.
4° La parodie, le pastiche et la caricature, compte tenu des lois du genre. [5]
5° Les actes nécessaires à l'accès au contenu d'une base de données électronique pour les besoins et dans les limites de l'utilisation prévue par contrat.
6° La reproduction provisoire présentant un caractère transitoire ou accessoire, lorsqu'elle est une partie intégrante et essentielle d'un procédé technique et qu'elle a pour unique objet de permettre l'utilisation licite de l'œuvre ou sa transmission entre tiers par la voie d'un réseau faisant appel à un intermédiaire ; toutefois, cette reproduction provisoire qui ne peut porter que sur des œuvres autres que les logiciels et les bases de données, ne doit pas avoir de valeur économique propre ;
7° La reproduction et la représentation par des personnes morales et par les établissements ouverts au public, tels que bibliothèques, archives, centres de documentation et espaces culturels multimédia, en vue d'une consultation strictement personnelle de l'œuvre par des personnes atteintes d'une ou plusieurs déficiences des fonctions motrices, physiques, sensorielles, mentales, cognitives ou psychiques, dont le niveau d'incapacité est égal ou supérieur à un taux fixé par décret en Conseil d'État et reconnues par la commission départementale de l'éducation spécialisée, la commission technique d'orientation et de reclassement professionnel ou la commission des droits et de l'autonomie des personnes handicapées mentionnée à l'article L. 146-9 du code de l'action sociale et des familles, ou reconnues par certificat médical comme empêchées de lire après correction. Cette reproduction et cette représentation sont assurées, à des fins non lucratives et dans la mesure requise par le handicap, par les personnes morales et les établissements mentionnés au présent alinéa, dont la liste est arrêtée par l'autorité administrative.
Les personnes morales et établissements mentionnés au premier alinéa du présent 7° doivent apporter la preuve de leur activité professionnelle effective de conception, de réalisation et de communication de supports au bénéfice des personnes physiques mentionnées au même alinéa par référence à leur objet social, à l'importance de leurs membres ou usagers, aux moyens matériels et humains dont ils disposent et aux services qu'ils rendent.
À la demande des personnes morales et des établissements mentionnés au premier alinéa du présent 7°, formulée dans les deux ans suivant le dépôt légal des œuvres imprimées, les fichiers numériques ayant servi à l'édition de ces œuvres sont déposés au Centre national du livre ou auprès d'un organisme désigné par décret qui les met à leur disposition dans un standard ouvert au sens de l'article 4 de la loi n° 2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique. Le Centre national du livre ou l'organisme désigné par décret garantit la confidentialité de ces fichiers et la sécurisation de leur accès ;
8° La reproduction d'une œuvre, effectuée à des fins de conservation ou destinée à préserver les conditions de sa consultation sur place par des bibliothèques accessibles au public, par des musées ou par des services d'archives, sous réserve que ceux-ci ne recherchent aucun avantage économique ou commercial ;
9° La reproduction ou la représentation, intégrale ou partielle, d'une œuvre d'art graphique, plastique ou architecturale, par voie de presse écrite, audiovisuelle ou en ligne, dans un but exclusif d'information immédiate et en relation directe avec cette dernière, sous réserve d'indiquer clairement le nom de l'auteur.
Le premier alinéa du présent 9° ne s'applique pas aux œuvres, notamment photographiques ou d'illustration, qui visent elles-mêmes à rendre compte de l'information.
Les reproductions ou représentations qui, notamment par leur nombre ou leur format, ne seraient pas en stricte proportion avec le but exclusif d'information immédiate poursuivi ou qui ne seraient pas en relation directe avec cette dernière, donnent lieu à rémunération des auteurs sur la base des accords ou tarifs en vigueur dans les secteurs professionnels concernés.
Over the top
Posted Jun 2, 2009 3:21 UTC (Tue) by ncm (guest, #165) [Link]
I just talked to the author on the phone. He says, "No, you're authorized to copy it", and I believe him. But the software completely ignores him.Bruce, you usually make sense. What are you up to?
Over the top
Posted Jun 2, 2009 3:32 UTC (Tue) by BrucePerens (guest, #2510) [Link]
What's up is that I think other folks have rights too. What we're talking about now is a "soft" approach to rights management that can be disabled in a few clicks. If we don't let authors have that much, what is going to keep them from locking their works up so well that Open Source can't ever be used to view them. Sometimes we really do go too far.But putting up that soft, overridable not-quite-DRM, think some, violates their fair use rights. The reality is that fair use is a defense rather than an affirmative right. You don't really have them the way you think. And that's less than optimal, I agree.
Over the top
Posted Jun 2, 2009 4:59 UTC (Tue) by timschmidt (guest, #38269) [Link]
BrucePerens said:If we don't let authors have that much, what is going to keep them from locking their works up so well that Open Source can't ever be used to view them.
Nothing. And nothing will stop them from fading into obscurity as no one can (or wants to) view their content.
Over the top
Posted Jun 2, 2009 5:07 UTC (Tue) by BrucePerens (guest, #2510) [Link]
Jamie Love has a list of the 30 ways in which iTunes still uses DRM. It's not fading.We aren't really winning this argument with the media-consuming public, not even considering the media makers. And look at what is on the horizon. Blue-Ray has much stronger security than DVD ever did. HDMI is a security nightmare, all implemented and waiting for enough saturation before the networks turn the really bad part on.
Over the top
Posted Jun 2, 2009 9:37 UTC (Tue) by paulj (subscriber, #341) [Link]
So on the one hand, you were arguing that the current state of things, with "semi-rigid", easily-circumventable DRM, is preferable to a future-possibility of "hard" DRM, in which free software would be precluded from much content (did I follow you correctly?). Your argument then is that we should honour this semi-rigid DRM because not doing so risks inducing the possible-future.
On the other hand, you're arguing that the bad, possible-future is already developed and in place, just awaiting activation (though, Blu-Ray security is already broken, isn't it?). If so, then this undermines your other argument - the media companies are not waiting to see whether free software will honour their flags or not...
Personally, I think (and I think the poster you responded to may have been trying to make the same point) that it has been shown that DRM will fall by itself. In 2 dimensions:
a) Deployments of DRM will be automatically market-bounded in how restrictive they can be. Media which does not allow customers to engage in common acts will lose out and will either fail, or the rights-holders will have to relent and loosen the restrictions. We have already seen this with iTunes and others, and a general DRM backlash in the industry.
While tech-nerd opposition may have helped spread the word, there is no good reason to think it was free software that was exceptionally involved in this demonstrated backlash, and free-software honouring flags certainly had nothing to do with it..
b) DRM schemes will technically always be flawed and fail. This means the content owners will never be able to fully ring-fence their content.
I just don't see how giving rights-holders a sop of semi-rigid DRM affects either of those dimensions.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Posted Jun 6, 2009 9:24 UTC (Sat) by Kamilion (subscriber, #42576) [Link]
http://www.bmeink.com/A70529/high/bmepb529722.jpg
HDMI's been compromised by the HDFury2.
http://preview.tinyurl.com/hdfury2
Neat little hack, that. They used a laptop TMDS display transmitter chip's
HDMI input paired 3cm from a TMDS receiver chip with a VGA/component
output.
Fully HDMI 1.3 compliant with embedded HDCP keys and CEA861 EDID extension
block! Heh!
Perfect match for the Ambarella A2 chip in Hauppauge's HD PVR to capture
crisp 720p or 1080i straight to h264. Ambarella's A3 chip extends that to
1080p60, or our friendly neighborhood PC resolution of 1920x1080@60hz.
(Can you tell I'm a hardware geek?)
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Posted Jun 6, 2009 16:23 UTC (Sat) by BrucePerens (guest, #2510) [Link]
Well, this is very nice for existing discs, but my understanding was that Blu-Ray had multiple keys, and that they had planned for updates.There is also the prospect of HDMI 2.0. So, I hope we're as lucky in the future.
Over the top
Posted Jun 3, 2009 15:20 UTC (Wed) by nye (guest, #51576) [Link]
What colour is the sky in your world?
Over the top
Posted Jun 3, 2009 21:10 UTC (Wed) by timschmidt (guest, #38269) [Link]
Quite blue most days, but sometimes greyish, and nearly black at night with little sparkly pinpricks of light scattered about. It's quite nice really. You should visit reality sometime and see what it's like! :)
Over the top
Posted Jun 4, 2009 10:33 UTC (Thu) by nye (guest, #51576) [Link]
Over the top
Posted Jun 4, 2009 16:21 UTC (Thu) by timschmidt (guest, #38269) [Link]
Many of my friends and co-workers have used iTunes in the past. Several of them stopped after catastrophic software failure or other calamity in which iTunes DRM keys were lost - preventing access to the hundreds of dollars of music they'd 'purchased'. Of course, when such things happen, these folks come to their friendly local computer guy, and we tend to show them the easiest way to replace all those music files - already bought and paid for - Arrrrr!
And that's how DRM fails - even for normal people.
Over the top
Posted Jun 2, 2009 4:46 UTC (Tue) by 0b11101 (guest, #57638) [Link]
The DCMA says, "No person shall circumvent a technological measure that effectively controls access to a work protected under this title."
And so you say this is not real DRM, but where do you differentiate your real DRM from these broader definitions of DRM ?
Over the top
Posted Jun 2, 2009 5:03 UTC (Tue) by BrucePerens (guest, #2510) [Link]
It's all concerned with usage. If your book library dies entirely if you don't keep your subscription with Amazon current, that's egregious. If something is in place to remind the naive user about copyright, and a knowledgable person can defeat it with a trivial effort, that's less annoying than feeding a parking meter.
Over the top
Posted Jun 2, 2009 5:19 UTC (Tue) by drag (guest, #31333) [Link]
Using DRM to simply provide a way that people can be notified and take intellegent choices is going to be quite a bit different from digitally enforced copyright protection schemes.
Over the top
Posted Jun 2, 2009 5:29 UTC (Tue) by BrucePerens (guest, #2510) [Link]
The difference between coercion and cooperation is a pretty big difference.
Over the top
Posted Jun 2, 2009 5:50 UTC (Tue) by drag (guest, #31333) [Link]
So all forms of DRM are not bad.
Most people think in terms of DRM as 'use encryption to thwart unwanted uses', which, as a concept, is just stupid.
In order to get users the ability to view digital media, they must be able to decrypt it. So people that impliment AACS and such things are, by simple fact of reality, giving their customers everything they need to circumvent the DRM (hardware capable of decrypting, software capable of decrypting, and the decryption keys)
So the only way that sort of scheme really works is through complex obsofcation, deception, lies, and misdirection. They hide as well as they can the actual functioning of the system to try to make it 'secure'. Which, as we all know, security by obsofcation is not the sort of security that can't possible stand up to scrutiny for very long.
So that's 'bad' drm.
The DRM here is just a program looking at the flag in a file and performing a (somewhat backwards) way of notifing the user about the apparent wishes of the person that created the file.
It's open, it's obvious, it depends on people's judgement, it's easy to work around if you have to.
So that's 'good' drm. When a scheme like that is implimented using Free software then it can actually have a positive effect.
I think that is still 'drm' though. Just the type that is actually sane.
Over the top
Posted Jun 2, 2009 16:46 UTC (Tue) by 0b11101 (guest, #57638) [Link]
Any software to toggle this flag?
Posted Jun 2, 2009 5:02 UTC (Tue) by jospoortvliet (guest, #33164) [Link]
You might want to disable the DRM for them in case they can't find it...
Just to be sure :D
Any software to toggle this flag?
Posted Jun 2, 2009 8:16 UTC (Tue) by halla (subscriber, #14185) [Link]
follow the intentions of the pdf author or your own whim on any platform.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 4:01 UTC (Tue) by Trelane (subscriber, #56877) [Link]
The above arguments are a cop-out. It is worth noting, however, that there is a very valid reason for implementing the DRM: patent licenses. Quoth http://partners.adobe.com/public/developer/support/topic_legal_notices.html:Accordingly, the following patents are licensed on a royalty-free, nonexclusive basis for the term of each patent and for the sole purpose of developing software that produces, consumes, and interprets PDF files that are compliant with the Specification:A conforming reader (http://www.adobe.com/devnet/pdf/pdf_reference.html)
A conforming reader shall comply with all requirements regarding reader functional behaviour specified in ISO 32000-1. The requirements of ISO 32000-1 with respect to reader behaviour are stated in terms of general functional requirements applicable to all conforming readers. ISO 32000-1 does not prescribe any specific technical design, user interface or implementation details of conforming readers. The rendering of conforming files shall be performed as defined by ISO 32000-1.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 4:16 UTC (Tue) by jake (editor, #205) [Link]
It seems a bit hard to argue that there is a *legal* basis for choosing to implement the copy bit if a way is also provided to circumvent it. Particularly one that is easily available through the UI.
jake
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 4:26 UTC (Tue) by Trelane (subscriber, #56877) [Link]
GUI copy mode selection is not scriptable, and verified document authenticity
Posted Jun 2, 2009 6:13 UTC (Tue) by tdwebste (guest, #18154) [Link]
From a practical point of view once I sign a document off I do NOT want others to modify that document without some indication.
I currently use git to sign documents off. This works well for me, but takes a bit of explaining for lawyers understand how and why the document's authenticity is verified.
GUI copy mode selection is not scriptable, and verified document authenticity
Posted Jun 2, 2009 8:10 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
A shell script that disables it through the configuration, a KDE-level sccript that works through the GUI to disable it, or whatever.
The "DRM" protection is not reliable and enforceable. If you think it is, please point to such an immutable document for the amusement of the crowd.
BTW: I can still generate a new document with your content (give or take a few minor changes) and re-sign it with my signature. The generated document will have a valid format. If that's all you check you won't get very far.
Okular, Debian, and copy restrictions
Posted Jun 3, 2009 5:22 UTC (Wed) by butlerm (subscriber, #13312) [Link]
nonexclusive basis for the term of each patent and for the sole purpose of
developing software that produces, consumes, and interprets *PDF files* that
are compliant with the Specification"
The above quoted paragraph has nothing to do with the issue at hand. It
doesn't say "produces, consumes, and interprets PDF files in a manner
compliant with the Specification. It says "produces, consumes and interprets
PDF *files* that *are* compliant with the Specification". That is a big
difference.
i.e. if your product reads and/or writes spec-compliant PDF files, you are
fine, but if you purposely generate non-conformant "PDF" files you are not.
What you do with the data once you have read it in is not addressed above at
all.
Okular, Debian, and copy restrictions
Posted Jun 4, 2009 7:17 UTC (Thu) by Trelane (subscriber, #56877) [Link]
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 6:02 UTC (Tue) by sitaram (guest, #5959) [Link]
I think blue is a very nice color, and offsets the green of the woods behind the bike shed.
Seriously, the only possible complaint against Okular devs is what Jon said in a reply to a comment: make it easier for people to find that option.
Many programs have warnings which come up on first use or until you turn them off. Maybe something like that. And in kiosk mode they wouldn't come up, so a corporate deployment can happen.
I'm actually in the position of advocating a corporate deployment of Linux, so I certainly like the default, DRM-hater though I may be at home.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 8:06 UTC (Tue) by nhippi (guest, #34640) [Link]
http://www.foolabs.com/xpdf/cracking.html
> If you think these security protections are a bad idea then write the author of the document. He's the one who set those bits after all.
Indeed, don't shoot the messenger!
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 13:07 UTC (Tue) by rjdymond (guest, #51625) [Link]
"...it would be very hypocritical of me to, on one hand, ask people to honor my licensing restrictions, and, on the other hand, bypass (or assist others in bypassing) another author's requested restrictions."
But this is a flawed argument, because the xpdf author's licensing restrictions (GPL) are not the same as the document author's requested restrictions (no copying, printing. etc.). It's not hypocrisy if I ask you not to smoke in my house, but then eat doughnuts in your house against your express wishes. You could argue that it's inconsiderate, but how much that matters has to be weighed against the reasonableness of the requested restriction. I imagine most people here would agree that the GPL's restrictions are reasonable, but that trying to prevent someone from copying text from or printing a PDF is just dumb.
The xpdf author also says:
"In addition to all of this, Adobe requires that implementors of the PDF spec adhere to the document permissions."
But as has already been pointed out, blindly following a spec just because it's a spec is also dumb.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 14:01 UTC (Tue) by halla (subscriber, #14185) [Link]
a PDF."
There is no need to justify that -- whether the restrictions are justified or not is not the point at all.
" I imagine most people here would agree that the GPL's restrictions are reasonable, but that trying
to prevent someone from copying text from or printing a PDF is just dumb."
Yes, and in other places, most people would agree that the GPL's restrictions are just dumb. Just
because you make GPL software and don't produce encrypted PDF's makes you right in feeling that
you need to enforce the one and discard the other; because if you have that right, then anyone else
has the same right to make their own judgment calls. And use your GPL'ed code in their proprietary
applications.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 8:09 UTC (Tue) by aigarius (subscriber, #7329) [Link]
'Protected' PDF files do exist
Posted Jun 2, 2009 8:37 UTC (Tue) by epa (subscriber, #39769) [Link]
the real problem is that people are downloading PDF files with restrictions in the first placeMeanwhile, in the real world, such PDF files continue to exist, and people quite reasonably expect to exercise their fair use / fair dealing rights.
Perhaps free PDF-generating software by default should turn on the restriction flags, to encourage use of uncrippled PDF readers. That would also negate the argument that only 'hackers' (bad! boo!) would want to copy and paste text from a PDF that has the no-copy flag set.
At the very least, instead of 'forbidden by DRM' the message should say 'this operations is forbidden; to turn off this restriction go to Options->Whatever...'.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 11:32 UTC (Tue) by sergey (guest, #31763) [Link]
think of the flag that disallows saving of a tagged PDF (a form with fields where users can enter
data) with user entry embedded in it? Should a free software program force users to lose what
they entered, if the document publisher chose to enable this flag? I hope not (even though last
time I tried Evince failed to save field values unconditionally).
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 12:06 UTC (Tue) by knan (subscriber, #3940) [Link]
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 12:10 UTC (Tue) by halla (subscriber, #14185) [Link]
* it is demanded by the standard
* there are users who need these bits
* it is a basic courtesy towards the content generators to abide by their license, just as we expect
others to abide by our licenses.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 12:34 UTC (Tue) by knan (subscriber, #3940) [Link]
It's none of the standards business. Those flags can never be more than advisory.
* there are users who need these bits
Default to off, let them turn it on. Kiosk mode. Don't inconvenience everyone.
* it is a basic courtesy towards the content generators to abide by their license, just as we expect others to abide by our licenses.
So if I write in my document that you need to wear a pink fedora while reading it, you'd want a program to enforce that by default? It's silly. Let the reader decide whether what the author demands is acceptable or not.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 13:06 UTC (Tue) by halla (subscriber, #14185) [Link]
You wanted to know the reasons: these are the reasons, so now you know the reeasons.
You may disagree with the authors of okular and xpdf, but, well, your disagreement is irrelevant. You're not doing the work, nor are you adding any well-considered well-formulated opinion, you are merely playing dummy and were asking a rather fatuous rhetorical question, to which you now have the answer.
And that's what you'll have to live with.
(And, of course, you should realize the complete equivalence of " Let the reader decide whether what the author demands is acceptable or not." and "Let the developer decide whether what the library author demands is acceptable or not", and that you have just given everyone a free pass on license violation of all the software you have ever written. If any.)
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 14:04 UTC (Tue) by sergey (guest, #31763) [Link]
> You wanted to know the reasons: these are the reasons, so now you know the reeasons.
This is a very poor reasoning, especially in the light of "standards" such as OOXML.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 14:18 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
http://www.coker.com.au/selinux/play.html
I'm quoting from it:
> To access my Debian play machine ssh to
> play.coker.com.au as root, the password is
[password ommited]
> I give no-one permission to distribute
> this password. If you want to share
> information on this machine you must
> give the URL to this web site
I'm not completely sure that the password here is long enough to be protected by copyright, but even if it isn't, it's easy to make a similar example that is enforceable. Thus I could have easily used my browser using my browser to circumevent the license of that page. But out of respect to the author of that page I avoid that.
In fact, most common browsers include functionality such as "send page" and that help you violate copyright licensing and easily publish the results. The sky is not falling, AFAIK. The internet is alive and kicking.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 14:29 UTC (Tue) by rjdymond (guest, #51625) [Link]
(And, of course, you should realize the complete equivalence of " Let the reader decide whether what the author demands is acceptable or not." and "Let the developer decide whether what the library author demands is acceptable or not", and that you have just given everyone a free pass on license violation of all the software you have ever written. If any.)You seem to be saying that if I choose to ignore/violate the licence restrictions on somebody else's work, then I am (morally?) obligated to allow others to ignore/violate the licence restrictions on my own work(s). Which is entirely wrong, because it doesn't take the details of the licences into account. Whether violating licence A is as acceptable as violating licence B surely depends on those details. (And yes, the answer will be a matter of opinion, but that's beside the point.)
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 15:32 UTC (Tue) by halla (subscriber, #14185) [Link]
If you're not prepared to do that, you forfeit the other's consideration for you.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 16:39 UTC (Tue) by rjdymond (guest, #51625) [Link]
Yes, I'm saying that you should behave unto others as you would like them to behave towards you.
At the risk of sounding like a broken record, behaving unto others as you would like them to behave towards you (which is a good idea that I can agree with) does not imply abiding by someone else's licence because I expect them to abide by mine. To suggest it does is to render the fine phrase meaningless. To translate into the narrow realm of licences:
Yes: You should comply with the GPL (on somebody else's work) if you expect others to comply with the GPL (on your own work).
No: You should comply with an absurdly restrictive licence (on somebody else's work) if you expect others to comply with the GPL (on your own work).
Again, the devil is in the details (of the licences).
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 18:59 UTC (Tue) by halla (subscriber, #14185) [Link]
No, your personal interpretation of the relative importance and
reasonableness of the restrictions imposed by a content creator aren't
absolute values. What you think is reasonable might be unreasonable in the
eyes of another. And you haven't got any right to force the other into
giving up their position. And that's the problem: you are demanding that
people who have a more reasonable position (by default we do the right
thing, but people can override that) than you give up that position.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 19:59 UTC (Tue) by nybble41 (subscriber, #55106) [Link]
Personally, I think the entire discussion is pointless. Enforcing copyright claims through coercion is both immoral (IMHO, though that classification is far from arbitrary) and ineffectual, and claiming copyright sans coercion is simply ineffectual. Better to just accept reality and move on.
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 16:54 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
Does it imply I'm allowed to freely distribute anything that is not protected by technical measures? Such as standard GPLed code?
Okular, Debian, and copy restrictions
Posted Jun 4, 2009 1:31 UTC (Thu) by JoeF (guest, #4486) [Link]
They are also "demanded by the standard".
There are also "users who need these bits"
It is also "a basic courtesy towards the content generators"
Yet, the browser pops up a dialog asking what to do with the cookie.
Okular, Debian, and copy restrictions
Posted Jun 4, 2009 10:37 UTC (Thu) by nye (guest, #51576) [Link]
Okular, Debian, and copy restrictions
Posted Jun 6, 2009 19:31 UTC (Sat) by Hawke (guest, #6978) [Link]
Okular, Debian, and copy restrictions
Posted Jun 11, 2009 12:17 UTC (Thu) by oblio (guest, #33465) [Link]
Okular, Debian, and copy restrictions
Posted Jun 2, 2009 22:36 UTC (Tue) by gmaxwell (guest, #30048) [Link]
It's very useful to know that a file has restrictions, and some people may appreciate the reminder that copying from the file is unwelcome and may be a violation of the law depending on the specifics of the situation.
Okular, Debian, and copy restrictions
Posted Jun 3, 2009 4:27 UTC (Wed) by dkite (guest, #4577) [Link]
choose to ignore what the author wanted and expressed when they created
the item, it is my risk.
One occasion comes to mind. A PDF for a specific purpose where having a
printed copy (laminated) is the only practical use. It had extensive no
printing protection that no pdf reader could overcome. Printing the screen
worked just fine, and we are proud and happy users of the information in
the format we required.
That was my choice. If the author of the document wants to sue, they can
sue me.
I don't expect the authors of the software to take that risk for me. How
we forget. Dmitry Sklyarov spent time in jail when he exposed the flaws in
Adobe's forgotten scheme. Adobe eventually even opposed the prosecution
(probably to attempt to foil a revolt among their developers). Not a
pleasant situation to be in.
So if you want to be a poster child for fair use rights, fight in court
and make law, great. Maybe the authors of Okular don't want to do that.
Fine with me.
Derek
Okular, Debian, and copy restrictions
Posted Jun 3, 2009 18:05 UTC (Wed) by tzafrir (subscriber, #11501) [Link]
Stretching your logic a bit further, the pop-up blocker of Firefox would be "dangerous" - the site wanted you to see a pop-up as part of the document. Who are you to decide the pop-up is not relevant? Who are you to use technical workarounds to prevent the starving author from receiving his due funding?
Okular, Debian, and copy restrictions
Posted Jun 4, 2009 0:39 UTC (Thu) by ncm (guest, #165) [Link]
admonition systems
Posted Jun 4, 2009 1:43 UTC (Thu) by zooko (guest, #2589) [Link]
This would be a nice solution to the dilemma of okular -- when an action is attempted that is not allowed by the drm bits, okular could open a dialog box saying "The author of this file has requested that you not copy text from it. The current setting of okular is to disable the copy feature when the author has made such a request. If you wish to enable the copy feature despite this request, please see "Settings > configure okular > obey drm".
Compromise
Posted Jun 8, 2009 20:39 UTC (Mon) by kevinbsmith (guest, #4778) [Link]
I read (much of) the bug thread, and see that JohnG (the original bug reporter) did agree to the compromise of having an advisory dialog with instructions for how to disable the feature. The KDE maintainer (Ana) said no, and actually explained why doing this would be somewhat difficult technically, at the package maintainer level.
So in my mind this compromise clearly should be pushed upstream. Oddly, neither the Okular user web page, nor the Okular KDE web page seem to have any links to any sort of bug tracker. So I can't tell what the upstream developers may have said about it.
If a reasonable effort has been made to persuade upstream to compromise, then I guess I would favor Debian taking action. The most reasonable technical action seems to be disabling the option by default. However, the maintainers disagree with that. I'm no Debian expert, but that seems to leave two options: Live with it, or create an alternative package with new maintainers.
It's frustrating when an issue like this is painted in stark black and white, when in reality there seems to be a very reasonable compromise available...and when some folks on each side seem uninterested in being reasonable.
Compromise
Posted Jun 8, 2009 21:23 UTC (Mon) by halla (subscriber, #14185) [Link]
And, of course, it's bugs.kde.org, which is the place where all KDE
applications track their bugs.
Never reported upstream?
Posted Jun 8, 2009 22:51 UTC (Mon) by kevinbsmith (guest, #4778) [Link]
I checked bugs.kde.org and couldn't find any bug report for this issue. Perhaps I missed it somehow. If not, hopefully someone will create one. Seems like that should have been the first step when the Debian maintainers marked the issue as wontfix.
Never reported upstream?
Posted Jun 9, 2009 7:43 UTC (Tue) by halla (subscriber, #14185) [Link]
all over the internet in search of a bug tracker, since you don't know what a bug tracker is.
You, Kevin, are not an ordinary user. You are posting comments on lwn.net, you know what a bug
tracker is, you know that Okular belongs to KDE. Of course you are not really so ignorant that you
cannot think of going to http://www.kde.org and see find the link that is clearly marked "Bug
Database".
Never reported upstream?
Posted Jun 9, 2009 12:35 UTC (Tue) by kevinbsmith (guest, #4778) [Link]
As for thinking to look on kde.org: I was curious about Okular, not KDE (I assume is possible to run one without the other, as with other KDE apps). It honestly didn't occur to me to look on the KDE site. Apparently I'm more ignorant than I thought
And sure, I don't really matter because I'm not (yet) an Okular user. Clearly the best response to my suggestion for how to improve the site, as well as my suggestion for a possible way to resolve the frustration of many users while also fixing a public relations problem, is to insult me. Ok. If that's how the Okular/KDE communities wish to be represented, so be it.
Never reported upstream?
Posted Jun 9, 2009 13:08 UTC (Tue) by halla (subscriber, #14185) [Link]
You know, normal people don't feel the need to "evaluate" the community before installing an application, especially not "including the bug reports". That alone marks you as Not a Normal User, but someone who can be expected to be a little more flexible and knowledgeable. And no, that is not an insult either. (And if Okular crashes on startup, you also get a nice window that helps you file a bug report.)
If you really had wanted to make a suggestion instead of scoring a silly little point at the tail of a silly discussion on a news website, you could have, like, contacted the Okular team directly. There is quite a prominent link on their website to http://okular.kde.org/contact.php, which gives you plenty of ways to contact them and ask them to add a link to bugs.kde.org.
So, you could, very easily, have made just this little suggestion of yours, without resorting to phrases like:
" Oddly, neither the Okular user web page, nor the Okular KDE web page seem to have any links to any sort of bug tracker. So I can't tell what the upstream developers may have said about it."
Because it isn't odd -- it's just an oversight, most KDE applications don't have a link to the bug database because that's in the application menu. It is seldom needed. But it didn't make it impossible for you to figure out what the upstrream developers might have said about, because a) there have been links to their opinion as expressed in blogs and b) you could easily have reached them because the means to do so are prominently displayed on the okular website.
Never reported upstream?
Posted Jun 12, 2009 6:41 UTC (Fri) by k8to (guest, #15413) [Link]
> community before installing an application, especially not
> "including the bug reports". That alone marks you as Not a Normal
> User, but someone who can be expected to be a little more flexible
> and knowledgeable.
I recognize that you are not trying to be insulting by insisting that people such as me who do this are abnormal. However, you are being insulting.
There's nothing wrong with researching something you're going to invest in. It is a matter of thoroughness, care, attention to detail, and of course interest and available time, rather than normality or the lack thereof.
Whta's the difference between this and robots.txt?
Posted Jun 4, 2009 12:49 UTC (Thu) by euske (subscriber, #9300) [Link]
BTW, I'm personally against the idea of this "extraction protection" bit because this poses a serious information barrier for users who are visually impaired and access to PDF documents via voice synthesis (later Adobe added an "exception for blind people" bit, but it's far from perfect). Still, I had to implement this dreadful thing when I published the software. Am I missing something?
Whta's the difference between this and robots.txt?
Posted Jun 4, 2009 20:00 UTC (Thu) by ncm (guest, #165) [Link]
The difference is that copying and pasting from a pdf is done by an individual, who can be presumed to be equipped to make the decision whether the flags reasonably apply in each case. robots.txt is read by automated programs, and is obeyed mainly because crawlers wouldn't work if they ignored it.
Whta's the difference between this and robots.txt?
Posted Jun 5, 2009 10:34 UTC (Fri) by euske (subscriber, #9300) [Link]
Think about it: Most people respect a "private" sign in the real world when there's no physical obstacle, so we don't have to spend huge money on security. If everyone starts ignoring these "soft" restrictions by their own discretion, the world would become much worse. Originally Adobe created this because their customers want it. But I'm pretty sure companies like Adobe might be eventually going to impose much more strict, heavy and technically ill-formed DRM scheme when the content providers demand, no matter how ridiculous or broken the idea is.
My only gripe is that the whole mechanism was made and spread by a single company without much consideration or democratic discussion, and nowadays it gets so important. But sadly, that's how most of today's format standards were created.
Whta's the difference between this and robots.txt?
Posted Jun 5, 2009 15:45 UTC (Fri) by foom (subscriber, #14868) [Link]
Think about it: Most people respect a "private" sign in the real world when there's no physical obstacle, so we don't have to spend huge money on security.
Taking that analogy further:
If you know you have the permission to enter the property marked "Private", you don't have to wait for the owner to come over and take the sign down before doing so. You can just do it.
If you are crossing into the land for innocent purposes (e.g. it's a shortcut to where you're going and the land is unused, so what's the harm?) you might make the decision to enter despite it being marked private. And often that'll be fine, because likely nobody will know, and nobody was harmed.
Think about it. Even when there's a chain-link-fence around some unused land (one step up from a sign on the border), how often have you seen holes in it for people to walk through? At least around here that's quite common.
Both externally-granted permission and innocent infringement are quite common with software, as "in the real world". I've certainly run into both situations personally with copy-inhibited PDFs.
Whta's the difference between this and robots.txt?
Posted Jun 6, 2009 5:34 UTC (Sat) by euske (subscriber, #9300) [Link]
Okular, Debian, and copy restrictions
Posted Jun 11, 2009 10:42 UTC (Thu) by Janne (guest, #40891) [Link]
If free software-folks stopped nitpicking and complaining about minor
licensing-issues and related topics, free software would utterly dominate
the world by now.
But no, what happens is that time and energy gets wasted on pointless
arguments. Software gets forked and unforked, resources get wasted and
developers have to waste their time listening to users who whine "But I
don't want to invest 10 seconds of my life to changing that setting, I want
you do to it for me!".
And there's one thing that amazes me: Basically this discussion has been
about "I should be able to do whatever I please with the content,
regardless of the wishes of the creator!". Now, assume the person saying
that comment was Steve Ballmer, and the content he was referring to, was
GPL'ed software, everyone would be up in arms. But now that it's US who is
making that claim, everything is apparently a-OK....
Okular, Debian, and copy restrictions
Posted Jun 16, 2009 14:54 UTC (Tue) by zenaan (guest, #3778) [Link]
This is an "information-age right". It appears there are some humans who believe this right either does not exist, or ought be restricted by some heavy hand of law or government or community. I find that strange, but c'est la vie.
In this case of Okular, this absolute-right-over-my-computer is 'functionally' acknowledged with the badly named and mildly obfuscated "DRM" preference option.
My datapoint: The current default for this option in Debian does not match my understanding of the Debian Social Contract nor my expectations for the Debian GNU/Linux distribution.
The "provide dialog option to disable, on first occurrence" is acceptable to me.
I actually like to know about the expectations and/ or license of a document producer/ document, and would appreciate having some GUI feature(s) which makes this information readily available to me.
My position is: either:
a) the Debian Social Contract must change,
b) the default for Okular "DRM" option in Debian must change, or
c) Okular must be 'enhanced' to provide opt-out on first hit, and/ or other GUI enhancements.
If the Okular devs/ Debian packagers are trying to make a point, they're not doing it in the most elegant way at the moment, emphasizing the utility of this article by Corbet - highlighting that there is in fact an issue.
I heartily agree.
Community introspection is a very important thing. Also highlights that we are indeed a community! Happy joy...
tar, ext4, root
Posted Jul 4, 2009 18:25 UTC (Sat) by ChrisDolan (guest, #41017) [Link]
And that ext4 filesystem, man! It always says "Permission denied" when I try to "rm -r /". We gotta rip that antifeature out of Linux.
And the root account? What's up with that? All accounts should be created equal! Root is the Man. Debian should eliminate the root account, or at least disable the limitations of all other accounts by default. Why do they make "sudo chmod -R 777 /" so obscure?