Re: Bug#451799: new evince cannot display Japanese characters correctly
Hi, On Wed, 28 Nov 2007 13:33:07 -0800, Steve Langasek wrote: On Wed, Nov 28, 2007 at 02:43:34PM +, John Halton wrote: On 28/11/2007, Michael Poole [EMAIL PROTECTED] wrote: Based on a quick look, these files establish a correspondence between different character set encodings. Copyright protects creative expression. What is the creative part of this mapping? I can see two possible bases: character selection and ambiguity resolution. Can't speak for the US, but in the UK the standard for copyright protection is somewhat lower than creative expression. Generally, a work merely has to be original (i.e. not copied from elsewhere). However, a file consisting of mappings of this nature probably constitutes a database under UK law (and in other EU jurisdictions). In that case it only attracts protection if, and only if, by reason of the selection or arrangement of the contents of the database the database constitutes the author's own intellectual creation. I really doubt that this file would meet that test, or that it would reach the substantial investment test for the separate database right. That being said, I am not sure enough to risk it in court on my dime. I would hope that Adobe would be willing to provide the data with a DFSG-compatible license and/or a notice that makes it clear whether they think the mappings are protected by copyright. Well, quite. What I said above only goes to show how complex copyright questions can become, and that's only looking at one jurisdiction. I find it hard to believe Adobe could or would assert copyright here, but I'm no more willing than you to be the one who tests that hypothesis! FWIW, I believe a search of debian-legal archives will show that we've come to the same conclusion before about copyrightability of non-creative databases, and are already shipping a number of these in Debian. I have a question: can we regard CMaps as database? Well, several years ago, some Japanese developers paid attention to the fact that CMaps are PostScript programs, not data tables like unicode tables[1]. Also, Adobe prohibits modification of that format as well as the mapping. BTW I have a news: Kenshi Muto (kmuto) asked GNU pdf developers about how they intend to get a handle on the CMap issue. The answer was they could try to ask Adobe to relicense the maps (a formal petition from the FSF)[2] and they proposed that they could do that along with Debian in order to achieve a better effect[3]. IMHO (actually, Taketoshi Sano's opinion[4]), Adobe would like to promote PDF (and PostScript), but would not like to increase incompatible unique CMaps that will impair the credibility of the format. So, it would be better for Adobe to loosen up the license of its CMap than to force FLOSS communities to create unique CMaps. So, formal petition would be a good measure. (IANAL, IANADD, and TINLA, but I am one of Japanese guys who suffers inconvenience from the CMap issue of PS/PDF. ;-) ) [1] http://lists.debian.or.jp/debian-devel/200104/msg00092.html (in Japanese) [2] http://lists.gnu.org/archive/html/pdf-devel/2007-12/msg1.html [3] http://lists.gnu.org/archive/html/pdf-devel/2007-12/msg3.html [4] http://lists.debian.or.jp/debian-devel/200104/msg00160.html (in Japanese) Many thanks, -nori -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451799: new evince cannot display Japanese characters correctly
Hi, On Thu, Dec 06, 2007 at 04:11:59AM +0900, Kobayashi Noritada wrote: FWIW, I believe a search of debian-legal archives will show that we've come to the same conclusion before about copyrightability of non-creative databases, and are already shipping a number of these in Debian. I have a question: can we regard CMaps as database? Well, several years ago, some Japanese developers paid attention to the fact that CMaps are PostScript programs, not data tables like unicode tables[1]. Also, Adobe prohibits modification of that format as well as the mapping. Being in program form doesn't automatically make it creative and copyrightable. Adobe's prohibition on modification of the format is begging the question: if it's not a copyrightable work, their prohibition carries no legal force (in the US). I have not looked at the CMaps myself, so I can't give you an informed opinion on whether I believe they contain a creative element; if you need me to give my (non-lawyerly) opinion on this, please provide a pointer to the CMaps. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451799: new evince cannot display Japanese characters correctly
On Wed, Nov 28, 2007 at 01:22:49PM +0100, Ondřej Surý wrote: However I don't think there is anything copyrightable in these files; they only contain series of numbers that describe the mappings. Do you people think it could be suitable for main? (Please follow-up on -legal only for licensing discussions.) Ondrej, are you willing - if the legal problems are settled out - to package it? Otherwise I guess me or any of the co-maintainers could do it, the packaging is absolutely trivial. It's already packaged in pkg-freedesktop SVN, but it was rejected by ftp-masters due licensing problems. If problem is only modification right, why not uploading to non-free? Osamu
Re: Bug#451799: new evince cannot display Japanese characters correctly
On Mon, Dec 03, 2007 at 11:23:24PM +0900, Osamu Aoki wrote: If problem is only modification right, why not uploading to non-free? That is certainly one option, but that may be over-cautious based on the previous discussion on this thread. John (TINLA) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451799: new evince cannot display Japanese characters correctly
However I don't think there is anything copyrightable in these files; they only contain series of numbers that describe the mappings. Do you people think it could be suitable for main? (Please follow-up on -legal only for licensing discussions.) Ondrej, are you willing - if the legal problems are settled out - to package it? Otherwise I guess me or any of the co-maintainers could do it, the packaging is absolutely trivial. It's already packaged in pkg-freedesktop SVN, but it was rejected by ftp-masters due licensing problems. Ondrej. -- Ondřej Surý [EMAIL PROTECTED] *** http://blog.rfc1925.org/ Kulturní občasník *** http://www.obcasnik.cz/ Nehoupat, prosím *** http://nehoupat.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451799: new evince cannot display Japanese characters correctly
However I don't think there is anything copyrightable in these files; they only contain series of numbers that describe the mappings. I don't see any reason in principle why series of numbers that describe the mappings couldn't be protected by copyright. Could you provide more details of why you think those numbers/mapping might *not* be copyright-protected? Thanks, John (TINLA) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451799: new evince cannot display Japanese characters correctly
On 28/11/2007, Michael Poole [EMAIL PROTECTED] wrote: Based on a quick look, these files establish a correspondence between different character set encodings. Copyright protects creative expression. What is the creative part of this mapping? I can see two possible bases: character selection and ambiguity resolution. Can't speak for the US, but in the UK the standard for copyright protection is somewhat lower than creative expression. Generally, a work merely has to be original (i.e. not copied from elsewhere). However, a file consisting of mappings of this nature probably constitutes a database under UK law (and in other EU jurisdictions). In that case it only attracts protection if, and only if, by reason of the selection or arrangement of the contents of the database the database constitutes the author's own intellectual creation. I really doubt that this file would meet that test, or that it would reach the substantial investment test for the separate database right. That being said, I am not sure enough to risk it in court on my dime. I would hope that Adobe would be willing to provide the data with a DFSG-compatible license and/or a notice that makes it clear whether they think the mappings are protected by copyright. Well, quite. What I said above only goes to show how complex copyright questions can become, and that's only looking at one jurisdiction. I find it hard to believe Adobe could or would assert copyright here, but I'm no more willing than you to be the one who tests that hypothesis! John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451799: new evince cannot display Japanese characters correctly
John Halton writes: However I don't think there is anything copyrightable in these files; they only contain series of numbers that describe the mappings. I don't see any reason in principle why series of numbers that describe the mappings couldn't be protected by copyright. Could you provide more details of why you think those numbers/mapping might *not* be copyright-protected? Based on a quick look, these files establish a correspondence between different character set encodings. Copyright protects creative expression. What is the creative part of this mapping? I can see two possible bases: character selection and ambiguity resolution. Character selection would be the selection of which characters to list (or not list) in each file. Ambiguity resolution would be the handling of look-alike characters in distinct sets. Neither of those seem like they are actually creative, given how thoroughly standardized and documented the character set encodings are. That being said, I am not sure enough to risk it in court on my dime. I would hope that Adobe would be willing to provide the data with a DFSG-compatible license and/or a notice that makes it clear whether they think the mappings are protected by copyright. Michael Poole (IANAL, IANADD, TINLA) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451799: new evince cannot display Japanese characters correctly
On Wed, Nov 28, 2007 at 02:43:34PM +, John Halton wrote: On 28/11/2007, Michael Poole [EMAIL PROTECTED] wrote: Based on a quick look, these files establish a correspondence between different character set encodings. Copyright protects creative expression. What is the creative part of this mapping? I can see two possible bases: character selection and ambiguity resolution. Can't speak for the US, but in the UK the standard for copyright protection is somewhat lower than creative expression. Generally, a work merely has to be original (i.e. not copied from elsewhere). However, a file consisting of mappings of this nature probably constitutes a database under UK law (and in other EU jurisdictions). In that case it only attracts protection if, and only if, by reason of the selection or arrangement of the contents of the database the database constitutes the author's own intellectual creation. I really doubt that this file would meet that test, or that it would reach the substantial investment test for the separate database right. That being said, I am not sure enough to risk it in court on my dime. I would hope that Adobe would be willing to provide the data with a DFSG-compatible license and/or a notice that makes it clear whether they think the mappings are protected by copyright. Well, quite. What I said above only goes to show how complex copyright questions can become, and that's only looking at one jurisdiction. I find it hard to believe Adobe could or would assert copyright here, but I'm no more willing than you to be the one who tests that hypothesis! FWIW, I believe a search of debian-legal archives will show that we've come to the same conclusion before about copyrightability of non-creative databases, and are already shipping a number of these in Debian. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451799: new evince cannot display Japanese characters correctly
On Wed, Nov 28, 2007 at 01:33:07PM -0800, Steve Langasek wrote: On Wed, Nov 28, 2007 at 02:43:34PM +, John Halton wrote: On 28/11/2007, Michael Poole [EMAIL PROTECTED] wrote: Based on a quick look, these files establish a correspondence between different character set encodings. Copyright protects creative expression. What is the creative part of this mapping? I can see two possible bases: character selection and ambiguity resolution. Can't speak for the US, but in the UK the standard for copyright protection is somewhat lower than creative expression. Generally, a work merely has to be original (i.e. not copied from elsewhere). However, a file consisting of mappings of this nature probably constitutes a database under UK law (and in other EU jurisdictions). In that case it only attracts protection if, and only if, by reason of the selection or arrangement of the contents of the database the database constitutes the author's own intellectual creation. I really doubt that this file would meet that test, or that it would reach the substantial investment test for the separate database right. That being said, I am not sure enough to risk it in court on my dime. I would hope that Adobe would be willing to provide the data with a DFSG-compatible license and/or a notice that makes it clear whether they think the mappings are protected by copyright. Well, quite. What I said above only goes to show how complex copyright questions can become, and that's only looking at one jurisdiction. I find it hard to believe Adobe could or would assert copyright here, but I'm no more willing than you to be the one who tests that hypothesis! FWIW, I believe a search of debian-legal archives will show that we've come to the same conclusion before about copyrightability of non-creative databases, and are already shipping a number of these in Debian. Even if not, an equivalent table could be be generated from the data in icu, iconv or anything else that deals with character set conversions, provided that the format is known. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451799: new evince cannot display Japanese characters correctly
On Wed, Nov 28, 2007 at 01:33:07PM -0800, Steve Langasek wrote: FWIW, I believe a search of debian-legal archives will show that we've come to the same conclusion before about copyrightability of non-creative databases, and are already shipping a number of these in Debian. Thanks, that's useful to know. I'm still trying to get a feel for how Debian treats these cases where there is no express licence, how people weigh up the legal pros and cons. John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451799: new evince cannot display Japanese characters correctly
John Halton [EMAIL PROTECTED] writes: Thanks, that's useful to know. I'm still trying to get a feel for how Debian treats these cases where there is no express licence, how people weigh up the legal pros and cons. Inconsistently :-) -- \The World is not dangerous because of those who do harm but | `\ because of those who look at it without doing anything. | _o__) —Albert Einstein | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451799: new evince cannot display Japanese characters correctly
clone 451799 -1 retitle 451799 evince should depend on poppler-data reassign -1 wnpp retitle -1 RFP: poppler-data -- Encoding data for the poppler PDF rendering library block 451799 by -1 thanks * Package name: poppler-data Version : 0.1.1 Upstream Author : Adobe, Red Hat * URL : http://poppler.freedesktop.org/ * License : non-free, see below Programming Lang: None Description : Encoding data for the poppler PDF rendering library This package contains the encoding data needed to view some PDF documents with libpoppler. The copyright is the following: Copyright 1990-1998 Adobe Systems Incorporated. All Rights Reserved. Patents Pending NOTICE: All information contained herein is the property of Adobe Systems Incorporated. Permission is granted for redistribution of this file provided this copyright notice is maintained intact and that the contents of this file are not altered in any way from its original form. PostScript and Display PostScript are trademarks of Adobe Systems Incorporated which may be registered in certain jurisdictions. However I don't think there is anything copyrightable in these files; they only contain series of numbers that describe the mappings. Do you people think it could be suitable for main? (Please follow-up on -legal only for licensing discussions.) Ondrej, are you willing - if the legal problems are settled out - to package it? Otherwise I guess me or any of the co-maintainers could do it, the packaging is absolutely trivial. Le lundi 19 novembre 2007 à 02:25 +0900, Hideki Yamane a écrit : New evince package displays Japanese characters wrong. Broken. Please see attached image file, one is opened CP-06.pdf with evince (Screenshot-CP-06.pdf.png), and another is with Adobe Reader (shows fine). I heard same problem from other people on IRC. The new poppler version needs some specific files that contain some mappings between Unicode and other encodings, which are in a separate package. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
