| |||||||||||||
Okular, Debian, and copy restrictionsOkular, Debian, and copy restrictionsPosted Jun 2, 2009 0:47 UTC (Tue) by corbet (editor, #1)In reply to: Okular, Debian, and copy restrictions by bjacob Parent article: Okular, Debian, and copy restrictions 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?
(Log in to post comments)
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 (subscriber, #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).
|
|||||||||||||