Re: copyright violation in libflash
Hi Robert, Thanks for bring this to my attention; I agree that we should remove the package, as I checked the two files and both mention that they are derived from sample code. I can't believe I didn't see that; I thought the only copyright violation was the old header from Mozilla which was replaced. Aubin P.S. Is Oliver using my patches? On Fri, Aug 02, 2002 at 11:37:12PM +0200, Robert Millan wrote: Hi Aubin! Olivier Debon (upstream maintainer of libflash) just told me that some files in libflash cannot be licensed under the GPL: ./lib/adpcm.cc ./lib/script.cc because they are (or appear to be) a derived work from macromedia's copyrighted code. he said he's working on a replacement and will release a fixed version in a few weeks. please could you invistigate on this? it could be that libflash needs to be removed from debian until the issue is solved. I'm CCing debian-legal cheers, -- Robert Millan 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5 Andrew S. Tanenbaum, 30 Jan 1992
GPL-script to be run on a non-free interpreter
Is it OK to distribute a script, which is - licencend under GPL. - intended to be executed by a non-free interpreter. Background: I'm intending to package maria (ITP at bug #146320), which is licenced under GPL. Besides the main tool, called maria, it also contains a script, called maria-vis, which can be used to visualise the output of maria. It is a script for the lefty interpreter, which is part of the non-free graphviz package. The first line of maria-vis is #!/usr/bin/lefty I was intending to split maria into several binary packages, in particular - maria: the core. Goes into main, suggests maria-vis - maria-vis: the mentioned script + manpage. Goes into contrib, depends on graphviz. When I sent my ITP on debian-devel today, Moshe Zadka claimed that even distributing maria-viz would be illegal. http://lists.debian.org/debian-devel/2002/debian-devel-200208/msg00188.html Can please someone advise whether this is really the case? Thanks. -Ralf. --
Re: GPL-script to be run on a non-free interpreter
On Aug 04, Ralf Treinen wrote: Is it OK to distribute a script, which is - licencend under GPL. - intended to be executed by a non-free interpreter. [..] When I sent my ITP on debian-devel today, Moshe Zadka claimed that even distributing maria-viz would be illegal. http://lists.debian.org/debian-devel/2002/debian-devel-200208/msg00188.html Can please someone advise whether this is really the case? I do not believe the Free Software Foundation interprets the GPL in this manner. After all, some GNU software includes code that is only intended to work with non-free compilers and make implementations. I believe there is GPL'ed software in contrib that requires certain (non-free) Java class libraries as well. The issue in the case of this program is perhaps even more narrowly cast, since there is a free alternative to (at least some of) graphviz (http://www.chaosreigns.com/code/springgraph/), and it is entirely possible to develop a free alternative for the particular interpreter in question. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765 pgpLeAT7n8agw.pgp Description: PGP signature
RE: GPL-script to be run on a non-free interpreter
To take Chris Lawrence's post a step further, what is the difference between having a pound-bang line for a non-free interpreter and executing a GPL binary on a closed source system? It is permissible for libc to be non-free and a program to use it. The closed system's kernel is for all intents and purposes an interpreter. I think this is simply ideology getting in the way.
Re: GPL-script to be run on a non-free interpreter
On Sun, Aug 04, 2002 at 05:58:19PM +0200, Ralf Treinen wrote: Is it OK to distribute a script, which is - licencend under GPL. - intended to be executed by a non-free interpreter. Background: I'm intending to package maria (ITP at bug #146320), which is licenced under GPL. Besides the main tool, called maria, it also contains a script, called maria-vis, which can be used to visualise the output of maria. It is a script for the lefty interpreter, which is part of the non-free graphviz package. The first line of maria-vis is #!/usr/bin/lefty I was intending to split maria into several binary packages, in particular - maria: the core. Goes into main, suggests maria-vis - maria-vis: the mentioned script + manpage. Goes into contrib, depends on graphviz. When I sent my ITP on debian-devel today, Moshe Zadka claimed that even distributing maria-viz would be illegal. http://lists.debian.org/debian-devel/2002/debian-devel-200208/msg00188.html Can please someone advise whether this is really the case? It is ok to redistribute it by itself; if you distribute it with the interpreter (which is the case in Debian), I believe the GPL requires you to also distribute the interpreter's source under the GPL. Therefore, if the interpreter is not GPL-compatible, the letter of the GPL says you cannot distribute this script in Debian. However, you can do so easily if you get an exemption from the author saying it's ok to distribute it with the lefty interpreter in spite of the interpreter's license. Legally, this is the least ambiguous solution, so I recommend seeking this license exception from the author to prevent future objections. Steve Langasek postmodern programmer pgpUZ740KYEDh.pgp Description: PGP signature
Re: GPL-script to be run on a non-free interpreter
On Sun, Aug 04, 2002 at 10:14:59AM -0700, Sean 'Shaleh' Perry wrote: To take Chris Lawrence's post a step further, what is the difference between having a pound-bang line for a non-free interpreter and executing a GPL binary on a closed source system? It is permissible for libc to be non-free and a program to use it. The closed system's kernel is for all intents and purposes an interpreter. None whatsoever -- which is why, in both cases, shipping the GPLed work WITH the GPL-incompatible component it depends on is prohibited. I think this is simply ideology getting in the way. Odd, I thought ideology was the point of the GPL. ;) Steve Langasek postmodern programmer pgp3Jv2kUVujx.pgp Description: PGP signature
Re: GPL-script to be run on a non-free interpreter
On Sun, 2002-08-04 at 12:47, Steve Langasek wrote: On Sun, Aug 04, 2002 at 05:58:19PM +0200, Ralf Treinen wrote: When I sent my ITP on debian-devel today, Moshe Zadka claimed that even distributing maria-viz would be illegal. http://lists.debian.org/debian-devel/2002/debian-devel-200208/msg00188.html Can please someone advise whether this is really the case? It is ok to redistribute it by itself; if you distribute it with the interpreter (which is the case in Debian), I believe the GPL requires you to also distribute the interpreter's source under the GPL. Therefore, if the interpreter is not GPL-compatible, the letter of the GPL says you cannot distribute this script in Debian. Forgive my ignorance, but is this the general policy for GPL packages in contrib that depend on packages in non-free? It's been often quoted that contrib and non-free are not part of Debian; I'm wondering if this determination has an effect on the licensing question. The idea in my head is that contrib and non-free are separate. Of course, if you create a contrib/non-free CD, you might have problems, but I thought that Debian didn't make any guarantees about third-party distribution of non-free. However, you can do so easily if you get an exemption from the author saying it's ok to distribute it with the lefty interpreter in spite of the interpreter's license. Legally, this is the least ambiguous solution, so I recommend seeking this license exception from the author to prevent future objections. I can't argue with this logic, no matter the conclusion of my previous question.
Re: GPL-script to be run on a non-free interpreter
Steve Langasek [EMAIL PROTECTED] writes: It is ok to redistribute it by itself; if you distribute it with the interpreter (which is the case in Debian), I believe the GPL requires you to also distribute the interpreter's source under the GPL. What clause of the GPL requires you to do this? It seems that this link is apropos: http://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat -- Alan Shutko [EMAIL PROTECTED] - In a variety of flavors! In cyberspace no one can hear your stomach rumble.
Re: Font license recommendation
On Fri, 2002-08-02 at 17:24, Lars Hellström wrote: It odd to see such a conviction that this is aggregation, which is harmless here on this list, considering that it was recently claimed that a tarball (!) must be considered to be single work until proof of the contrary has been obtained, without any objections from the regulars. Can anyone think of any use other than aggregation for a tarball? But perhaps there are double standards at work ... I argued that a tarball must be considered a derived work, but I was arguing in reference to the LPPL, not the GPL. The draft of the LPPL under discussion at that point had no mere aggregation clause. There is no question that a tarball is a derived work of the files contained within it. The GPL, however, allows that its conditions concerning derived works need not hold to mere aggregations, which allows the kinds of discussions we're having here. The LPPL does not allow these kinds of discussions, however, because it lacks a similar clause.
Re: GPL-script to be run on a non-free interpreter
On Sun, Aug 04, 2002 at 02:59:17PM -0400, Alan Shutko wrote: Steve Langasek [EMAIL PROTECTED] writes: It is ok to redistribute it by itself; if you distribute it with the interpreter (which is the case in Debian), I believe the GPL requires you to also distribute the interpreter's source under the GPL. What clause of the GPL requires you to do this? The GPL's definition of source code is: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Interpreters are not explicitly mentioned anywhere in the definition, but their function is most similar to compilers and kernels -- the major components of the operating system on which the executable runs. There is sufficient ambiguity that I believe obtaining an explicit license exception is safest for all involved. It seems that this link is apropos: http://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat The question presented there is, If a programming language interpreter has a license that is incompatible with the GPL, can I run GPL-covered programs on it?, but running such programs is not the issue -- distributing them is. In light of the wording of the GPL, that FAQ answer seems to only cloud the issue, IMHO. It is also based on the FSF's interpretation of the GPL; their interpretation is not legally authoritative, particularly when they don't hold the copyright on the work in question. Steve Langasek postmodern programmer pgpdZ0wCMdqWG.pgp Description: PGP signature
Re: GPL-script to be run on a non-free interpreter
On Sun, Aug 04, 2002 at 01:57:52PM -0500, Jeff Licquia wrote: On Sun, 2002-08-04 at 12:47, Steve Langasek wrote: On Sun, Aug 04, 2002 at 05:58:19PM +0200, Ralf Treinen wrote: When I sent my ITP on debian-devel today, Moshe Zadka claimed that even distributing maria-viz would be illegal. http://lists.debian.org/debian-devel/2002/debian-devel-200208/msg00188.html Can please someone advise whether this is really the case? It is ok to redistribute it by itself; if you distribute it with the interpreter (which is the case in Debian), I believe the GPL requires you to also distribute the interpreter's source under the GPL. Therefore, if the interpreter is not GPL-compatible, the letter of the GPL says you cannot distribute this script in Debian. Forgive my ignorance, but is this the general policy for GPL packages in contrib that depend on packages in non-free? It's been often quoted that contrib and non-free are not part of Debian; I'm wondering if this determination has an effect on the licensing question. The idea in my head is that contrib and non-free are separate. Of course, if you create a contrib/non-free CD, you might have problems, but I thought that Debian didn't make any guarantees about third-party distribution of non-free. The ignorance appears to have been mine; I assumed that the interpreter was GPL-incompatible, but still free. If it's non-free, then we don't risk shipping them together, since non-free, main, and contrib are each regarded separately, and Debian does not ship non-free as part of the standard CD sets. We even go so far as to warn distributors about the potential legal tangles of shipping non-free; this is just one more. Steve Langasek postmodern programmer pgpanzmjeRGCA.pgp Description: PGP signature
Re: GPL-script to be run on a non-free interpreter
Steve Langasek [EMAIL PROTECTED] writes: The GPL's definition of source code is: Clause 3 means that if you ship an executable or object code form of a work, you do not need to ship the compiler and kernel source unless you are including the compiler or kernel with the executable. Debian would not be shipping an executable or object code form of a script, since the script _is_ source, therefore distribution would fall under clause 2, which has no such problems. I could see this being a problem with a non-free language with something like the perl compiler or Emacs byte-compiler, if we only shipped compiled versions, but it isn't a problem here. -- Alan Shutko [EMAIL PROTECTED] - In a variety of flavors! The Illuminati aren't out to get you. What was your name?
Re: copyright violation in libflash
Hi Aubin, On Sun, Aug 04, 2002 at 10:13:39AM -0500, Aubin Paul wrote: Thanks for bring this to my attention; I agree that we should remove the package, as I checked the two files and both mention that they are derived from sample code. I can't believe I didn't see that; I thought the only copyright violation was the old header from Mozilla which was replaced. good luck. Hope that Oliver brings a solution soon.. P.S. Is Oliver using my patches? I think so, I sent them a while ago and he accepted them -- Robert Millan 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5 Andrew S. Tanenbaum, 30 Jan 1992
Re: Font license recommendation
At 00.53 +0200 2002-08-03, Thomas Bushnell, BSG wrote: Lars Hellström [EMAIL PROTECTED] writes: I doubt this argument could work. However if it did then it certainly would provide a technical solution to the (obnoxious?) GPL incompatibility problem: just design the linker so that it pads the executable with markup saying beginning/end of material that is part of the work XXX, and then claim the file is an aggrevation of different works, which just happens to be interpreted as an executable program by the OS. Since things like intention matter--and not just technical mechanism--this is just FUD. FUD ? On what do you base your opinion that intent has any significance for whether the GPL allows an action? It clearly says You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. and I don't see any reference in it to the intent of the licensee (only to the intent of the license, but that is something quite different). Furthermore I don't see that there would necessarily be any difference in intent. Certainly if one writes a program whose only purpose is to demonstrate a legal loophole there would be a difference in intent, but that isn't the interesting case. In the interesting case the intent is to make a single file program, incorporating various pieces of free software (some of which are GPL and some of which are GPL-incompatible), that does X. The X could be to display a certain picture; PS files can have this intent, but there are also C programs with the same intent. And just to make sure we're clear on what my point is: Incorporating a GPLed font in a PS document does, in contrast to what you claimed, have (in many cases) unwanted legal implications; if it didn't then there would be a simple workaround for GPL-incompatibility. Lars Hellström
Bug#155396: ITP: iso-codes -- Collection of ISO code lists and their translations
Package: wnpp Version: N/A; reported 2002-08-04 Severity: wishlist * Package name: iso-codes Version : 1.0 Upstream Author : Alastair McKinstry [EMAIL PROTECTED] * URL : http://www.saorleir.com/iso-codeshttp://www.saorleir.com/iso-codes * License : GPL Description : Collection of ISO code lists and their translations This package is (to be) a collection of ISO code lists: - ISO 639 Language codes - ISO 3166 Country codes - ISO 3166-2 country code subdivisions - ISO 4217 Currency codes and their translations (50+ languages so far). This is very problematic. First place, I don't see where we can distribute ISO 3166-2 _at all_. See http://www.din.de/gremien/nas/nabd/iso3166ma/ where ISO 3166-2 is only offered for sale. Secondly, I don't see how we can relicense the others - under an indeterminate license - and their derivatives (translations) under the GPL. It also seems counter-productive; more than GPL programs need to use these.
Re: Font license recommendation
On Sun, 2002-08-04 at 17:53, Lars Hellström wrote: At 00.53 +0200 2002-08-03, Thomas Bushnell, BSG wrote: Lars Hellström [EMAIL PROTECTED] writes: I doubt this argument could work. However if it did then it certainly would provide a technical solution to the (obnoxious?) GPL incompatibility problem: just design the linker so that it pads the executable with markup saying beginning/end of material that is part of the work XXX, and then claim the file is an aggrevation of different works, which just happens to be interpreted as an executable program by the OS. Since things like intention matter--and not just technical mechanism--this is just FUD. FUD ? On what do you base your opinion that intent has any significance for whether the GPL allows an action? Well, there's this: The source code for a work means the preferred form of the work for making modifications to it. (section 3) Preferred is an intent, last time I checked. It's used against people who use obfuscators on their source before distribution, for example, because no one in their right mind would intend to edit the obfuscated source to add features or fix bugs. There's also this: The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. What the Program does is also intent. Incidentally, the latter paragraph also provides reason to believe that a PostScript file generated using a GPL font does not become tainted with the source requirements of the GPL. (No, it's not clear-cut; I'm not necessarily arguing that it's the case, just that it's possible.) It clearly says You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. and I don't see any reference in it to the intent of the licensee (only to the intent of the license, but that is something quite different). That's because intent is a subject of other parts of the license. Furthermore I don't see that there would necessarily be any difference in intent. Certainly if one writes a program whose only purpose is to demonstrate a legal loophole there would be a difference in intent, but that isn't the interesting case. In the interesting case the intent is to make a single file program, incorporating various pieces of free software (some of which are GPL and some of which are GPL-incompatible), that does X. The X could be to display a certain picture; PS files can have this intent, but there are also C programs with the same intent. Well, let's take the Gimp. It processes one image file into another, and is GPLed. Does that have any implication on the legal status of either image? What if the original is GPLed? Especially given that most image formats are their own preferred format for modification, things are not so clear as they might seem. One could make the case that a font is an interpreted language, with the font renderer as the interpreter. In that case, a rendered glyph could be considered output from the Program. OTOH, the font could be considered data that is input by a font renderer; in that case, the rendered glyphs could be considered derived works. Then again, if you're using the Gimp to create a PNG with text rendered in a GPLed font, it wouldn't matter; the PNG file is its own preferred format. But an EPS or SVG might, especially if the font is required to process the file properly. Indeed, a vector image file format could itself be described as a program; PostScript is even considered Turing complete, if my memory serves me. But what if you convert a PNG to an EPS, and add some text with a GPLed font? What constitutes the source? If the PNG is proprietary, have you just violated the GPL? The details of embedding could even make a difference. One could embed bitmaps generated by the font instead of the font itself, which would clearly be output from the Program. Bitmap fonts would themselves be in the preferred form, so their licensing status might not matter; at that point, what would it matter if the fonts were embedded in another file? In short, I don't think the question is as simple as you make it. And just to make sure we're clear on what my point is: Incorporating a GPLed font in a PS document does, in contrast to what you claimed, have (in many cases) unwanted legal implications; if it didn't then there would be a simple workaround for GPL-incompatibility. That's entirely possible, but I remain unconvinced.
