[Pkg-kde-talk] Re: DRM in PDF readers

[Christopher Martin]

--nextPart1410536.qnHRVybLd1
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On March 12, 2005 09:01, Frederic Peters wrote:
> I recently adopted pdftohtml, a program to translate PDF documents into
> HTML.  It is a derivative of xpdf.  I am now asked to override the DRM
> tests (current code checks for "don't copy me" pdf flag and aborts if
> set).
>
> It is easy patching to disable this but in the course of the bug report
> (<http://bugs.debian.org/298584>) xpdf author, Derek B. Noonburg, raised
> his hand: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D298584#msg22
>
> This is basically the same as his official statement available on
>   <http://www.foolabs.com/xpdf/cracking.html>
>
> Hamish Moffatt, xpdf maintainer, then told me about the discussion
> when he was asked to disable DRM checks:
>   <http://lists.debian.org/debian-devel/2001/03/msg00862.html>
> and this particular email:
>   <http://lists.debian.org/debian-devel/2001/03/msg00927.html>
>
> He also writes:
>   Frederic, you may open this discussion again on debian-devel or
>   debian-legal if you wish, especially wrt pdftohtml. I think consistency
>   between PDF reading applications would be good.
>
> I'm all for consistency, I quickly checked PDF readers (all of them
> based on xpdf code) to see if they bypassed DRM settings:
>
>                 upstream   debian
>   --------   ------
> evince          yes        yes
> gpdf            yes        yes
> kpdf            yes        yes
> pdftohtml       no         no
> viewpdf.app[1]  yes        yes
> xpdf[2]         no         yes
>
>   [1] by mean of pdfkit.framework
>   [2] includes pdftotext
>
>
> My current idea is to default to upstream behaviour and implements an
> option to override the settings but I would like to have some comments
> on the "DRM-in-Debian" situation.

I checked, and kpdf 3.4 now, by default, enables DRM restrictions. This=20
decision was very controversial and quickly reversed in HEAD, but the=20
change was not checked into KDE_3_4_BRANCH. I recommend that we build=20
kdegraphics with the --disable-kpdf-drm switch to re-establish the expected=
=20
(and future) behaviour.

But before I commit this change (Ubuntu already committed it, but that=20
doesn't mean we must follow), I'd like to run it by the team, since the=20
above mail brings up certain issues with this decision.

Looking at the old debian-devel thread linked to above, the general=20
consensus was that DRM can infringe fair-use rights, and it should be left=
=20
up to the user to obey the copyright laws in his/her locale. I (personally)=
=20
agree with this view. Since this stance has since been adopted by all the=20
other xpdf-based viewers, and no movement to reverse this seems afoot,=20
temporarily changing kdpf's default isn't a momentous choice - but again,=20
I'd like to check if the rest of the team agrees or disagrees.

Cheers,
Christopher

--nextPart1410536.qnHRVybLd1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Signed by Christopher Martin <chrsmrtn@freeshell.org>

iD8DBQBCNO52U+gWW+vtsysRAhGiAJ4+KVxQ8WsFpihGSJKbErRpdx/VyQCgmuB+
/jGD2SfUv5+JMmkLF+7elEI=
=fUkb
-----END PGP SIGNATURE-----

--nextPart1410536.qnHRVybLd1--