Weekly Edition
Return to the Front page
| |||||||||||||
Okular, Debian, and copy restrictions
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.
John Goerzen encountered this behavior in Debian's Okular package; suffice to say he was not pleased. He filed a bug and asked:
So what I want to know is: why are people putting code into Debian
that limits our freedom? Why are people putting such code into KDE?
And can we please patch it to stop that? 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:
If tomorrow a corporate person complains that Okular does not
respect the PDF format in that sense and that they cannot make use
of it because of that, what should I tell them? They would be
right. Look, having the "power of developers" does not imply
developers should feel like crackers, disabling restrictions just
because they can or in the name of some "freedom".
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 (subscriber, #4723) [Link]
It should be an easily switchable option, like we are used with file write, read, execute protections. Those worried to extract text by mistake from a protected pdf file would then be protected from themselves, and those wanting to override the protection because they are entitled to (like the authors, or an authority), would not be limited.
Okular, Debian, and copy restrictions Posted Jun 1, 2009 21:36 UTC (Mon) by drag (subscriber, #31333) [Link]
Yeah. That makes sense to me.
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 (subscriber, #33164) [Link]
Agreed. This feature isn't very useful for casual home usage, but for
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
I also don't understand why mr Corbet does not mention how easy it is to
Okular, Debian, and copy restrictions Posted Jun 3, 2009 16:35 UTC (Wed) by jospoortvliet (subscriber, #33164) [Link]
can't edit the comment, so: I didn't notice Corbet mentioned the posibility of turning it off...
Okular, Debian, and copy restrictions Posted Jul 1, 2009 3:10 UTC (Wed) by ggw (guest, #59386) [Link]
What have you been smoking Superstoned? Here is the last sentence of the
third paragraph.
"There is a configuration option which disables this behavior, but the
Okular, Debian, and copy restrictions Posted Jun 5, 2009 7:44 UTC (Fri) by liljencrantz (subscriber, #28458) [Link]
This seems completely backwards to me. The very, very small number of organizations with specific reasons to limit their users freedom can update the system defaults to enforce these limitations, and let the other 99.9 % of humanity, including all sane corporations, to get on with their lives. Why on earth should the default value cater to a microscopic subgroup instead of the broad masses, when that subgroup can actually change the default for themselves?
Okular, Debian, and copy restrictions Posted Jun 1, 2009 21:38 UTC (Mon) by ana (subscriber, #41598) [Link]
There is not restrictions when you can turn them off.
Anyway:
Okular, Debian, and copy restrictions Posted Jun 1, 2009 22:07 UTC (Mon) by johnflux (subscriber, #58833) [Link]
That's exactly what okular does. You can simply turn off the restrictions.
Okular, Debian, and copy restrictions Posted Jun 1, 2009 22:35 UTC (Mon) by elanthis (guest, #6227) [Link]
Is it really "simply" or is it "through a series of arcane steps" ? I'd imagine the best bet would be a checkbox-menuitem in the Edit menu, two clicks away at most and in a fairly obvious place.
(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]
Settings (menu) > configure okular (Dialog box) > obey drm (Checkbox) > ok (Button)
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 (subscriber, #31018) [Link]
Yeah, why don't Debian just provide a conf file with the option checked out?
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]
*sigh* does nobody read the article anymore?
Okular, Debian, and copy restrictions Posted Jun 2, 2009 15:01 UTC (Tue) by rvfh (subscriber, #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]
Did some people come over from Slashdot? It is common there to comment without reading TFA...
Useless denigrating comments Posted Jun 4, 2009 7:09 UTC (Thu) by rvfh (subscriber, #31018) [Link]
Really? I didn't know: never been on /.
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]
Or don't use Okular if it annoys you too much each time you have to use it on a new system. Evince does not have this problem. Likewise xpdf.
Okular, Debian, and copy restrictions Posted Jun 2, 2009 15:18 UTC (Tue) by engla (guest, #47454) [Link]
Not so simple, this wouldn't be an issue if:
1. Most users would realise there was an option
Okular, Debian, and copy restrictions Posted Jun 1, 2009 21:37 UTC (Mon) by asdlfiui788b (guest, #58839) [Link]
Indeed, I believe that compliance to standards while allowing standards to be ignored when they infringe on freedoms are the PERFECT way to go about this issue.
This is not like the Windows NT server/workstation issue where the more expensive software is simply crippled.
This is a situation where an open standard allows for user-removable copy-restrictions to be easily lifted.
I say hoorah for okular's decision to include this functionality by default.
This is a FEATURE, not a "FEATURE".
up-side Posted Jun 1, 2009 23:34 UTC (Mon) by ncm (subscriber, #165) [Link]
It's a "feature" that leads me to see no reason to install okular knowing that evince is not similarly broken. I notice that DVD players that obey region coding and restrictions on skipping FBI notices are distinctly missing from repositories, for identically the same reason. DVD player boxes that have been identified as easy to modify so as to remove these misfeatures are more appealing to buy, so much so that manufacturers make a point of releasing the necessary details.
It's obvious to me that Debian's rightful course is to flip the default on this program, and further to issue a slap up-side the collective head of those arguing otherwise. It would not be wrong to have it post a marginal icon advising users that the document originator had sought to restrict their use of it.
up-side Posted Jun 2, 2009 1:30 UTC (Tue) by ncm (subscriber, #165) [Link] I have now read the Debian bug report thread, and have learned that the KDE maintainers are unanimous in opposing any sort of fix for this bug.It appears the only choices remaining are: (1) Fork the project, and upload a new package "okular-free"; (2) Initiate a vote to override the package maintainers directly; (3) Initiate a vote to change the project charter so that the repository maintainers are obliged to override the package maintainers' misguided notions. Probably the last is ultimately the right course. I wonder what project these package maintainers think they are working in. Their unanimously bad judgment makes me disinclined to try KDE programs.
up-side Posted Jun 2, 2009 4:57 UTC (Tue) by jospoortvliet (subscriber, #33164) [Link]
I don't get the issue. It is incredibly easy to turn it off - so home
users won't have a problem with it. Meanwhile for certain corporations it is crucial for legal reasons. What's the problem?
up-side Posted Jun 3, 2009 1:37 UTC (Wed) by akumria (subscriber, #7773) [Link] Meanwhile for certain corporations it is crucial for legal reasons.Feel free to provide a link to some evidence with your rhetoric.
up-side Posted Jun 3, 2009 10:07 UTC (Wed) by jospoortvliet (subscriber, #33164) [Link]
Ok, you want a real example so here you go.
I've worked at KPN, the dutch largest telecom provider. The government has mandated the company to kind'a split it's operations off from the sales. The reason is that KPN has both network & services. The goverment has forced it to open up it's network, so other providers can compete with KPN on services.
To prevent any unfair competition, operations is not allowed to tell all it knows to headquarters (for example numbers about marketshare, revenue, growth, prices etc from competitors).
This division is rather dificult to maintain - obviously, as it is still ONE company. But the fines by the OPTA (goverment agency overviewing and checking KPN and other companies in the telecom area) are easily in the millions, so there is quite some pressure.
DRM, among other technologies, is used to keep certain employees from certain information. Even IF you send a doc to someone 'on the wrong side' they won't be able to open it. Or can only see but not print etcetera.
How's that for evidence with my rhetoric. I think a person (which includes a legal person like a company) should have every right to enable and enforce DRM on his/her/their own hardware and software. It's perfectly valid, legal and morally right. Imho.
up-side Posted Jun 3, 2009 11:00 UTC (Wed) by mbanck (subscriber, #9035) [Link]
The point is that the okular problem is not about DRM (even though it is worded as such in the GUI). What we are talking about is advisory locking - the PDF has a bit set and the standard says what should happen; however there is no encryption or anything going on.
You can print the PDF, you can copy the PDF, you just cannot copy&paste if the application honors the bit. So I don't see how this pertains to your KPN example (which might be a valid example for DRM or not, I will not judge on that).
Michael
up-side Posted Jun 3, 2009 12:34 UTC (Wed) by sepreece (subscriber, #19270) [Link]
It means that, if applications implement the standard correctly, an individual can't ACCIDENTALLY copy information from the document or print the document. That gives the company deniability and shifts the liability for violations to the individual who broke the rules.
This is important to many companies. My previous employer often set the no-copy/no-print flags on PDFs that were covered either by internal distribution restrictions (e.g., registered company secrets) or external restrictions (documents received from third parties with restrictions).
The point isn't to make it impossible to copy (they would love to do that, but recognize that it's impossible in an era when every mobile has a camera can take screenshots), but to make it obvious to people when they are breaking the rules.
up-side Posted Jun 4, 2009 1:09 UTC (Thu) by JoeF (guest, #4486) [Link]
A non-sequitur.
DRM to prevent opening or reading a file has absolutely nothing to do with this issue.
This issue is about copying only. And preventing copying is, at least for text, simply impossible. If somebody wants to copy the text, the person can always re-type it. Even for diagrams, I can just take a screenshot.
up-side Posted Jun 4, 2009 11:57 UTC (Thu) by jospoortvliet (subscriber, #33164) [Link]
Point is that preventing copying like this works just fine in most cases. Especially if you know (like in the example I gave) that you're not allowed to try to circumvent it. This is like a 'soft DRM' function. Pretty easy to circumvent, but that's no problem. Inconvenient is good enough here.
Anyway, you think the functionality is useless. I think it has it's usecases. You should ask Adobe why they wrote it, and the companies using it why they do that, not me.
up-side Posted Jun 2, 2009 7:33 UTC (Tue) by rvfh (subscriber, #31018) [Link]
Why patch/fork the program when you can just set an option!?!
up-side Posted Jun 4, 2009 0:21 UTC (Thu) by ncm (subscriber, #165) [Link]
Simple: because the package maintainers whose job it is to set the option default correctly have refused to do so.
up-side Posted Jun 2, 2009 6:02 UTC (Tue) by amit (guest, #1274) [Link]
With DVDs, there might be an issue with you not being able to view a DVD you bought on a trip somewhere in your DVD player. You certainly don't want that kind of a behaviour. On the other hand, okular's only forbidding you to copy some text from the pdf when it's marked as such. That's way different from not being able to view the pdf at all. So comparing these two isn't a good analogy.
up-side Posted Jun 2, 2009 16:33 UTC (Tue) by joey (subscriber, #328) [Link]
PDF flags can also prevent PDFs from being printed, which is perhaps more analagous (many PDFs can't be fully used without being printed out).
Evince and others readers used to honor those flags but have been fixed to ignore them. I wonder what Okular does?
Okular, Debian, and copy restrictions Posted Jun 1, 2009 21:39 UTC (Mon) by atai (subscriber, #10977) [Link]
"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."
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]
Free software authors write software to use it, just like the other users of that software would -- while proprietary companies create software to sell it. Note the distinction.
Okular, Debian, and copy restrictions Posted Jun 2, 2009 7:43 UTC (Tue) by rvfh (subscriber, #31018) [Link]
My thought exactly. Free Software motto seems to me to be more like "if you want something done, do it yourself".
Okular, Debian, and copy restrictions Posted Jun 1, 2009 21:40 UTC (Mon) by madcoder (subscriber, #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 (subscriber, #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 (subscriber, #30027) [Link]
Actually no I meant John (Goerzen) the Debian Developper who started the whole thing, not our angry editor :)
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. The PDF spec allows setting these flags and the PDF viewer should enforce the use of those flag. If someone has created content that sets these flags to restrict what you can do with the content, that's a problem with the content, not the viewer. Okular needs to continue to honor those flags. It would be hypocritical of us to expect people to honor our wishes (or licenses that we use for free software) yet not honor the wishes of those who choose to restrict their content.
Okular is doing the right thing Posted Jun 1, 2009 22:20 UTC (Mon) by tzafrir (subscriber, #11501) [Link]
Expected result: users will automatically disable this configuration and disrispect the limitation as before.
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]
And then there's the hard way: actually distribute PDF files that have such annoying DRM limitations but no licensing issues whatsoever. This should be done in order to encourge users to use PDF viewers that that ignore those limitations (e.g.: in the case of KPDF/Okular: disable that configuration item, for win32 users: use e.g. Sumatra PDF (untested)).
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]
There is a subtle point here that I think you are missing about license restrictions and the enforcement thereof.
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]
> There is a subtle point here that I think you are missing about license
> 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
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]
> "Implementing the spec as designed" is not an excuse for putative bad
> 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
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
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 (subscriber, #165) [Link]
Fair Use does not mean convenience. Free Software means convenience. Artificially enforced inconvenience is incompatible with the Free Software ethos. If you don't like what Free Software is about, what are you doing here?
Is Okular doing the right thing? Posted Jun 2, 2009 21:51 UTC (Tue) by sepreece (subscriber, #19270) [Link]
Free software means you, as the user of the software, can do what you want - you can set the configuration option or you can rebuild the package to change default, just as you can decide that it's inconvenient that cp observes the system access rules and change it so it lets you copy files regardless of the permission bits, assuming it's a system that you can install your own kernel on.
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 (subscriber, #165) [Link]
I'm not talking to the Okular developers. They can do whatever the hell they want, and it's none of my business. I'm talking to the Debian maintainers of the Okular package, who signed an agreement to abide by the Debian Social Contract. These package maintainers are catering to people who are not members of the Debian community at the expense of people who are, in violation of that Contract.
Is Okular doing the right thing? Posted Jun 3, 2009 23:28 UTC (Wed) by sepreece (subscriber, #19270) [Link]
I don't think there's anything about the default setting of the Okular option that "violates the Debian Social Contract" or violates the DFSG, unless there's a lot of understood subtext that I'm not aware of as an outsider. The software is, to the best of my knowledge, appropriately licensed, modifiable, and redistributable.
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]
"I work for a medical device manufacturer and we restrict the copying of text and printing of PDFs of our standard operating procedures"
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"?
Is Okular doing the right thing? Posted Jun 6, 2009 1:24 UTC (Sat) by pjm (subscriber, #2080) [Link]
The word "enforce" is in general somewhat ambiguous about to what extent the object is absolutely obtained (see the variation in meanings given by a dictionary), but the post to which JoeF replies already makes clear (in more than one paragraph) that its author is aware that the software does not absolutely prevent copying.
(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 (✭ supporter ✭, #5246) [Link]
I personally see this as being equivalent to a courtesy lock on a bathroom in a house. By default, if someone clicks the button on the knob, anyone else trying to enter the bathroom cannot, because the knob won't turn. But, grab a toothpick and "pop", the doorknob is unlocked.
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 (subscriber, #19270) [Link]
I would probably phrase the statement more like "The author has indicated that this document has restricted circulation and may not be copied." And the two action buttons would the be "Cancel" and "I have the author's permission to proceed."
Is Okular doing the right thing? Posted Jun 3, 2009 15:25 UTC (Wed) by Los__D (guest, #15263) [Link]
Err, no.
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 (subscriber, #19270) [Link]
I'd be perfectly happy with "Proceed anyway" ;-)
Is Okular doing the right thing? Posted Jun 11, 2009 6:13 UTC (Thu) by huaz (guest, #10168) [Link]
> "Implementing the spec as designed" is not an excuse for putative bad
> 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]
>> Is it okay for a tool to attempt to enforce usage restrictions?
>Yes, because the flags for said usage restrictions are part
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]
> 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.
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
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]
> > 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
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 (subscriber, #19270) [Link]
Again, I think you're overstating your preferred option as "the only tolerable option".
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]
"Again"? This is your first reply to me in this thread.
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]
What makes you believe I am arguing that software developers and distributors have an obligation to serve their users? For various reasons, Debian developers WANT to serve their users. Their discussion, and the one happening here, is about how best to do that. Congratulations on noticing that getting everything right for everyone out the box is impossible. Please join the conversation AFTER you've figured out that this does not rule out getting as much right for as many people as possible.
Okular is doing the right thing.mostly. Posted Jun 3, 2009 13:23 UTC (Wed) by sepreece (subscriber, #19270) [Link]
Sorry, the "Again" was ill-chosen, I was reemphasizing someone else's point, not my own, and should have expressed that more clearly.
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]
And as part of that lock down, to make it effective, other parts of the operating system would have to interpret the pdf flags so that the document itself could not be copied off the device onto removable storage or over the network to another device where the flags were not respected. Effective lock-down is very hard to do unless the entire system is designed for it.
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 (subscriber, #19270) [Link]
The common use of the "No copying" flag is corporate. The documents I've seen with copying disabled have usually been either proprietary corporate documents, marketing materials that weren't authorized for release, yet, and materials received from a third-party under NDA.
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 (subscriber, #50638) [Link]
How does the "No copying" flag work with "cp"?
Okular is doing the right thing. NOT. Posted Jun 3, 2009 12:45 UTC (Wed) by sepreece (subscriber, #19270) [Link]
It has no interaction with "cp", it just disables the ability to take snips out of the document. The expectation is that people are more likely to leak a paragraph than a whole document (in part because the whole document is more likely to identify who it was sent to) and that it avoids the possibility of quotes being taken out of context.
Okular is doing the right thing. NOT. Posted Jun 4, 2009 1:20 UTC (Thu) by JoeF (guest, #4486) [Link]
"it just disables the ability to take snips out of the document."
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.
Okular is doing the right thing. NOT. Posted Jun 4, 2009 14:28 UTC (Thu) by sepreece (subscriber, #19270) [Link]
Agreed, and that's clear in other comments I have made in this strand - it disables the ability to take snips out of the document without overriding the restriction.
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 (subscriber, #755) [Link]
Precisely. The point is to make it necessary for you to testify that you turned the protection off in order to copy the data.
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]
What you said makes sense apart from your choice of words 'criminal activity' when you mean very minor copyright infringement.
That's our Chandler allright Posted Jun 2, 2009 18:41 UTC (Tue) by ikm (subscriber, #493) [Link]
> It would be hypocritical of us to expect people to honor our wishes (or licenses that we use for free software) yet not honor the wishes of those who choose to restrict their content.
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 (subscriber, #58833) [Link]
The Okular developers spent a long time trying to get this right, and imho have a great solutions.
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 (subscriber, #39279) [Link]
I'd imagine that having it on by default is also a CYA move in case anyone ever tried to come after them.
Okular, Debian, and copy restrictions Posted Jun 2, 2009 0:17 UTC (Tue) by bjacob (subscriber, #58566) [Link]
I can't believe that I just paid for a 6 month subscription to LWN, only to read this.
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]
And to clarify: the article does briefly mention that "there is a configuration option" but the above comments show clearly that this wasn't done prominently enough and that the article left the readers with the wrong impression.
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]
First off, thanks for replying.
> 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 (subscriber, #165) [Link]
I found the story extremely relevant. If it indicts anybody, it indicts the package maintainers for failing to maintain their part of the distro's social contract. The upstream developers, of course, aren't beholden to anybody, but their nutty opinions ought to be equally of no practical interest to anybody. The system has broken down because the package maintainers are violating the terms of their office by catering to the wrong people. Probably the repository maintainers should take that package away from them.
Okular, Debian, and copy restrictions Posted Jun 2, 2009 8:51 UTC (Tue) by jamesh (guest, #1159) [Link]
> The upstream developers, of course, aren't beholden to anybody, but
> 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 (subscriber, #165) [Link]
Upstream, in this case, is fully aware of users' desires. Likewise, the Debian packagers. They have both elected to ignore them. It's not clear whether the packagers are choosing to honor upstream's nutty opinion, or have evolved their own nutty opinion to match, and it doesn't matter much.
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]
What users' desires? You seem to be rabidly opposed to having this option exist and automatically assuming that every rational human being should see it as an affront to God and man, when I don't think that's the case *at all*.
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 (subscriber, #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]
I didn't think it was necessarily ad hominem. I mean, the amount of time
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
(FWIW I agree with you, less vehemently: attempting to copy from a
not FAIL Posted Jun 4, 2009 0:30 UTC (Thu) by ncm (subscriber, #165) [Link]
I agree that your proposed approach would completely resolve the problem with Okular itself. (I can even agree vehemently, if you like, but I'm not accustomed to vehemence.) It would not solve the problem that Debian has, as official maintainers, individuals who have expressed and demonstrated fundamental hostility to the ideals and goals of the project.
FAIL Posted Jun 4, 2009 1:26 UTC (Thu) by JoeF (guest, #4486) [Link]
"(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.)"
Yes, that would be a very sensible approach.
FAIL Posted Jun 4, 2009 10:30 UTC (Thu) by nye (guest, #51576) [Link]
And after I spent all that time coming up with a politely factual remark, rather than making the original emotional response I felt like.
Tch.
Okular, Debian, and copy restrictions Posted Jun 3, 2009 11:05 UTC (Wed) by mbanck (subscriber, #9035) [Link]
Also note that at least some of the Debian KDE maintainers are also upstream Okular developers, so there is no clear line to be cut here.
Michael
Okular, Debian, and copy restrictions Posted Jun 2, 2009 6:32 UTC (Tue) by amit (guest, #1274) [Link]
> 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?
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]
The problem with this is that it restricts what you can do if you're not "in the know". If you are in the know, of course, you'll turn it off right away, but if you don't (and don't know what to look for), you'll be stymied. This isn't a situation where understanding what's going on really is important for, say, system integrity (and hence arguably there should be some kind of knowledge barrier).
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]
A click-through is just one click per user, and we still don't like it. Those clicks add up.
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
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]
> Actually the Debian maintainer of the respective package also claimed here he does not want to deviate from the upstream package.
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]
As far as package management is concerned, changing defaults usually is achieved through patching. If things change in new versions of the program, it can cause conflicts in the same way as other patches so has similar maintenance overhead.
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]
This is a big, big social issue without an easy answer. 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?
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 (subscriber, #165) [Link]
This is a trivial social issue with a very, very easy answer. Some people who are not users don't like the answer.
Okular, Debian, and copy restrictions Posted Jun 2, 2009 1:49 UTC (Tue) by 0b11101 (guest, #57638) [Link]
What is the very easy answer? Circumvent the DRM? Well, now you are a criminal. "Yeah, that was easy!" Seriously, not only are there laws like DMCA that criminalize this specifically, but also multinational trade treaties protecting copyrights generally. Even if those laws are not rigorously enforced within your private home, a commercially supported distribution cannot take that kind of legal risk.
Okular, Debian, and copy restrictions Posted Jun 2, 2009 2:57 UTC (Tue) by ncm (subscriber, #165) [Link]
This is not DRM. For actual DRM cases, we already have evolved the answer, as demonstrated by the present handling of DVD players.
Okular, Debian, and copy restrictions Posted Jun 2, 2009 4:20 UTC (Tue) by 0b11101 (guest, #57638) [Link]
Having trouble following your replies. You say this is not DRM?
The Okular application says specifically, "copy forbidden by DRM".
Okular, Debian, and copy restrictions Posted Jun 2, 2009 6:34 UTC (Tue) by ncm (subscriber, #165) [Link]
Yes, it's not DRM. I can't help what okular says.
Okular, Debian, and copy restrictions Posted Jun 16, 2009 13:43 UTC (Tue) by zenaan (subscriber, #3778) [Link]
ncm: YOU ROCK!
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]
DRM need not be as complicated as you elaborately explained. A quick read of the DCMA definitions of "copy protection systems" shows how broadly it can be defined. Just takes a copy right holder using some technology used to prevent some type of access.
http://thomas.loc.gov/cgi-bin/query/F?c105:6:./temp/~c105...
Circumvention Posted Jun 2, 2009 14:56 UTC (Tue) by man_ls (subscriber, #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]
IMHO, the EU reverse-engineering protections for home-use do not defend against creating widespread public software for patent and copyright infringement, and I think we will see this play out in the courts there one day. Regardless, there are current and upcoming multinational trade agreements that do cover circumventing copyright technical restrictions, in the EU, so this issue is not as easily dismissed as to say it is a USA-only problem.
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 (subscriber, #3778) [Link]
Well well well. My, what a cool nic you have ...
Okular, Debian, and copy restrictions Posted Jun 2, 2009 11:37 UTC (Tue) by neiljerram (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 (subscriber, #15413) [Link]
Abiding by copyrights does *not* require this ridiculous complain-when-copying behavior.
Okular, Debian, and copy restrictions Posted Jun 2, 2009 15:07 UTC (Tue) by nybble41 (subscriber, #55106) [Link]
Free software does not depend on copyright. The *GPL* requires copyright to be enforceable--purely in order to subvert the negative effects of copyright law, of course--but there is much more to free software than just the GPL. The most obvious example would be software in the public domain, which obviously has no dependencies whatsoever on copyright law. A more common example would be BSD software, where the only requirements are attribution and retention of the original license notice, neither of which is essential to its classification as free software. Software under the MIT and similar licenses could likewise operate just fine in the absence of copyrights.
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 (subscriber, #19270) [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."
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]
"Well, what about the goals of the other users - the ones who wrote and distributed the documents?"
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]
"It is the fact that Okular actively resists its users' obvious intent
which I find objectionable."
What on earth are you talking about? Okular provides a toggle for the
I hit this "problem" during my first day of using KDE4, which uses Okular.
Okular, Debian, and copy restrictions Posted Jun 3, 2009 19:25 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
I am aware of the toggle setting, which was cleverly hidden in a non-default page of the application settings dialog. The error message does not mention that this behavior can be disabled (short of editing the code), much less where to find the controls. It would be reasonable to assume that having gone out of their way to block such behavior the developers would make their restrictions as difficult as possible to circumvent; ergo, many wouldn't even go looking for such an option.
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]
It's reasonable to assume that if you're intimidated by complex
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]
BTW, does anyone know of software which can remove the no-copy flag on a PDF, for the benefit of
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"
Any software to toggle this flag? Posted Jun 2, 2009 1:34 UTC (Tue) by ncm (subscriber, #165) [Link]
I think pdftk can do that. It's a Java program, but on Debian compiled with gcj so you needn't install and fire up a JVM just to run it.
Any software to toggle this flag? Posted Jun 2, 2009 2:55 UTC (Tue) by foom (subscriber, #14868) [Link]
Unfortunately not. At least the version in Debian requires the owner password to do *anything*,
including even basic things like the "cat" command.
pdftk test.pdf output test.output.pdf allow AllFeatures
Any software to toggle this flag? Posted Jun 2, 2009 3:57 UTC (Tue) by foom (subscriber, #14868) [Link]
Okay, it turns out that pdftk can do it, if you apply a little patch. I found out what to do here:
http://newsgroups.derkeiler.com/Archive/Comp/comp.text.pd...
The source says:
But of course I want:
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]
ghostscript can do this. Easiest is to scrub it thorugh pdftops/pstopdf once.
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]
I've tried pdftops/pstopdf before, but as I recall, it produces pretty bad PDFs: they lose all their
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 (subscriber, #165) [Link]
How is the software supposed to know whether the copy is authorized?
Over the top Posted Jun 2, 2009 3:01 UTC (Tue) by foom (subscriber, #14868) [Link]
Indeed.
In my particular case, I get a large collection of pdf documentation from another company. *Some*
Over the top Posted Jun 2, 2009 12:53 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
Or use a saner PDF reader?
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]
> When the copyright holder sets the flag, that's like saying it isn't
> 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 (subscriber, #15413) [Link]
Bruce, you're getting pretty disingenuous here.
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]
> Free software dies at its own hands.
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]
> 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.
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
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]
> Perhaps you haven't noticed the success of the Kindle.
It's interesting that the Kindle's DRM scheme had been broken at least a few years before the Kindle
I'm not sure what to think about that -- perhaps content owners consider it good enough, if it
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 (subscriber, #165) [Link]
Bruce, I agree you're being disingenuous, unless you can tell me some practical way to distinguish a "valid defense" from an "affirmative right". Furthermore, nobody has argued that "turning off that flag" is a fair use right. They have argued that their fair use right allows them, in very common cases, to ignore the literal interpretation of the flag's name and the accompanying text in the standard. In other words, that text does not match anyone's rights. I note, further, that I frequently have other rights, beyond fair use, also not reflected in that text.
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]
Well, given that 'direspect the users' is unlikely to be written into
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]
With all due respect, Mr. Perens, I believe it is important to point out that you worked for Pixar for a long while. This film producer just released the Disney "UP" blockbuster which is doubtlessly being downloaded, without permission, by tens-of-thousands bittorrent clients at this moment. Your view that the lack of DRM spells end-times for Linux may be shaded by past experiences.
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 (subscriber, #28458) [Link]
What you're saying about being swept into a corner strongly implies that you believe DRM measures will in the future successfully keep open source projects from using various media. 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. As such, I see no strategical reason what so ever to accept even minor restrictions in order to gain brownie points from the content industry.
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]
DRM *implemented in software* is fundamentally flawed. I just hope nobody
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 (subscriber, #28458) [Link]
The decryption keys are stored somewhere on every HDMI device. Way harder than to sniff out the key from a software player, but definitely doable. Don't know enough about TPM to know how secure it is, though.
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]
Sure. It's the Copyright and Related Rights Act (2000), least in Ireland.
Next..
Over the top Posted Jun 2, 2009 16:51 UTC (Tue) by shmget (subscriber, #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 :
Over the top Posted Jun 2, 2009 3:21 UTC (Tue) by ncm (subscriber, #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]
This is confusing.
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]
Blu-Ray's AACS key has been compromised since May of 2007.
http://www.bmeink.com/A70529/high/bmepb529722.jpg
HDMI's been compromised by the HDFury2.
Neat little hack, that. They used a laptop TMDS display transmitter chip's
Fully HDMI 1.3 compliant with embedded HDCP keys and CEA861 EDID extension
Perfect match for the Ambarella A2 chip in Hauppauge's HD PVR to capture
(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]
>Nothing. And nothing will stop them from fading into obscurity as no one can (or wants to) view their content.
What colour is the sky in your world?
Over the top Posted Jun 3, 2009 21:10 UTC (Wed) by timschmidt (guest, #38269) [Link]
> What colour is the sky in your world?
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]
Okay, sorry. I'm just saying that I don't think it's realistic *at all* to expect content and its producers to 'fade into obscurity' simply for wanting to use DRM. The number of us who even know what that means may well be less than a percent of the general population, and the other guys just think we're wierd for caring about such things.
Over the top Posted Jun 4, 2009 16:21 UTC (Thu) by timschmidt (guest, #38269) [Link]
One need not know what DRM is to be prevented from viewing content by it.
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]
I have considered any technology used to limit usage of digital content a DRM solution.
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 (subscriber, #31333) [Link]
I've always considered DRM to simply mean 'digital rights management'.
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 (subscriber, #31333) [Link]
Yes.
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]
Hmmm- I disagree. Let us clarify here. If you write me an email with the words, "DO NOT FORWARD", then it is not DRM. If you write the same email and my email application abides by your words, then it is still not DRM. It *is* DRM if you write the same email with the intent for those words to trigger restriction features in my email application. Even if the work-around is trivial, it is the intent of the copyright holder to enact digital restrictions of recipients that makes DRM.
Any software to toggle this flag? Posted Jun 2, 2009 5:02 UTC (Tue) by jospoortvliet (subscriber, #33164) [Link]
Give them the windows version of Okular and all is well ;-)
You might want to disable the DRM for them in case they can't find it...
Any software to toggle this flag? Posted Jun 2, 2009 8:16 UTC (Tue) by boudewijn (subscriber, #14185) [Link]
Your windows compatriots can just use Okular on windows... Great software, isn't it? Allows you to
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]
So, a reader that has default behavior which is 'compliant', but can be changed to non-compliant in 4 clicks is OK? I suspect if Adobe cared, they could easily claim that Okular doesn't comply and thus doesn't have the appropriate patent license(s).
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]
It'd be against the spirit but not the words, so I'd think it OK. IANAL, tho.
GUI copy mode selection is not scriptable, and verified document authenticity Posted Jun 2, 2009 6:13 UTC (Tue) by tdwebste (guest, #18154) [Link]
The GUI copy mode selection is not acceptable, because it is not scriptable. What good is a this mode selection if scripts can not be used to open pdfs.
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]
What do you mean by "not scriptable"? Not scriptable by which means?
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]
"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"
The above quoted paragraph has nothing to do with the issue at hand. It
i.e. if your product reads and/or writes spec-compliant PDF files, you are
Okular, Debian, and copy restrictions Posted Jun 4, 2009 7:17 UTC (Thu) by Trelane (subscriber, #56877) [Link]
Very good catch. I totally missed that. The MSFT Office - Adobe kerfluffle makes even more sense now. (Think MSFT-Java and Sun)
Okular, Debian, and copy restrictions Posted Jun 2, 2009 6:02 UTC (Tue) by sitaram (subscriber, #5959) [Link]
Well, this is a first... Jon writing something I disagree with :-)
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 (subscriber, #34640) [Link]
I'm _really_ disappointed that Corbet failed to quote the original argument on xpdf site why this restriction makes sense. You are giving a very one-sided view of the issue.
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 (subscriber, #51625) [Link]
I don't see any argument on the xpdf site that justifies the restrictions on what may be done with a PDF. There is this:
"...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 boudewijn (subscriber, #14185) [Link]
"I don't see any argument on the xpdf site that justifies the restrictions on what may be done with
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
Yes, and in other places, most people would agree that the GPL's restrictions are just dumb. Just
Okular, Debian, and copy restrictions Posted Jun 2, 2009 8:09 UTC (Tue) by aigarius (subscriber, #7329) [Link]
There is one and only one valid reason to have this functionality - system administrators in large companies might want to enforce a no-copying or no-printing policy on their users. To allow this there should a switch in /etc that enables the DRM compliance. But it should be off by default as there is no actual reason for our users to be inconvenienced.
'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]
Disabling copying of fragments or printing are less controversial flags. What does everybody
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]
These please-inconvenience-the-user flags are about as much use as the rfc3514 evil bit. Sure, we can implement the evil bit, but why would we want to?
Okular, Debian, and copy restrictions Posted Jun 2, 2009 12:10 UTC (Tue) by boudewijn (subscriber, #14185) [Link]
Because, as has been explained many times before:
* it is demanded by the standard
Okular, Debian, and copy restrictions Posted Jun 2, 2009 12:34 UTC (Tue) by knan (subscriber, #3940) [Link]
* it is demanded by the standard
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 boudewijn (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]
> it is demanded by the standard
> 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]
Consider the following page:
http://www.coker.com.au/selinux/play.html
I'm quoting from it:
> To access my Debian play machine ssh to
[password ommited]
> I give no-one permission to distribute
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 (subscriber, #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 boudewijn (subscriber, #14185) [Link]
Yes, I'm saying that you should behave unto others as you would like them to behave towards you.
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 (subscriber, #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 boudewijn (subscriber, #14185) [Link]
At the risk of sounding like a broken record...
No, your personal interpretation of the relative importance and
Okular, Debian, and copy restrictions Posted Jun 2, 2009 19:59 UTC (Tue) by nybble41 (subscriber, #55106) [Link]
Take your own advice for a change. Even assuming we all agree that no one has the right to demand that another abandon their position, the reasonableness of applying restrictions by default is no less your *merely subjective opinion* than rjdymond's assessment that some licenses are more reasonably adhered to than others.
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]
I respect copyright and usage license. But what does this have to do with the technical limitation of the DRM bit?
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]
Then do things as every decent browser does wrt cookies.
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]
The thing is, I don't know of any browser that does so by default. By default they all just accept it, unless you change a configuration option. This sounds familiar to me...
Okular, Debian, and copy restrictions Posted Jun 6, 2009 19:31 UTC (Sat) by Hawke (subscriber, #6978) [Link]
Konqueror does, in my experience.
Okular, Debian, and copy restrictions Posted Jun 11, 2009 12:17 UTC (Thu) by oblio (guest, #33465) [Link]
Maybe this (together with various other issues) is what's holding Konqueror back. Check out Linux Hater's blog for the KDE 4 rant ;)
Okular, Debian, and copy restrictions Posted Jun 2, 2009 22:36 UTC (Tue) by gmaxwell (subscriber, #30048) [Link]
I'm fond of the restriction which you can turn off, better still might be a notice that says something like "The action you have attempted to perform is forbidden by the DRM settings on this file. Okular can ignore these settings but other PDF viewers may not. Following the law is your responsibility. [Ok] [Ignore DRM flag]".
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]
I'm no fan of copy protection, drm or whatever its called today. But if I
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
That was my choice. If the author of the document wants to sue, they can
I don't expect the authors of the software to take that risk for me. How
So if you want to be a poster child for fair use rights, fight in court
Fine with me.
Derek
Okular, Debian, and copy restrictions Posted Jun 3, 2009 18:05 UTC (Wed) by tzafrir (subscriber, #11501) [Link]
Following your logic, clive (http://clive.sourceforge.net ) is a gross violation of usage restrictions. Likewise all those Firefox plug-ins that allow you to download the flash movies instead of using the built-in player.
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 (subscriber, #165) [Link]
This isn't about the "authors of Okular", just as it isn't about the authors of Xpdf. This is about the Debian package maintainers. The xpdf package maintainer did the right thing, by the standards of the Debian project. The Okular maintainers did the wrong thing, by the same standards.
admonition systems Posted Jun 4, 2009 1:43 UTC (Thu) by zooko (subscriber, #2589) [Link]
Mark S. Miller has advocated what he calls "admonition systems". http://www.caplet.com/security/taxonomy/admonition.html Those are user interfaces which inform the user clearly that the author of the file has requested that you, the user, not do certain things, but which also makes it clear how to direct your software to do as you bid once you have chosen to respect or disrespect the request.
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'm disappointed at how many folks here have either taken the absolutist stance "It must be removed or disabled by default" while many others take the opposite absolutist position of "No change needed or desired." Where is the compromise? (Kudos to the several people who have advocated some middle ground).
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 boudewijn (subscriber, #14185) [Link]
But the Okular application _has_. Help->Report Bug.
And, of course, it's bugs.kde.org, which is the place where all KDE
Never reported upstream? Posted Jun 8, 2009 22:51 UTC (Mon) by kevinbsmith (guest, #4778) [Link]
"Of course". Sigh. As if everyone in the world knows that. I'm neither a KDE nor an Okular user, but perhaps someone could suggest that they update their web sites to have links to their bug tracker.
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 boudewijn (subscriber, #14185) [Link]
Yes, of course. If you are a normal user, you use the menu to report a bug. You don't go traipsing
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
Never reported upstream? Posted Jun 9, 2009 12:35 UTC (Tue) by kevinbsmith (guest, #4778) [Link]
Perhaps I would like to evaluate the Okular community (including bug reports) before deciding to install the application. Perhaps the bug I want to report is that the app won't even start up. There really are valid reasons for the project web site to link to the bug tracker.
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 boudewijn (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 (subscriber, #15413) [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.
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]
As a developer of text extraction tool from PDF, I'm pretty concerned of this sort of bashing. Think about the difference of this type of copy protection and robots.txt. Both are shady standards but used for some time. Do people complain about major search engines not ignoring robots.txt? Sure, this kind of features can be abused by some people. But both are easily circumvented if anyone has demand. Any "decent" search engine or crawler program are supposed to respect this, and departure from the expected behavior is considered rude. You can be rude anytime at your own risk, but please don't complain when people don't provide a tool for it.
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 (subscriber, #165) [Link]
What does "had to" mean, here? Corporate directive, or misplaced feeling of obligation?
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]
No, copy-and-paste is a form of automation too. You could always type the written characters by yourself when extraction is prohibited, although it sounds stupid. Basically, both features grant access to the contents in a basic way. They just prohibit a certain kind of use of its information. Technically, of course, it doesn't make much sense, because it's easily circumventable. But it's an okay solution as long as most people follow the restriction and to follow these restriction is considered decency.
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]
But even in those cases, we don't publicly tout that we can infringe it, right? Going back to the PDF case, what a developer could do at best (in favor of infringement) in this case is to give an ability to do so in a somewhat obscure way, and I guess that's what the Okular people did. Blaming them publicly that they didn't make it conspicuous enough is obviously too much one-sided. This is a complex real-world problem and there's no single perfect answer, either technically or socially.
Okular, Debian, and copy restrictions Posted Jun 11, 2009 10:42 UTC (Thu) by Janne (guest, #40891) [Link]
If there's one thing that's cle<r from this discussion, it's this:
If free software-folks stopped nitpicking and complaining about minor
But no, what happens is that time and energy gets wasted on pointless
And there's one thing that amazes me: Basically this discussion has been
Okular, Debian, and copy restrictions Posted Jun 16, 2009 14:54 UTC (Tue) by zenaan (subscriber, #3778) [Link]
My right to do as I choose with my computer in my house (not talking about publishing to the Internet here at the moment), is absolute!
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.
My position is: either:
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 (subscriber, #41017) [Link]
While we're at it, can we remove file permissions from the tar file format? When I untar a file with -r--r--r-- permissions, that violates my freedom.
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?
|
|||||||||||||
![[Okular]](/images/ns/okular-drm-sm.png)
