Sunday, February 20, 2005

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.

13 comments:

Anonymous said...

Hi Albert,

I'd like to give you a different recommendation. Implement the DRM "parsing" as usual but simply give the user the possibility to override it. So when the user asks to print a file, he gets a dialogbox which says "The author of the document has asked not to print this file. Do you want to print it nevertheless?" or something like that.

Simply forbidding it while lead to nothing as the code will simply be forked.

Greetings
Bausi

Anonymous said...

I agree with the above. I'd like to see a warning given that the document is protected by DRM, but be allowed to continue anyway. I also understand why some sysadmins would want to force DRM.

There could be an entry in the global kdmrc with options, such as:
DRM=[yes,no,warn]The default setting could be DRM=warn, to produce the warning dialog. It would be nice if this dialog had a HELP button, linking to the DRM section of the KPDF manual.

If the sysadmin wanted to force DRM (e.g. for corporate installations or kiosks) they could do this by setting DRM=yes.

Sometimes DRM just doesn't matter: Teachers are always allowed to make copies of things for educational purposes, lawyers can copy documents as part of legal filings, writers can excerpt for reviews, and so on. They could set DRM=no so they don't have to click through a useless dialog every time they need to print/copy/etc.

That way everyone's happy. It shouldn't be too hard to implement. Just an idea.

Cheers,
Andrea

Mikal said...

Hi Albert

It must be sucky that people tell you what and what not you should do. I am sorry about that, but I am really glad you made it optional.

Anonymous said...

How many lines of code have DRM owners contibuted to KPDF? How many lines of code have other depelopers contributed?
So, do you really want to annoy anybody who just wants to print a PDF? Do you really want to annoy anybody who just wants to use copy/paste?

Maybe someone is going to do a fork with DRM=no or DRM=ask as default.

Anonymous said...
This comment has been removed by a blog administrator.
Anonymous said...

KDE or the distributions should not be making choices for the users. Let the user decide. If you do not, I plan to fork KPDF under FreePDF and put out rpms for all the major distributions.

Anonymous said...

I consider DRM like this as similar to other annoyances like pop-up ads, letting people on MSN change their display name, and WMV being able to open web pages automatically.

Just because technology adds a capability, does not mean it is good and won't be abused.
I'm fairly sure that everyone (except advertisers) would agree that popups were a bad idea (hence pop-up blockers). The WMV thing was definitely a bad idea - you don't see mplayer etc. implementing it.

And even Microsoft has implemented aliases in MSN 7 (I think). It is available in MSN Plus at least.

pinky said...

I think this switch will change nothing.
The only hope is, that all distributions will use this switch by default.
If not, there will be users who can't make with their copy of an pdf what they wan't.
So they will look for an other pdf viewer.
By the whole thing nobody can win and only one can lose -> kpdf.

So i can just recommend you to remove the DRM implementation or make it configurable for normal users without re-compile it.
I think this are the only two valid options without endanger the future of kpdf as the default pdf-viewer

Nathan Adams said...

I think it would be immediately better if the default compile was to turn the DRM off (as opposed to on by default), with users given the option to add the flag at compile time to enable it, for any users with the particular use cases that require it (eg in an office setting).

Otherwise, this is pretty analogous to the pop-up problem. Advertisers obviously intended you to see pop-ups, and content providers obviously intended you to see the ads. But it's widely agreed that they go over the tolerable line, and that therefore pop-up blocking is fine and good. Limiting in software what a user can do with their printer and a file on their machine is akin to the same principle.

Albert Astals Cid said...

Hi anonymous, feel free to do your fork, that is where GPL force resides, the only problem i see is who wants a fork whose life is dead, are you going to backport all our features and all our bugfixes?

For those who ask a configuration option (instead of a configure switch) keep in mind we have a STRING FREEZE in KDE right now that means you can not add any NEW string before 3.4 release that is comming in a few weeks. We may add it after STRING FREEZE is over.

Albert Astals Cid said...

The post that says

"This post has been removed by a blog administrator.

9:41 AM"

has been removed because it was a duplicate post.

Albert Astals Cid said...

Anonymous said:
"How many lines of code have other depelopers contributed?"

Almost 95% of current code on kpdf is coded by Enrico and me or comes from xpdf, only some code of the shell code remains from old kpdf.

Anonymous said...

Hi Albert,

DRM is an interesting technology for big companies who want to control the access or diffusion (leaking) of information. For the home user, it is a different story.

If we don't have a DRM infrastructure in KDE, these companies will just not switch to OpenSource software.

Andrea's solution is in my opinion the best to implement post 3.4. Having a central configuration place for enabling / disabling / warning of DRM. Sysadmins who wan't to enable DRM in their organisation will juts set the option and lock it with kiosk. The default option could be 'warning'.

Cheers,
Charles de Miramon