Re: Bug#224866: kanjidic: Kanjidic is not DFSG-free
On Tue, 23 Dec 2003, Dafydd Harries wrote: Kanjidic's copyright file states (lines 208-212): The commercial utilization of the frequency numbers is prohibited without written permission from Jack Halpern. Use by individuals and small groups for reference and research purposes is permitted, on condition that acknowledgement of the source and this notice are included. First, since the frequency can be construed as a fact, and therefore is not copyrightable work of authorship, I'm not particularly concerned by this. [If there is a jurisdiction which does construe mere compendiums of facts as a work of authorship, we could perhaps reconsider this.] Second, the documentation included with the source file seems to indicate that the frequency actually in kanjidic are not Jack Halpern's at all (which anyways were taken from the National Language Research Institute in Tokyo) but [...] is based on an analysis of word frequencies in the Mainichi Shimbun over 4 years by Alexandre Girardi.[1][2] I suggest that the maintainer adjust the language in debian/copyright to reflect the fact that kanjidic no longer contains the frequency information that was (dubiously) copyrighted by Jack Halpern. Don Armstrong 1: kanjidic_doc.html in kanjidic-2003.07.21. 2: Its worth noting that this conflicts with what is listed in kanjidic.doc, but it seems that the HTML file superceeds the .doc: Earlier editions [...] used a frequency-of-use ranking [...] interpreted and adapted by Jack Halpern. (From [1]) -- Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and the Ugly). -- Matt Welsh http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Bug#224866: kanjidic: Kanjidic is not DFSG-free
Don Armstrong [EMAIL PROTECTED]: The commercial utilization of the frequency numbers is prohibited without written permission from Jack Halpern. Use by individuals and small groups for reference and research purposes is permitted, on condition that acknowledgement of the source and this notice are included. First, since the frequency can be construed as a fact, and therefore is not copyrightable work of authorship, I'm not particularly concerned by this. [If there is a jurisdiction which does construe mere compendiums of facts as a work of authorship, we could perhaps reconsider this.] The European Union has a Database Directive which grants monopoly rights to the creators of databases, so the prohibition above, which doesn't mention copyright, could still be effective. If the frequencies were manually adjusted, perhaps copyright would apply in some places, too. If as you say the package no longer contains Jack Halpern's work, all this is irrelevant, but perhaps you're interested to know about the Database Directive anyway in case you encounter similar cases.
I'll contact upstream
reopen 183860 tags 183860 moreinfo thanks control I've just send a message to RMS (cc'd to this bug) asking for clarification. I hope we get as solution soon; however, at the moment, this appears to be quite a valid bug. Using even marginally cautious standard of what constitutes a work based on [the Program] under Section 2 [of the GPL], the manuals qualify. Since we distribute them in an object form (info), we must Accompany [the Program in object code or executable form] with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 [of the GPL] on a medium customarily used for software interchange. We can not do that because the GFDL is not GPL-compatible. Since from reading the licenses it is fairly clear that we are violating them, we need clarification on why this is _not_ a bug, not on why it is. I'm requesting such clarification. Re-opening. [ cc'd to legal so they may point flaws in my reasoning, if any. Please don't cc control on responses! ]
Re: I'll contact upstream
Anthony DeRobertis wrote: I hope we get as solution soon; however, at the moment, this appears to be quite a valid bug. Using even marginally cautious standard of what constitutes a work based on [the Program] under Section 2 [of the GPL], the manuals qualify. Huh? Why do you think that running a document written in Texinfo through a Texinfo interpreter makes the document a derivative work of a (specific) Texinfo interpreter?
Re: I'll contact upstream
On Dec 23, 2003, at 13:21, Florian Weimer wrote: Huh? Why do you think that running a document written in Texinfo through a Texinfo interpreter makes the document a derivative work of a (specific) Texinfo interpreter? Because that's not what we're doing. We're running texinfo.tex and foo.texi through the Τεχ interpreter. I'm pretty sure various portions of texinfo.tex get copied to the output. I thus base it on http://www.gnu.org/licenses/gpl-faq.html#GPLOutput
Re: I'll contact upstream
Anthony DeRobertis wrote: On Dec 23, 2003, at 13:21, Florian Weimer wrote: Huh? Why do you think that running a document written in Texinfo through a Texinfo interpreter makes the document a derivative work of a (specific) Texinfo interpreter? Because that's not what we're doing. We're running texinfo.tex and foo.texi through the interpreter. I still can't see why this should pose a problem. Do you think that makeinfo shares the same problem? Why? I'm pretty sure various portions of texinfo.tex get copied to the output. Which ones? Are they even subject to copyright? Sorry, you need much more convincing arguments IMHO.
Re: Bug#224866: kanjidic: Kanjidic is not DFSG-free
Dafydd Harries wrote: This appears to me to be a clear violation of policy. The problem with SKIP codes has been fixed in kanjidic 2003.07.21-1. See the changelog: kanjidic (2003.07.21-1) unstable; urgency=low * New upstream release * New license that allows modifications and free redistribution: now in main * New maintainer. Closes: #192690 * removed SKIP codes. Closes: #182652 * added debian/download to build a new source tar and remove SKIP codes Moreover, Jim Breen, the author of kanjidic, explained me that Jack Halpern's SKIP copyright statement is a dead letter (and kanjidic file has been used by freeware and shareware for a decade without Jack Halpern making any noise about it). He'll also see if Jack Halpern will agree to a more sensible copyright statement for the SKIP codes. Anyway SKIP codes are not distributed anymore with the latest upload of kanjidic, so I close this bug. Cheers, -- Ludovic Drolez. http://www.palmopensource.com - The PalmOS Open Source Portal http://www.drolez.com - Personal site - Linux and PalmOS stuff
Re: I'll contact upstream
On Tue, Dec 23, 2003 at 08:06:28PM +0100, Florian Weimer wrote: Anthony DeRobertis wrote: On Dec 23, 2003, at 13:21, Florian Weimer wrote: Huh? Why do you think that running a document written in Texinfo through a Texinfo interpreter makes the document a derivative work of a (specific) Texinfo interpreter? Because that's not what we're doing. We're running texinfo.tex and foo.texi through the interpreter. I still can't see why this should pose a problem. Do you think that makeinfo shares the same problem? Why? As a Texinfo developer, I know that makeinfo does not have this problem for Info output. However, you must remember that Texinfo is a compiled language, not an interpreted one. I'm pretty sure various portions of texinfo.tex get copied to the output. Which ones? Are they even subject to copyright? As for DVI output, you may be able to get away with saying that you're making a derivative work. This only stems from the fact that texinfo.tex defines many macros that are essential syntax for the file you are compiling. The analogous case is #including a header file that declares and defines all its code. Simon
Re: Bug#224866: kanjidic: Kanjidic is not DFSG-free
On Tue, 23 Dec 2003, Ludovic Drolez wrote: Moreover, Jim Breen, the author of kanjidic, explained me that Jack Halpern's SKIP copyright statement is a dead letter (and kanjidic file has been used by freeware and shareware for a decade without Jack Halpern making any noise about it). He'll also see if Jack Halpern will agree to a more sensible copyright statement for the SKIP codes. As far as copyright goes, non-enforcement does not change the copyright at all one way or the other. Furthermore, Debian's useage extends far beyond mere non-profit or research only useage, so the history of the enforcement of its use in freeware and shareware for a decade isn't particularly relevant. If this were still an issue for kanjidic, the SKIP codes inclusion in Debian would still require a valid license which is DFSG free. Mere lack of copyright enforcement activity is not sufficient. Anyway SKIP codes are not distributed anymore with the latest upload of kanjidic, so I close this bug. Please change debian/copyright to reflect that fact before you close the bug. Don Armstrong -- All bad precedents began as justifiable measures. -- Gaius Julius Caesar in The Conspiracy of Catiline by Sallust http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Bug#224866: kanjidic: Kanjidic is not DFSG-free
On Tue, 23 Dec 2003, Edmund GRIMLEY EVANS wrote: Don Armstrong [EMAIL PROTECTED]: First, since the frequency can be construed as a fact, and therefore is not copyrightable work of authorship, I'm not particularly concerned by this. [If there is a jurisdiction which does construe mere compendiums of facts as a work of authorship, we could perhaps reconsider this.] The European Union has a Database Directive which grants monopoly rights to the creators of databases, so the prohibition above, which doesn't mention copyright, could still be effective. Bummer. Now the EU gets stuck with allowing copyrights on the various Genome sequences. I guess the phenomenon of governmentally sanctioned rape of the populace is spreading. Don Armstrong -- Fate and Temperament are two words for one and the same concept. -- Novalis [Hermann Hesse _Demian_] http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Binaries under GPL(2)
15-Dec-03 07:39 Walter Landry wrote: Alexander Cherepanov [EMAIL PROTECTED] wrote: 8-Dec-03 20:43 Walter Landry wrote: If I give you GPL'd source, then there is only two ways in which you can make modifications, Section 2 and Section 3. Section 3 allows a particular kind of modification (compilation), and Section 2 allows any kind of modification. IMHO there is no such a clear division: Section 2 is about any form (or only source form) while Section 3 is about executable form. Section 3 is about distribution of executable form and it doesn't talk about modification at all. All permissions to modify are in Section 2. Creating an executable is also a way of modifying code. The code is translated into machine code, similar to running a document through babelfish. Exactly. Thus, when distributing binaries compiled from sources, the compilation is under Section 2 and the distribution is under Section 3. That's part of the original confusion--requirement of source form in Section 2 applies only to distribution, not to modification. Compilation is not covered by the license, only distribution. Distribution of modified binaries is covered by Sections 2 and 3. Section 3 lets distribute binaries as long as you distribute source. Section 2 tells you what you have to do if you modified the source. Pardon? You agreed above that compilation is a kind of modification. And modification is clearly covered by Section 2. Or you mean that Section 3 implicitly contains a permission to compile? Or what? Distributing binaries under Section 2 probably means editting the binaries with a hex editor. You also need to have the rights to distribute everything in the binary under the GPL. BTW, that's also interesting. Can you distribute, under Section 3, a binary statically linked with a library from non-free compiler? Probably not. Section 3 clearly says that the binary must be distributed under the terms Sections 1 and 2. And 2b says that the whole thing must be under the GPL. If the library linked in is, for example, non-modifiable that's impossible. Though one can argue that this is the usual way of creating an executable and therefore Section 3 gives a permission to do just that... With non-free compilers, that may be a problem. With gcc, that probably means more hex editing to include the FSF, HP, SGI, etc. copyrights. The only difference in distribution under Section 2 and under Section 3 is the requirement for sources. True. That would seem to imply that you have to preserve copyright notices etc. in all of the modified files. Otherwise it makes no sense to refer to the terms of Section 1. If it makes no sense to refer to it from Section 2 then it makes no sense to refer to it from Section 3 at all. In fact, Section 1 contains the following requirements: (a) you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; (b) keep intact all the notices that refer to this License and to the absence of any warranty; and (c) give any other recipients of the Program a copy of this License along with the Program. You seems to talk only about (b) but (a) and (c) are quite reasonable in any situation (with the Program in (c) replaced by something else, of course). But the usual way of creating an executable is by running code through a compiler, which removes most of those notices. So you could argue that Section 3 gives you permission to do just that. Now I get your idea. You say that one usually cannot distribute a binary under Section 2 because he cannot comply with some technical requirements from Section 1 but these requirements are overridden when distributing under Section 3. That would be an interesting solution. The hole in the explicit wording seems to be so clear that I start doubting it is just an oversight. Maybe it's normal for sections of a license to trump each other? The hole is there, but exploiting it is hard. People don't normally modify machine code. That's true for machine code but there are other kinds of binaries. Consider info for example. It usually contains copyright notices and it usually is not source. Is it ok to distribute .info without .texi? Sasha
Re: Plugins, libraries, licenses and Debian
17-Dec-03 07:26 Anthony DeRobertis wrote: Emphasis added, of course. So, when I write a plugin I can't claim to have created a compilation of the plugin and the host, because the plugin is not preexisting. Following the readme file's statement that A is a plugin for HOST certainly does not create a compilation original work of authorship. Even if it did, that copyright would belong to the Debian maintainer, and he certainly can't sue Debian for distributing it after he uploads it.[1] Why copyright for host+plugin is important at all? GPL 2b: b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. It doesn't talk about derivative work or compilation, it talks about any work ... that ... contains. The only reason why the whole CD (or CD set) is not required to be under GPL is a special exception about mere aggregation. Sasha
Re: Binaries under GPL(2)
16-Dec-03 16:07 Joe Moore wrote: Anthony DeRobertis said: The only time I think they would allow otherwise would be if the copyright holder distributed object code under the GPL. I don't know what they'd do then. I'd argue (not that a court would necessarily agree) that The Work described in sections 1 and 2 is the object code, so I can make and/or distribute copies of The Work. Then it's Ok for non-free? Sasha
Re: Binaries under GPL(2)
16-Dec-03 13:34 Anthony DeRobertis wrote: On Dec 13, 2003, at 23:09, Alexander Cherepanov wrote: The hole in the explicit wording seems to be so clear that I start doubting it is just an oversight. Maybe it's normal for sections of a license to trump each other? If one section of a legal document is more specific than an other, it is normal to follow the more specific one. So, if GPL 3 covers a specific modification, and GPL 2 covers any modification, and you do that specific modification, you follow section 3, not section 2. In general, you don't interpret a legal document to make an entire section irrelevant. A court should ask, What did the FSF intend by putting in a section 3? And they will come to the answer: If you distribute object code, you must follow section 3. The question seems to be more like that: is it intentional or is it an oversight? In any case it's probably better to correct this because it leads to the situation when all kinds of interpretaions arise as debian-legal archive shows. Maybe in GPL v3... The only time I think they would allow otherwise would be if the copyright holder distributed object code under the GPL. I don't know what they'd do then. Agreed. Sasha
Re: Binaries under GPL(2)
Alexander Cherepanov [EMAIL PROTECTED] wrote: 15-Dec-03 07:39 Walter Landry wrote: Alexander Cherepanov [EMAIL PROTECTED] wrote: 8-Dec-03 20:43 Walter Landry wrote: Thus, when distributing binaries compiled from sources, the compilation is under Section 2 and the distribution is under Section 3. That's part of the original confusion--requirement of source form in Section 2 applies only to distribution, not to modification. Compilation is not covered by the license, only distribution. Distribution of modified binaries is covered by Sections 2 and 3. Section 3 lets distribute binaries as long as you distribute source. Section 2 tells you what you have to do if you modified the source. Pardon? You agreed above that compilation is a kind of modification. And modification is clearly covered by Section 2. Or you mean that Section 3 implicitly contains a permission to compile? Or what? I mean that Section 3 lets you distribute binaries as long as you distribute source. If you happen to have modified that source, then you have to comply with Section 2 in how you've modified the source (prominent notices etc.) Distributing binaries under Section 2 probably means editting the binaries with a hex editor. You also need to have the rights to distribute everything in the binary under the GPL. BTW, that's also interesting. Can you distribute, under Section 3, a binary statically linked with a library from non-free compiler? Probably not. Section 3 clearly says that the binary must be distributed under the terms Sections 1 and 2. And 2b says that the whole thing must be under the GPL. If the library linked in is, for example, non-modifiable that's impossible. Though one can argue that this is the usual way of creating an executable and therefore Section 3 gives a permission to do just that... Section 3 specifically lists the compiler as one of the things that you don't have to distribute under the GPL. Historically, many things were compiled with a non-free compiler and distributed by the FSF under the GPL. With non-free compilers, that may be a problem. With gcc, that probably means more hex editing to include the FSF, HP, SGI, etc. copyrights. The only difference in distribution under Section 2 and under Section 3 is the requirement for sources. True. That would seem to imply that you have to preserve copyright notices etc. in all of the modified files. Otherwise it makes no sense to refer to the terms of Section 1. If it makes no sense to refer to it from Section 2 then it makes no sense to refer to it from Section 3 at all. In fact, Section 1 contains the following requirements: (a) you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; (b) keep intact all the notices that refer to this License and to the absence of any warranty; and (c) give any other recipients of the Program a copy of this License along with the Program. You seems to talk only about (b) but (a) and (c) are quite reasonable in any situation (with the Program in (c) replaced by something else, of course). Exactly. But those are much easier to comply with. But the usual way of creating an executable is by running code through a compiler, which removes most of those notices. So you could argue that Section 3 gives you permission to do just that. Now I get your idea. You say that one usually cannot distribute a binary under Section 2 because he cannot comply with some technical requirements from Section 1 but these requirements are overridden when distributing under Section 3. That would be an interesting solution. Yup. The hole in the explicit wording seems to be so clear that I start doubting it is just an oversight. Maybe it's normal for sections of a license to trump each other? The hole is there, but exploiting it is hard. People don't normally modify machine code. That's true for machine code but there are other kinds of binaries. Consider info for example. It usually contains copyright notices and it usually is not source. Is it ok to distribute .info without .texi? As long as it complies with Section 2, it should be fine. I don't know if, in general, .info files will comply. For example, does any copyright from makeinfo leak into the .info files? Regards, Walter Landry [EMAIL PROTECTED]
