On Wed, Jun 11, 2008 at 05:20:43PM +0200, Ondřej Surý wrote: > 2008/6/11 Robert Millan <[EMAIL PROTECTED]>: > > On Wed, Jun 11, 2008 at 04:10:32PM +0200, Jakub Wilk wrote: > >> >So they're not used internally, but externally. IOW, it provides > >> >a helper framework to facilitate implementation of restriction > >> >management in an upper layer. > >> It's nothing wrong with that, as long as you are free _not_to_ use the > >> framework. > > > > In practice, it tends to generate confusion. For example, the implementor > > of > > a libpoppler-based program might naively think that access to the data is > > disallowed by cryptography instead of restriction management, and make her > > program disallow access to the document in good faith. > > And so what? You want to disallow people to write such programs? Or > you want to disallow people to write DRM programs at all? And what > about their freedoms?
Considering there's no mechanism that would allow us to "disallow" people from writing a specific program, I think this is entirely out of context. But yes, I respect their freedom to write anything they like using Debian, even trojans, viruses or spammer tools. This doesn't change the fact that a user who installs non-mallicious programs based on this library may obtain bizarre information, such as a file manager telling her a PDF can be read but not printed, whereas this is in fact not only false, but it even violates the principles of information theory. > These functions doesn't restrict you, they just > inform you about flags used in PDF. Since I already replied to this, I assume you didn't read it. I'm pasting it here for your convenience: <quote> Pino, I agree with what you said. But the information it is displaying leads the user to believe this document cannot be printed, which isn't true most of the time. It is misleading. An accurate description of the information would be, that the author of this document pretended to restrict you from printing it, but this will only have an effect if you're not using the free PDF viewer that came with KDE. I don't know how to summarize this, but certainly "cannot be printed" doesn't describe reality. </quote> (from http://bugs.kde.org/show_bug.cgi?id=162089#c9) > > If you don't want to remove the functions, please consider at least renaming > > them and clearly documenting in the code that they're purely informative. > > Try asking upstream. Since upstream not only added these functions in first place, but also used them to implement restriction management, I expect that discussing this with upstream would be even less productive than it is discussing it with you or the KDE developers. > I don't see any reason to mangle with API/ABI > just because of your holy war. What holy war? I'm talking about technical flaws; namely, that programs make biased assumptions about this library's API, which ultimately leads to false information being reported to the user. Please don't turn it into politics ... -- Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What good is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
