For those who fear a fork

I just wanted to inform you that a few moments after the DRM code was added to KPDF we added a configure switch so if you do

./configure --enable-kpdf-drm=no

you still get the old behaviour. IMHO that rules out any possibility of a fork.

Mantainership is a heavy rock

Since i took kpdf mantainership I've been quite proud of the changes Enrico, Tobias and me have made to it. But all things have its bad faces, and kpdf development have had 2 of them.

First of them happened when i introduced the possibility of running external programs on a user click on a link if the pdf specified this, that was put down by kde-cvs list readers as they said it was a security problem even if we added a dialog asking the user if he wanted to execute the command or not. IMHO that can be an interesting feature in some cases like when doing a presentation, but i can understand the security implications

The second has happened today when Enrico and me have added the DRM handling to PDF, that means, if the pdf says you can not print it, we don't let you do it, and some similar things. That has caused some controversy on #kde-devel as people said that this removes freedom from the user side and that there is no need for us to implement it. IMHO there is a need for this, i mean we don't go on opening password protected files without asking for a password, if the author put a password on it it was because he had good reasons, so if the author decided he did not like his pdf to be printed we do the same as with the password protected the file. Maybe you want to print the file, but should not blame kpdf for not being able to print it, blame the author for being an asshole.

Well i suppose being the mantainer of a program means you have to be prepared for such discussions.