Re: prozilla: Nonfree
On Thu, Jan 13, 2005 at 10:07:07AM +, MJ Ray wrote: > Brian Nelson <[EMAIL PROTECTED]> wrote: > > [...] I can only find it currently in 2 packages in > > Debian--prozilla and elinks. The others that used it in the past > > (libcurl, wget?) likely rewrote the code since it was obsolete anyway. > > Why not just take the code from one of those if it's really a concern? > > That seems like a good suggestion. Can you tell which parts > replaced it? >From src/Changelog: 2000-11-18 Jan Prikryl <[EMAIL PROTECTED]> * ftpparse.c, ftpparse.h: New files. * ftp-ls.c (ftp_parse_ls): Use ftp_parse_unix_ls for UNIX servers only. Use ftp_parse_nonunix_ls otherwise. (ftp_parse_nonunix_ls): Stub to the ftpparse library handling all exotic FTP servers. * ftp.h (stype): New enum, distinguishes UNIX, VMS, and "other" FTP servers. And then later: 2001-02-13 Jan Prikryl <[EMAIL PROTECTED]> * ftp-ls.c (ftp_parse_ls): Added support of ST_MACOS (Unix-like listing without correct permissons). * ftp.h (stype): Added ST_MACOS to identify the NetPresenz MacOS FTP server. * ftp.c (ftp_retrieve_list): New mirroring logic: A remote file shall be donwloaded only when it's newer than the local copy or when it has the same timeestamp but its size is different. ST_VMS and ST_MACOS as special cases that lie about file size. * ftp-ls.c (ftp_parse_ls): Support for ST_MACOS. * Makefile.in: Removed dependency on ftpparse library due to unclear copyright issues and absence of any feedback to our queries. * ftp-ls.c: Removed dependency on ftpparse library due to unclear copyright issues and absence of any feedback to our queries. (ftp_parse_ls): Added a warning message when remote server system does not seem to be suported by wget. (ftp_parse_vms_ls): New function for parsing VMS ftp server listing output. So, ftp_parse_ls() is the functional equivalent of ftpparse(), though it's not a drop-in replacement. The design is a little different--for example, ftp_parse_ls() requires a server type as found from the SYST command, whereas ftpparse() seems to just guess the output on the fly. Still, it should be a relatively trivial switch. I suggest explaning to upstream that they have no clear right to use ftpparse in their code, and several other projects that once relied on it have purged it from their code as a result. Then point them to the wget code for a functional replacement. -- Society is never going to make any progress until we all learn to pretend to like each other.
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Måns Rullgård <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > >> "Michael K. Edwards" <[EMAIL PROTECTED]> writes: >> >>> [no longer relevant to debian-java, I think] >>> >>> On Thu, 13 Jan 2005 15:28:57 -0500, Brian Thomas Sniffen >>> <[EMAIL PROTECTED]> wrote: >>> [snip] You are ignoring the creative act performed by the programmer who arranged calls to functions within libc. That was creative effort on his part which critically involves a copy of libc. >>> >>> As is the creation of a critical essay on libc. But that's not a >>> derivative work either. >> >> But an annotated edition of libc is. A program seems far more similar >> to an annotated edition than to a critical essay -- since it includes >> a copy of the library, after all, and pointers into it. > > Now you stopped making sense. A program includes only references to a > library, not the library itself. The program makes neither functional nor creative sense without the library component. A binary -- which we usually think of as a program -- is only part of a program. All of the libraries included in it are part of it also; that's why we ship them along. > A distribution, e.g. Debian, might include both the program and the > library. I don't see a problem with distributing a collection of > programs, where some of them can be combined in ways that violate > some license, as long as all of them still have legitimate uses. I don't see a problem with that either. But the default library loaded for some soname should probably be legal to *distribute* as a combination with anything Debian is distributing set to load it. -- Brian Sniffen [EMAIL PROTECTED]
Re: Illustrating JVM bindings
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > These facilities include class loading, class instantiation, > synchronization, garbage collection (ie. you can trigger GC from within > your program), reflection (ie. you can ask VM "what are methods that > this class have?"). Those are features of the interpreter. The fact that the interpreter happens to be written in C as well as in Java doesn't matter here. This is what I meant about you leaning too much on your knowledge of how JVMs tend to be built. But everything you've listed here is an accident of the implementation of the JVM. > It is not possible to have a JVM w/o these facilities. > > Now, the FAQ says: > > "However, when the interpreter is extended to provide "bindings" to > other facilities (often, but not necessarily, libraries), the > interpreted program is effectively linked to the facilities it uses > through these bindings. So if these facilities are released under the > GPL, the interpreted program that uses them must be released in a > GPL-compatible way." What the FAQ is talking about is, for example, using JNI to access GNU Readline or GMP from a Java program using JNI. That is, it's pointing out that if you want to use the GPL'd Readline library, your application program must be distributed under the terms of the GPL. I'm not convinced the JVM does, but I suspect it's the case without the OS exception (which, of course, Debian can't use). -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: why is graphviz package non-free?
Matthew Garrett <[EMAIL PROTECTED]> writes: > Does anyone actually have any compelling reason for believing that the > literal interpretation is what was meant? I don't know what was meant, but I know what it should mean: imagine a work under a copyleft-like license, which insisted that all modifications and derived works had to be distributed under BSD-like licenses. It's sort of a copywrong, since the original author can collect all the modifications and sell proprietary licenses to them. Should this be considered free? I can't see it as free. It's very clear that recipients are being charged for the ability to modify the software. They aren't on a plane with the original author. This is a root problem similar to that of the FSF's shenanigans with GFDL and GPL'd text, and the reason I object to their use of the GFDL: when only a copyright holder can do some things, that's non-Free. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, Jan 13, 2005 at 12:21:51PM -0500, Brian Thomas Sniffen wrote:
> Måns Rullgård <[EMAIL PROTECTED]> writes:
>
> > The program vim contains a list of function names, all of which are
> > found in the ISO C standard, or in one of POSIX, SuS etc. It also
> > mentions a soname similar to libc.so.6. Please explain how that can
> > form a copy of libc.
>
> That doesn't. The actual copy of libc there on disk and loaded into
> memory does. The fact that the collection of programs {vim, emacs,
> tcsh} has had the common factor libc compressed out has nothing to do
> with it.
You mean libc.so.12, as found on my Nienna system?
(Okay, so I haven't got all the build dependancies for vim completed yet,
but somehow, I have a sneaking suspicion that GNU libc will, oddly enough,
utterly fail to appear anywhere when I get that far; certainly it doesn't
on nvi...)
> > In the case of Java, the binding is even looser. A class might
> > contain references to other classes which the JVM is free to look for
> > anywhere it pleases. AFAIK, Eclipse uses only the standard Java API
> > as published by Sun, and will run equally well with any implementation
> > of said interface.
>
> Great -- which implementation does Debian ship it with? That's all
> that really matters.
Excellent question. See above (for some value of 'ship' and 'Debian'
which is not yet official, but certainly aims to be when complete).
--
Joel Aelwyn <[EMAIL PROTECTED]> ,''`.
: :' :
`. `'
`-
signature.asc
Description: Digital signature
Re: prozilla: Nonfree
On Thu, Jan 13, 2005 at 02:25:06AM -0800, Brian Nelson wrote: > On Thu, Jan 13, 2005 at 02:00:47AM -0800, Steve Langasek wrote: > > On Thu, Jan 13, 2005 at 01:30:52AM -0800, Brian Nelson wrote: > > > I can only find it currently in 2 packages in Debian--prozilla and elinks. > > > The others that used it in the past (libcurl, wget?) likely rewrote the > > > code since it was obsolete anyway. Why not just take the code from one of > > > those if it's really a concern? > > Why not? I see no reason why not; please, be my guest. > Because I'm not the one that sees a major legal problem with this bit of > code. :) I don't know that anyone here has asserted that this is a *major* legal problem. Problems do not have to be "major" for us to report them as bugs, or believe that they're worth fixing. Even minor legal problems still warrant the assumption of severity=serious, because if they come calling, the impact on our users is significant regardless of how *much* code we're infringing. > > In particular, prozilla seems a particularly silly piece of software to jump > > to the defense of, since it has RC security holes and doesn't look like it's > > coming anywhere close to shipping with sarge. > OK, but elinks also contains this file and otherwise *is* in shape for > sarge. Yes, and I think this package will also need to have a bug filed against it now that we're aware of it, and the matter investigated. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
OT: GPL section 4 termination clause
Grzegorz B. Prokopski wrote: And GPL also says, that the person who packages and then distributes breaks the rules of GPL, it has no longer right to distribute nor use the GPLed work. As an aside, what's to stop a party, having violated the GPL at some point (and therefore having had their rights under the GPL terminated by section four) from simply acquiring another copy of the work from someone who still has the right to distribute it under the GPL, and therefore 'automatically receiv[ing] a license from the original licensor'? Apologies for the tangent, but I've never been able to find an answer to this question, and it seems relevant to the debate: if it is truly the case that an entity can lose the right to distribute forever, then the Debian mirrors have already irrevocably lost the right to kaffe. -- Lewis Jardine IANAL, IANADD
Re: prozilla: Nonfree
On Thu, Jan 13, 2005 at 10:07:07AM +, MJ Ray wrote: > Brian Nelson <[EMAIL PROTECTED]> wrote: > > [...] I can only find it currently in 2 packages in > > Debian--prozilla and elinks. The others that used it in the past > > (libcurl, wget?) likely rewrote the code since it was obsolete anyway. > > Why not just take the code from one of those if it's really a concern? > > That seems like a good suggestion. Can you tell which parts > replaced it? >From src/Changelog: 2000-11-18 Jan Prikryl <[EMAIL PROTECTED]> * ftpparse.c, ftpparse.h: New files. * ftp-ls.c (ftp_parse_ls): Use ftp_parse_unix_ls for UNIX servers only. Use ftp_parse_nonunix_ls otherwise. (ftp_parse_nonunix_ls): Stub to the ftpparse library handling all exotic FTP servers. * ftp.h (stype): New enum, distinguishes UNIX, VMS, and "other" FTP servers. And then later: 2001-02-13 Jan Prikryl <[EMAIL PROTECTED]> * ftp-ls.c (ftp_parse_ls): Added support of ST_MACOS (Unix-like listing without correct permissons). * ftp.h (stype): Added ST_MACOS to identify the NetPresenz MacOS FTP server. * ftp.c (ftp_retrieve_list): New mirroring logic: A remote file shall be donwloaded only when it's newer than the local copy or when it has the same timeestamp but its size is different. ST_VMS and ST_MACOS as special cases that lie about file size. * ftp-ls.c (ftp_parse_ls): Support for ST_MACOS. * Makefile.in: Removed dependency on ftpparse library due to unclear copyright issues and absence of any feedback to our queries. * ftp-ls.c: Removed dependency on ftpparse library due to unclear copyright issues and absence of any feedback to our queries. (ftp_parse_ls): Added a warning message when remote server system does not seem to be suported by wget. (ftp_parse_vms_ls): New function for parsing VMS ftp server listing output. So, ftp_parse_ls() is the functional equivalent of ftpparse(), though it's not a drop-in replacement. The design is a little different--for example, ftp_parse_ls() requires a server type as found from the SYST command, whereas ftpparse() seems to just guess the output on the fly. Still, it should be a relatively trivial switch. I suggest explaning to upstream that they have no clear right to use ftpparse in their code, and several other projects that once relied on it have purged it from their code as a result. Then point them to the wget code for a functional replacement. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Måns Rullgård <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > >> "Michael K. Edwards" <[EMAIL PROTECTED]> writes: >> >>> [no longer relevant to debian-java, I think] >>> >>> On Thu, 13 Jan 2005 15:28:57 -0500, Brian Thomas Sniffen >>> <[EMAIL PROTECTED]> wrote: >>> [snip] You are ignoring the creative act performed by the programmer who arranged calls to functions within libc. That was creative effort on his part which critically involves a copy of libc. >>> >>> As is the creation of a critical essay on libc. But that's not a >>> derivative work either. >> >> But an annotated edition of libc is. A program seems far more similar >> to an annotated edition than to a critical essay -- since it includes >> a copy of the library, after all, and pointers into it. > > Now you stopped making sense. A program includes only references to a > library, not the library itself. The program makes neither functional nor creative sense without the library component. A binary -- which we usually think of as a program -- is only part of a program. All of the libraries included in it are part of it also; that's why we ship them along. > A distribution, e.g. Debian, might include both the program and the > library. I don't see a problem with distributing a collection of > programs, where some of them can be combined in ways that violate > some license, as long as all of them still have legitimate uses. I don't see a problem with that either. But the default library loaded for some soname should probably be legal to *distribute* as a combination with anything Debian is distributing set to load it. -- Brian Sniffen [EMAIL PROTECTED]
Re: Illustrating JVM bindings
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > These facilities include class loading, class instantiation, > synchronization, garbage collection (ie. you can trigger GC from within > your program), reflection (ie. you can ask VM "what are methods that > this class have?"). Those are features of the interpreter. The fact that the interpreter happens to be written in C as well as in Java doesn't matter here. This is what I meant about you leaning too much on your knowledge of how JVMs tend to be built. But everything you've listed here is an accident of the implementation of the JVM. > It is not possible to have a JVM w/o these facilities. > > Now, the FAQ says: > > "However, when the interpreter is extended to provide "bindings" to > other facilities (often, but not necessarily, libraries), the > interpreted program is effectively linked to the facilities it uses > through these bindings. So if these facilities are released under the > GPL, the interpreted program that uses them must be released in a > GPL-compatible way." What the FAQ is talking about is, for example, using JNI to access GNU Readline or GMP from a Java program using JNI. That is, it's pointing out that if you want to use the GPL'd Readline library, your application program must be distributed under the terms of the GPL. I'm not convinced the JVM does, but I suspect it's the case without the OS exception (which, of course, Debian can't use). -Brian -- Brian Sniffen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why is graphviz package non-free?
Matthew Garrett <[EMAIL PROTECTED]> writes: > Does anyone actually have any compelling reason for believing that the > literal interpretation is what was meant? I don't know what was meant, but I know what it should mean: imagine a work under a copyleft-like license, which insisted that all modifications and derived works had to be distributed under BSD-like licenses. It's sort of a copywrong, since the original author can collect all the modifications and sell proprietary licenses to them. Should this be considered free? I can't see it as free. It's very clear that recipients are being charged for the ability to modify the software. They aren't on a plane with the original author. This is a root problem similar to that of the FSF's shenanigans with GFDL and GPL'd text, and the reason I object to their use of the GFDL: when only a copyright holder can do some things, that's non-Free. -Brian -- Brian Sniffen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, Jan 13, 2005 at 12:21:51PM -0500, Brian Thomas Sniffen wrote:
> Måns Rullgård <[EMAIL PROTECTED]> writes:
>
> > The program vim contains a list of function names, all of which are
> > found in the ISO C standard, or in one of POSIX, SuS etc. It also
> > mentions a soname similar to libc.so.6. Please explain how that can
> > form a copy of libc.
>
> That doesn't. The actual copy of libc there on disk and loaded into
> memory does. The fact that the collection of programs {vim, emacs,
> tcsh} has had the common factor libc compressed out has nothing to do
> with it.
You mean libc.so.12, as found on my Nienna system?
(Okay, so I haven't got all the build dependancies for vim completed yet,
but somehow, I have a sneaking suspicion that GNU libc will, oddly enough,
utterly fail to appear anywhere when I get that far; certainly it doesn't
on nvi...)
> > In the case of Java, the binding is even looser. A class might
> > contain references to other classes which the JVM is free to look for
> > anywhere it pleases. AFAIK, Eclipse uses only the standard Java API
> > as published by Sun, and will run equally well with any implementation
> > of said interface.
>
> Great -- which implementation does Debian ship it with? That's all
> that really matters.
Excellent question. See above (for some value of 'ship' and 'Debian'
which is not yet official, but certainly aims to be when complete).
--
Joel Aelwyn <[EMAIL PROTECTED]> ,''`.
: :' :
`. `'
`-
signature.asc
Description: Digital signature
OT: GPL section 4 termination clause
Grzegorz B. Prokopski wrote: And GPL also says, that the person who packages and then distributes breaks the rules of GPL, it has no longer right to distribute nor use the GPLed work. As an aside, what's to stop a party, having violated the GPL at some point (and therefore having had their rights under the GPL terminated by section four) from simply acquiring another copy of the work from someone who still has the right to distribute it under the GPL, and therefore 'automatically receiv[ing] a license from the original licensor'? Apologies for the tangent, but I've never been able to find an answer to this question, and it seems relevant to the debate: if it is truly the case that an entity can lose the right to distribute forever, then the Debian mirrors have already irrevocably lost the right to kaffe. -- Lewis Jardine IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox/Thunderbird trademarks: a proposal
Change "the name of the package will have to be changed" to "the Mozilla Foundation reserves the right to withdraw license to its trademarks" and I think it's completely unobjectionable. IANADD, IANAL. Thanks to Gervase for being such a pro. Cheers, - Michael
Re: Questions about legal theory behind (L)GPL
On Thu, 13 Jan 2005 22:00:05 +, Henning Makholm <[EMAIL PROTECTED]> wrote: > I got lost somewhere along the way: Why is it important to you whether > the GPL is a "contract" or not? To me, personally? It bugs me to see needless conflicts within the Free Software world caused by GPL interpretations that have no foundation in law. IANAL, but I've been following the relevant case law on and off for years, as a matter of self-defense, and the FSF's positions on this and other issues look to me to be increasingly untenable and major obstacles to the very ideals of programmer freedom they profess. It's a sad way for a formerly admirable and effective organization to devolve, and I hope that it's reversible through reasoned argument. I have no axe to grind here, and I'm perfectly content not to use FSF copyright material in ways the FSF doesn't intend. I got into the whole topic again when the Linux Core Consortium proposal came up, and the "(L)GPL is not a contract" fiction was raised to justify why the LGPL fails to ban de facto consecration of "golden" binaries. The other issues in play -- whether drivers containing firmware download mechanisms have to go into contrib, whether GPL-incompatible Java code can be run on a GPL JVM, etc. -- have kept me engaged longer, and brought up more precedents, than I originally intended. > You don't have to convince me - in my home jurisdiction it is beyond > dispute that application of the GPL would be a matter for our contract > law, and I won't aspire to claim anything about how it works in a > common-law system. > > But the heat of the debate nevertheless leaves me wondering what it's > for. Does it make any difference, and if so, what? In US jurisdictions very different standards apply to actions under contract and under tort, and in particular under the tort of copyright infringement. If a plaintiff can demonstrate a likelihood of success on the facts of copyright infringement, then he is entitled to an automatic presumption that irreparable harm will come of allowing the defendant to continue publishing the infringing work while the case is fully argued, and that presumption is quite hard to rebut. That's the "big stick" that the FSF tries to wave over those who misuse (in their opinion) GPL material -- disruption of their business through preliminary injunction while the case grinds its way through court. The FSF's position would be subject to much closer scrutiny under contract law in other respects as well. As a matter of law, ambiguities in a contract have to be construed against the offeror, because it is presumed that the offeror could have written the terms of the contract to be as favorable to himself as the offeree would tolerate. Statutory overrides and principles of equity may be used to alter the contract provisions and find additional implied provisions during the court's interpretation of its text. And the remedies applied are subject to pragmatic tests such as the "balance of harms" and reasonable standards of "cure of breach". Under either legal standard, I don't believe that linking GPL and non-GPL material creates a derivative work in violation of the actual terms of the GPL. But that's another debate. Cheers, - Michael
Re: how to mention GPL in the debian/copyright file
Scripsit Joey Hess <[EMAIL PROTECTED]> > Henning Makholm wrote: >> > found in /usr/share/debhelper/dh_make/native/copyright", which turn out >> this notice happens to be identical to the blurb you quoted from >> debhelper > Debhelper does not contain such a GPL copyright blurb. Sorry. Damn dh-make's creative installation directory choices. -- Henning Makholm "Der er ingen der sigter på slottet. D'herrer konger agter at triumfere fra balkonen når de har slået hinanden ihjel."
Re: how to mention GPL in the debian/copyright file
Scripsit Jochen Voss <[EMAIL PROTECTED]> > On Thu, Jan 13, 2005 at 10:25:58PM +, Henning Makholm wrote: >> What you should include is the exact notice found in the upstream >> source which says that the program is covered by the GPL. > Does this mean we need all the notes from the source files with > duplicates removed? Yes. All authors who claim copyright in a source file should be credited in the Debian copyright file, together with the exact statement of license they issued. For many free licences this is a legal requirement, because the notices in the source are not shipped in the .deb otherwise, and even when it isn't it would be discourteous in extreme not to quote it anyway. This is what /usr/share/doc/*/copyright is _for_. > Does different white space count as being different? Current best practice is, as far as I'm aware, something like: 1. Minor formatting differences, including different styles of comment markup, line wrapping and other whitespace, can be compressed away in the copyright file. 2. Similarly, two authors who assert copyright but give identical license notices can be compressed into just giving both copyright assertions in the copyright file, followed by the common license notice. 3. Actual differences in wording should be preserved, even if they may seem insignificant to the packager, except perhaps where the difference is beyond any conceivable doubt due to a mere typo. > Do you have any reference for this? Policy section 12.5. A "verbatim copy of its copyright and distribution license" means just what it says. Policy perhaps neglects to explicitly point out that this applies simultaneously to every copyright [notice] and every distribution licence that covers the package, but I still think this can safely be left to the reader's imagination. > I find for example the appended notices. Should I replace my > text blurb by the concatenation of all these notices? Yes. See e.g. /usr/share/doc/xlibs/copyright for an example of how large this can be in complex cases, but it all has to be there. > PS.: I looked at the vroot.h license (last one in my list) which I > did not spot before. I think is is ok for our purposes. Do you agree? Yes, it looks like a minor rewording of the common 3-clause BSD license: > Permission to use, copy, modify, and distribute this software and > its documentation for any purpose and without fee is hereby > granted, provided that the above copyright notice appear in all > copies and that both that copyright notice and this permis- > sion notice appear in supporting documentation, and that the > name of Solbourne not be used in advertising > in publicity pertaining to distribution of the software without > specific, written prior permission. > > ANDREAS STOLCKE AND SOLBOURNE COMPUTER INC. DISCLAIMS ALL WARRANTIES > WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF > MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL ANDREAS STOLCKE > OR SOLBOURNE BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL > DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA > OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER > TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE > OR PERFORMANCE OF THIS SOFTWARE. -- Henning Makholm"I ... I have to return some videos."
JVM = interpreter + VM bindings
On Thu, 2005-13-01 at 18:18 -0500, Brian Thomas Sniffen wrote: > "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > > > On Thu, 2005-13-01 at 15:58 -0500, Raul Miller wrote: > >> On Thu, Jan 13, 2005 at 03:19:36PM -0500, Grzegorz B. Prokopski wrote: > >> > >> > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > >> > > >> > "However, when the interpreter is extended to provide "bindings" to > >> > other facilities (often, but not necessarily, libraries), the > >> ... > >> > Do you understand that an interpreter for Java IS such an interpreter > >> > that provides "bindings" to other facilities? > >> > >> But was Kaffe _extended_ to provide such bindings for Eclipse 3.0? > > > > This FAQ entry discusses 2 cases. One is when we have an interpreter, > > that basically goes over the pseudo-code and purely "interprets" it > > (an old BASIC interpreter would fit here). No Java VM/interpreter > > _ever_ fits in this first, simple casse. > > I think you're making untenable conclusions based on your knowledge of > accidents of implementation of Java VMs. Sorry about that, now that the flaming part is hopefully over, I'll be more than happy to give some more technically detailed informations. I've just posted a hopefuly more meaningful sketch of what the interconnections of program, java library, interpreter and its bindings are. > A Java bytecode interpreter is just an interpreter. The class > libraries matter, and the libraries exposed through the JNI interface > matter. Sure they do. But it's hard to agree (after seeing how complicated machinery a JVM is) that JVM is "just an interpreter". Actually the interpreter part of SableVM (that is, where you take bytecodes one by one and interpret them) is maybe 10-15% of it. > > On the contrary. A Java Virtual Machine (Java interpreter) inevitably > > has to provide such bindings to support Java specification. In other > > words the interpreter itself has to be extended with a library that > > provides these bindings to support Java specs. There's plenty of these > > bindings required to exist in core java.lang.* classes. > > This confuses me, though. Can you provide an unambiguous example? I'll do my best, and I'll try to show things that are not in any way SableVM-specific. Say a thread of your program acquired a lock (mutex, with a monitor in C) and wants to wait on it, until it's signalled by another thread. Your program has a VIRTUALCALL bytecode with reference to string "java.lang.Object.wait()". Interpreter will see the bytecode, read the string, make sure the object on which you're trying to invoke wait() does actually implement it, then it will see that it's a native method. It will therefore call a native (usually JNI) library, which is part of the JVM itself to find a function ie. Java_java_lang_Object_wait(). If a VM has moving garbage collector (SableVM, Sun, IBM, have) the first thing this function will do is to call "resuming_java()" function (this means "resuming java virtual machine internal code") to ensure that ie. garbage collection will not happen, which would result in objects being relocated. It will then proceed by checking whether the current thread actually owns the lock of the object on which it wants to wait() and will instantiate and throw an exception if it doesn't. Let's assume the excaption is to be thrown. Actually instantiating an exception for the first time will make use of a class loading facilities, which will have to go thru the hierarchy of class loaders. Ie. it might be that an application's class loader will be asked first to load the exeception class code, thus we'll be dumped back to the interpreter and it will invoke some of the application code. Then, after a class of the exception is loaded we will also have to instantiate it, thus if it contained any "static initializers" - they will need to be ran (again, we'll get back to the interpreter, which might execute any amount of code static initializer called, even including calling wait() or some other internal VM method again). So we saw the following boundary crossings: - Application is interpreted and calls java library - java library is interpreted and calls VM library binding - VM library method does some magic, possibly touching structures shared between the VM library part and interpreter - VM library calls interpreter again as a result of what happened - interpreter executes application or library code - this code can call the VM library again ... - ... The java library and the application of course can have their own native libraries that are being called under way, but this is not part of the discussion. Now, the VM library is pretty much always statically linked (is part of) to the "interpreter" part, because they often share many data structures. I have not shown an example, but even simple loading of the very first class of an application which is about to run requires interaction with VM library part. In s
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, Jan 13, 2005 at 08:25:49PM +0100, M?ns Rullg?rd wrote: > Andrew Suffield <[EMAIL PROTECTED]> writes: > > > On Thu, Jan 13, 2005 at 07:58:53PM +0100, M?ns Rullg?rd wrote: > >> >> Then how can things like thepiratebay.org be legal? > >> > > >> > They aren't with any degree of certainty. > >> > >> It's certain enough that Microsoft have failed to shut them down. > > > > They haven't tried. All Microsoft have done to them so far is send > > them some nastygrams in the mail. > > And for some reason you believe Microsoft would be content with that, > if they believed they had any real chance to stop them? It's sheer hubris to think that Microsoft cares about this site. There's a million others like it and one more doesn't make much difference. Pursuing it would merely use up time which their lawyers could instead have spent eroding our civil liberties. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Illustrating JVM bindings
> > Is this relevant to Eclipse? I was under the impression that Eclipse > > was pure java -- that it did not use JNI at all. > > > > If Eclipse does use JNI, would still a question about whether or not > > Kaffe's JNI implementation constitute some kind of extension designed > > to work around the GPL or whether they are some kind of implementation > > of some Java standard. On Thu, Jan 13, 2005 at 06:33:20PM -0500, Grzegorz B. Prokopski wrote: > I fail to see anything in the FAQ you cited above about extensions > designed to _work around GPL_. Please refrain from creating meanings. I believe the GPL takes precedence over the FAQ. And, no, I will not restrict my use of the english language words to literal quotes taken from a FAQ. If I've provided too much meaning for you to deal with, I feel some mild regret at inflicting such agony on you, but not so much regret that I'll start posting nonsense. > This is about the way Java works. You cannot merely interpret > bytecode. Sure I can. I've done it. Mind you, I'm not very fast when I interpret bytecode logically, but that wasn't your claim. > The program you're interpreting has to be able to call back > into the JVM (or if you wish into a JNI library that is bound to a VM) > to be able to run at all. http://google.com/search?q=define:jni When a java program uses JNI, you basically have to treat it as a non-java program, because it can use non-java facilities. However, a pure java program doesn't need to use JNI and the presence of JNI facilities in the interpreter is moot at that point. This case is typically simpler than the case of a non-java program, which is why JNI gets special mention -- so that the two cases aren't confused. > > > > Or is Eclipse 3.0 using only the facilities which Kaffe provides for > > > > arbitrary byte code? > > > > > > There is nothing in the FAQ that would suggest that these "facilities" > > > have to be provided for a specific program. > > > > There is nothing in the FAQ to suggest that a GPLed JNI implementation has > > to be a problem for arbitrary code, though of course it does point out JNI > > as a issue that can be a problem. But for problem resolution, the FAQ is > > saying that certain things need to be released in a GPL-compatible way, > > not that no release can happen. > > It says "if these facilities are released under the GPL, the interpreted > program that uses them must be released in a GPL-compatible way". Indeed. But I question whether the phrase "these facilities" is at all relevant to this context. Until I have some reason to believe that it is relevant, I don't find discussion of the consequences of releasing "these facilities" to be very interesting. > > > On the contrary. A Java Virtual Machine (Java interpreter) inevitably > > > has to provide such bindings to support Java specification. In other > > > words the interpreter itself has to be extended with a library that > > > provides these bindings to support Java specs. There's plenty of these > > > bindings required to exist in core java.lang.* classes. > > > > > > Hope this clarifies the issue, > > > > You seem to be claiming that a JVM has to provide non-standard JNI > > capabilities or it isn't a standard implementation of the JVM. > > I am sorry, but where do you see the "non-standard" is wrriten? I see it written two lines and five lines above this sentence. [You asked.] Now, if you'd have asked a relevant question I'd have made an effort to provide a relevant answer. But relevance has to do with concepts and ideas. A strong devotion to literal quotes won't get you there if you've abandoned the meaning of the material you're quoting. > The only part that would suggest somethign like that is "when the > interpreter is extended to provide "bindings" to other facilities". > > Is that the part you're referring to? No. I'm talking about my understanding of the significance of various aspects of computer programming technology within the scope of my understanding of the GPL, as they relate to the context being discussed in that part of the FAQ. While I'm prepared to restate my ideas using different words, if my words are a problem for you, I'm not prepared to pretend ignorance where it doesn't exist. Likewise, I'm not really prepared to pretend that I know about something I don't know about. Finally, while I'm prepared to admit my mistakes, if they're pointed out to me (and I do make mistakes, at times), I'm not going to pretend that <> is always a mistake. > I am trying to explain, since the very beginning, that it is not > possible for a Java interpreter not to provide these facilities that > are being called by the program being interpreted. Therefore *every* > JVM has to consists of an interpreter (be it JIT or ahead of time) > extended with these "callback" functions. I know that's what you're trying to explain. What I don't see is any convincing reason to believe that you are correct. However, take
Re: how to mention GPL in the debian/copyright file
Henning Makholm wrote: > > found in /usr/share/debhelper/dh_make/native/copyright", which turn out > > What you should include is the exact notice found in the upstream > source which says that the program is covered by the GPL. As far as I > can see from a random sample (src/fnmatch.c) from the source package, > this notice happens to be identical to the blurb you quoted from > debhelper Debhelper does not contain such a GPL copyright blurb. -- see shy jo, who will keep correcting people who confuse dh-make and debhelper forever, I suppose signature.asc Description: Digital signature
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, 2005-13-01 at 18:13 -0500, Brian Thomas Sniffen wrote: > "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > > Which Eclipse packages? The old ones we have in SID now? Irrelevant. > > There would have been nothing whatsoever to discuss in such case. > > > > The *new* Eclipse packages that are being prepared now and which we've > > been discussing (I already said it in another email, but you must > > have crossed yours) have it this way: > > > > Build-depends: kaffe > > Depends: kaffe | java2-runtime > > > > [ From http://kyoto.larvalstage.net/ubuntu/warty/ ] > > > > So a user who does either 'apt-get source eclipse' or 'apt-get install > > eclipse' will link (either at compilation time or at runtime) to Kaffe's > > Java library, and to Kaffe JVM bindings which are all GPL. > > > > I hope this clarifies _at least_ this issue. > > Can you clarify one more? Is Eclipse then just building as > well-specified JVM code, or is it linking against GPL'd class > libraries as well? I am unsure what you understand as "well-specified JVM code". But any Java application you compile (unless you're compiling the most and self-contained core classes) surely has to link to a java library, just as you cannot compile your application w/o having .so and .h files of a library you're linking to. In case of Kaffe at least the core part of the java libraries is GPLed, and yes, you have to link against it during compilation. > I don't actually know whether Kaffe is a JVM or > also includes the rest of the Java runtime environment. Kaffe includes a JVM along with java libraries. The whole JVM is GPLed, and part of the very core libraries also is. Kaffe also includes some tools (a compiler among others). Cheers, Grzegorz B. Prokopski -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> SableVM - Free, LGPL'ed Java VM http://sablevm.org Why SableVM ?!? http://sablevm.org/wiki/Features Debian GNU/Linux - the Free OS http://www.debian.org
Re: why is graphviz package non-free?
Glenn Maynard <[EMAIL PROTECTED]> wrote: > This has come up in the past, under the argument that requiring this violates > the "under the same terms as the license of the original software" provision > of DFSG#3: you aren't allowed to distribute modifications under the same > terms you received them, but instead must grant extra permissions. I'm still somewhat confused as to what DFSG 3 is meant to mean. As written, yes, it does sound like it's trying to prevent that sort of situation. But I've no real idea /why/ that sort of situation is supposed to be avoided. It was never discussed in the debian-private thread that lead to the DFSG being adopted. Bruce hasn't replied to my email asking what he meant it to mean. We've ended up with a sentence and nothing much in the way of meaning. Personally, I'm inclined to believe it was intended to mean "The license must allow modifications and derived works, and it must be possible to provide all recipients with a full set of DFSG rights". The current language has the advantage of not being self-referential, which might explain it to some extent. Does anyone actually have any compelling reason for believing that the literal interpretation is what was meant? -- Matthew Garrett | [EMAIL PROTECTED]
Illustrating JVM bindings
On Thu, 2005-13-01 at 17:24 -0500, Raul Miller wrote: > On Thu, Jan 13, 2005 at 04:35:50PM -0500, Grzegorz B. Prokopski wrote: > > > But was Kaffe _extended_ to provide such bindings for Eclipse 3.0? > > > > This FAQ entry discusses 2 cases. One is when we have an interpreter, > > that basically goes over the pseudo-code and purely "interprets" it > > (an old BASIC interpreter would fit here). No Java VM/interpreter > > _ever_ fits in this first, simple casse. > > The FAQ discusses far more than 2 cases. > > I imagine you're concerned about this part: > > If a programming language interpreter is released under the GPL, > does that mean programs written to be interpreted by it must be under > GPL-compatible licenses? > When the interpreter just interprets a language, the answer is > no. The interpreted program, to the interpreter, is just data; > a free software license like the GPL, based on copyright law, > cannot limit what data you use the interpreter on. You can run it > on any data (interpreted program), any way you like, and there are > no requirements about licensing that data to anyone. > > However, when the interpreter is extended to provide "bindings" > to other facilities (often, but not necessarily, libraries), the > interpreted program is effectively linked to the facilities it uses > through these bindings. So if these facilities are released under > the GPL, the interpreted program that uses them must be released in > a GPL-compatible way. The JNI or Java Native Interface is an example > of such a binding mechanism; libraries that are accessed in this way > are linked dynamically with the Java programs that call them. These > libraries are also linked with the interpreter. If the interpreter > is linked statically with these libraries, or if it is designed to > link dynamically with these specific libraries, then it too needs > to be released in a GPL-compatible way. > > > Second case is where the code being interpreted may request to access > > bindings provided by the JVM. In Java these are done thru JNI calls, > > so usually JVM itself is a JNI library that provides these bindings. > > > > So an interpreter has to be "extended" to provide these "bindings" to > > other facilities. In such case, as the FAQ states "the interpreted > > program is effectively linked to the facilities it uses through these > > bindings." > > Is this relevant to Eclipse? I was under the impression that Eclipse > was pure java -- that it did not use JNI at all. > > If Eclipse does use JNI, would still a question about whether or not > Kaffe's JNI implementation constitute some kind of extension designed > to work around the GPL or whether they are some kind of implementation > of some Java standard. I fail to see anything in the FAQ you cited above about extensions designed to _work around GPL_. Please refrain from creating meanings. This is about the way Java works. You cannot merely interpret bytecode. The program you're interpreting has to be able to call back into the JVM (or if you wish into a JNI library that is bound to a VM) to be able to run at all. > > > Or is Eclipse 3.0 using only the facilities which Kaffe provides for > > > arbitrary byte code? > > > > There is nothing in the FAQ that would suggest that these "facilities" > > have to be provided for a specific program. > > There is nothing in the FAQ to suggest that a GPLed JNI implementation has > to be a problem for arbitrary code, though of course it does point out JNI > as a issue that can be a problem. But for problem resolution, the FAQ is > saying that certain things need to be released in a GPL-compatible way, > not that no release can happen. It says "if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way". The IPL/APL are not GPL-compatible, that is, they cannot be released in a GPL-compatible way. These "facilities" of a java interpreter are (usually) available via JNI, which is basically a library call interface (no magic here). These library calls have to be used by any program that runs on a JVM. That library is usually part of JVM, and in the case we're discussing, is whole GPLed. According to the above citation, it imposes that you must be able to release a program (the one you're running on a JVM, the one that uses these bindings) in a GPL-compatible way. You cannot do it for a program that is GPL-incompatible. > > On the contrary. A Java Virtual Machine (Java interpreter) inevitably > > has to provide such bindings to support Java specification. In other > > words the interpreter itself has to be extended with a library that > > provides these bindings to support Java specs. There's plenty of these > > bindings required to exist in core java.lang.* classes. > > > > Hope this clarifies the issue, > > You seem to be claiming that a JVM has to provide
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, Jan 13, 2005 at 03:29:13PM -0800, Michael K. Edwards wrote: > copyrightable. To get at the cases the FSF is shooting for, they > would have to use terms of art instead of "derivative or collective > works", and would have to insert far more draconian provisions to > create an action for breach of contract when GPL and non-GPL works are > combined. I think we might disagree about which cases the FSF is shooting for. That they've provided a FAQ which states things a certain way probably has more to do with the questions they've been asked than it does the design intent of the GPL. -- Raul
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, 13 Jan 2005 18:21:52 -0500, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > "Michael K. Edwards" <[EMAIL PROTECTED]> writes: [snip] > > As is the creation of a critical essay on libc. But that's not a > > derivative work either. > > But an annotated edition of libc is. A program seems far more similar > to an annotated edition than to a critical essay -- since it includes > a copy of the library, after all, and pointers into it. A creatively human-annotated edition of the libc source code is certainly a derivative work if the source code has any expressive content at all (which I, NAL, think a court would certainly rule that it does). A creatively annotated edition of its header files may or may not be, to the extent that it can be defended as having used those header files entirely according to their functional aspect. A program that uses a libc binary through its published functional interface isn't, no matter what mechanical details of compiling against header files, linking statically or dynamically, etc. may be involved. At most it creates an uncopyrightable combination of the two. Copyright law protects expression, not function. It isn't even really the right tool to protect a software publisher's ownership right in binaries, which is one reason why most commercial software tries to force you to accept a license in order to use it. But even to the extent that binaries are copyrightable, and that copying and using a binary of libc requires a license under copyright, that's about libc itself and not a derivative work of libc. Cheers, - Michael
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > "Michael K. Edwards" <[EMAIL PROTECTED]> writes: > >> [no longer relevant to debian-java, I think] >> >> On Thu, 13 Jan 2005 15:28:57 -0500, Brian Thomas Sniffen >> <[EMAIL PROTECTED]> wrote: >> [snip] >>> You are ignoring the >>> creative act performed by the programmer who arranged calls to >>> functions within libc. That was creative effort on his part which >>> critically involves a copy of libc. >> >> As is the creation of a critical essay on libc. But that's not a >> derivative work either. > > But an annotated edition of libc is. A program seems far more similar > to an annotated edition than to a critical essay -- since it includes > a copy of the library, after all, and pointers into it. Now you stopped making sense. A program includes only references to a library, not the library itself. A distribution, e.g. Debian, might include both the program and the library. I don't see a problem with distributing a collection of programs, where some of them can be combined in ways that violate some license, as long as all of them still have legitimate uses. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, 13 Jan 2005 17:02:52 -0500, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: [snip] > Why are copies OK, and derivative works not? I see GPL 2b talking > about any work that in whole or in part contains the Program. > Eclipse+Kaffe contains Kaffe, GPL 2 then exempts mere aggregation -- > which this is not. It also exempts separate sections *when > distributed separately* -- and explicitly covers them when the Program > is distributed as a whole. GPL section 2 is all about "works based on the Program", read in the context of copyright law. Later in that section, it says that "the intent is to exercise the right to control the distribution of derivative or collective works based on the Program." Eclipse+Kaffe isn't a "work based on the Program" because it isn't copyrightable as a derivative or collective work. In other words, you can't combine Eclipse and Kaffe, by running Eclipse on Kaffe, and then sue me for copyright infringement for doing the same. The "mere aggregation ... on a volume of storage or distribution medium" bit may clarify the contract writer's intent to some degree, but it doesn't automatically make other ways of combining two works copyrightable. To get at the cases the FSF is shooting for, they would have to use terms of art instead of "derivative or collective works", and would have to insert far more draconian provisions to create an action for breach of contract when GPL and non-GPL works are combined. > That feels like it's written to address this particular case -- or at > least a tarball containing Kaffe and Eclipse. This is similar enough > to count, it's just a funny compression scheme. It's written to address that case, all right; but I think that it's irrelevant and that the FSF is trying (unsuccessfully) to have it both ways. By inserting the "mere aggregation is OK" clause, and by publishing an aggressive stance on other forms of combination in their FAQ, the FSF tries to control interpretation and distract from the fact that courts will interpret "derivative or collective works" according to their meaning in the copyright law context that the preamble proclaims. Meanwhile, they claim the existence of a "law of license" outside contract law (with no basis that I can find), trying to avoid contract law standards such as "balance of harms" and take advantage of the relative ease of obtaining a preliminary injunction under copyright law. As I have detailed previously, the Progress Software v. MySQL case makes it pretty clear that they don't succeed in avoiding contract law standards once they actually get into court. Also, the judge in that case didn't rule on the factual issue of whether Progress Software had created a derivative work, but did make it quite clear that the FSF has no more authority on that point than any other expert witness that files an affidavit. The question "does linking create a derivative work" won't really be settled in the US unless and until a new case arises, is adjudicated in a court of fact, is appealed, and is properly analyzed with reference to precedent by a circuit court. I think (IANAL) that the outcome is quite predictable in light of precedents I have cited from several circuits. Ultimately, linking against the public interface to a published library doesn't detract from the rights in authorship that copyright law was created to protect, and US appellate courts are surprisingly good at sticking to the purpose of copyright in the face of legal and technical contortions that attempt to leverage a copyright monopoly beyond its legitimate bounds. Cheers, - Michael
Re: Firefox/Thunderbird trademarks: a proposal
Change "the name of the package will have to be changed" to "the Mozilla Foundation reserves the right to withdraw license to its trademarks" and I think it's completely unobjectionable. IANADD, IANAL. Thanks to Gervase for being such a pro. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Michael K. Edwards" <[EMAIL PROTECTED]> writes: > [no longer relevant to debian-java, I think] > > On Thu, 13 Jan 2005 15:28:57 -0500, Brian Thomas Sniffen > <[EMAIL PROTECTED]> wrote: > [snip] >> You are ignoring the >> creative act performed by the programmer who arranged calls to >> functions within libc. That was creative effort on his part which >> critically involves a copy of libc. > > As is the creation of a critical essay on libc. But that's not a > derivative work either. But an annotated edition of libc is. A program seems far more similar to an annotated edition than to a critical essay -- since it includes a copy of the library, after all, and pointers into it. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > On Thu, 2005-13-01 at 15:58 -0500, Raul Miller wrote: >> On Thu, Jan 13, 2005 at 03:19:36PM -0500, Grzegorz B. Prokopski wrote: >> >> > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL >> > >> > "However, when the interpreter is extended to provide "bindings" to >> > other facilities (often, but not necessarily, libraries), the >> ... >> > Do you understand that an interpreter for Java IS such an interpreter >> > that provides "bindings" to other facilities? >> >> But was Kaffe _extended_ to provide such bindings for Eclipse 3.0? > > This FAQ entry discusses 2 cases. One is when we have an interpreter, > that basically goes over the pseudo-code and purely "interprets" it > (an old BASIC interpreter would fit here). No Java VM/interpreter > _ever_ fits in this first, simple casse. I think you're making untenable conclusions based on your knowledge of accidents of implementation of Java VMs. A Java bytecode interpreter is just an interpreter. The class libraries matter, and the libraries exposed through the JNI interface matter. > On the contrary. A Java Virtual Machine (Java interpreter) inevitably > has to provide such bindings to support Java specification. In other > words the interpreter itself has to be extended with a library that > provides these bindings to support Java specs. There's plenty of these > bindings required to exist in core java.lang.* classes. This confuses me, though. Can you provide an unambiguous example? -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: how to mention GPL in the debian/copyright file
On Thu, 13 Jan 2005, Henning Makholm wrote: > Scripsit Jochen Voss <[EMAIL PROTECTED]> > > Recently Justin Pryzby filed bug #290087 against chbg, claiming > > that the debian/copyright file should instead contain "the 3 > > paragraphs as found in > > /usr/share/debhelper/dh_make/native/copyright", which turn out to > > be > > [snip standard GPL blob] > > > 1) Is it required to include the above three paragraphs into the > > debian/copyright file? > > What you should include is the exact notice found in the upstream > source which says that the program is covered by the GPL. As far as > I can see from a random sample (src/fnmatch.c) from the source > package, this notice happens to be identical to the blurb you quoted > from debhelper, but if it had been different, you should add the > notice actually found in the upstream source. I actually missed this particular one... fnmatch.c is not copyrighted by Stefan Ondrejicka either. Nor is gtkclrbutton.c. The copyright file needs to include the copyright statements for the different works that have been included in chbg, since there are at least 5 copyright holders that I've identified so far. (FSF, Stefan, Peter, Spencer, and Josh.) [I'm ignoring the auto* stuff, but since that's owned by the FSF as well, you're probably ok.] Don Armstrong -- If it jams, force it. If it breaks, it needed replacing anyway. -- Lowery's Law http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Måns Rullgård <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > >>> It is not hard: Some distribution of Eclipse is only encumbered by the >>> GPL if it requires a GPLed work to correctly operate. You may have >>> some odd version of Eclipse, but the standard releases have no such >>> requirement. >> >> While most of what you said seemed perfectly reasonable, this does >> not. >> >> Some distribution of Eclipse is encumbered by the GPL if it, that >> distribution, includes a copy of a GPL'd work (and it is not mere >> aggregation, which this certainly isn't). So shipping Eclipse+Kaffe >> is not OK. Shipping Eclipse+otherJVM is fine. > > Your definition of "include" appears to be a little broader than the > one most of us use. I am using the plain English meaning: if I ship you a CD with Eclipse and Kaffe so that all you have to do is double-click some icon and it runs, that is a distribution of Eclipse including Kaffe. >> I do not think anyone will disagree with this. Can we now confine >> this argument to whether a program distributed as a >> package with Depends: jre | java-runtime contains a copy of a package >> with Provides: java-runtime? >> >> I'm inclined to say no, that that is not the intended operating state, >> merely an incidental of technically compatible packages -- and so even >> if Eclipse had a Depends: some-non-kaffe-jvm | java-runtime and Kaffe >> a Provides: java-runtime, there would be no conflict with the GPL here. > > You're starting to make sense. Merely because I'm reaching a conclusion which you find palatable? This reasoning is grounded on the same axioms and rules I've been using all along. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Firefox/Thunderbird trademarks: a proposal
Here's my attempt at something which hopefully everyone can accept. I've tried to take into account all the excellent feedback over the past few weeks, for which I thank all involved. Comments are in square brackets. This assumes that DFSG #8 means that Debian can be given rights over and above the rights necessary to make a program free, as long as all the rights necessary to make it free are transferable. 1) The Foundation grants Debian, and all redistributors of the official Debian packages of the Foundation's products, the right to label those packages with a name containing the trademark. [This document would apply to "Firefox", "Thunderbird", and any other trademarks on software names we may hold in future. The name would be Firefox, Community Edition or whatever is agreed between the Foundation and the maintainer. It's not important to this document.] 2) The Foundation agrees to document the procedure for changing the name to its satisfaction, for the benefit of Debian and anyone else, and to work to make that procedure as simple as possible. [This means that if you or a Debian redistributor ever has to change the name, it hopefully won't be too onerous. And it means we can't blindside anyone with 'but you forgot to change *this* instance".] 3) The Foundation will review the current Debian package at freeze time, and at other times at their discretion, and bring any issues they have to the attention of the maintainer. The maintainer is not responsible for notifying the Foundation of any changes he may make to the package, or obligated to make any change that the Foundation may suggest. However, in the unlikely event of irreconcilable differences occurring between the maintainer and the Foundation, the name of the package will have to be changed in all as-yet-unreleased versions of Debian. [This gives you a free hand over the development process, and us the oversight that we need by law to be seen to be having.] 4) The Foundation agrees not to withdraw the permission more than three months into a freeze. [This is intended to mean that we can't require an inconvenient change just when you are about to release; if we don't notice until it's too late, it's our problem. My understanding of the Debian process is not complete; 'freeze' may not be the correct term here.] 5) The Foundation agrees not to withdraw the permission for versions of the product shipping in stable releases of Debian, provided all updates to the package are within Debian's guidelines for package updates in stable releases. [You have carte blanche to make security fixes. We are happy because your own procedures say you can't gut the package and replace it with something different. And you are happy because you have to follow your own procedures anyway, so it's not a burden.] 6) The Foundation agrees that it's not Debian's responsibility to make sure the distributors of any derivative works of Debian packages have an implicit or explicit trademark license from the Foundation. [No hassle for you.] 7) The Foundation requests that Debian document, in a place where it might be seen by package modifiers, the potential need to acquire such a trademark licence. [I hope you would view such a notice as a service to your users - but distributors of modified versions may need a license whether you add the notice or not. This is hopefully in line with DFSG #4, which says that packages are free even if derived works are required to carry a different name. It is also in line with free software licenses where changes require other changes, e.g. the GPL 2a) where code changes must be documented.] Is this a runner? Gerv One final note: I can't completely exclude the possibility that someone higher up at the Foundation (e.g. Mitchell Baker) will say that I've overreached myself. But I don't know of any reason why that would be the case, and I'm negotiating in good faith. I would, of course, get a final version approved by all necessary parties :-)
Re: Questions about legal theory behind (L)GPL
On Thu, 13 Jan 2005 22:00:05 +, Henning Makholm <[EMAIL PROTECTED]> wrote: > I got lost somewhere along the way: Why is it important to you whether > the GPL is a "contract" or not? To me, personally? It bugs me to see needless conflicts within the Free Software world caused by GPL interpretations that have no foundation in law. IANAL, but I've been following the relevant case law on and off for years, as a matter of self-defense, and the FSF's positions on this and other issues look to me to be increasingly untenable and major obstacles to the very ideals of programmer freedom they profess. It's a sad way for a formerly admirable and effective organization to devolve, and I hope that it's reversible through reasoned argument. I have no axe to grind here, and I'm perfectly content not to use FSF copyright material in ways the FSF doesn't intend. I got into the whole topic again when the Linux Core Consortium proposal came up, and the "(L)GPL is not a contract" fiction was raised to justify why the LGPL fails to ban de facto consecration of "golden" binaries. The other issues in play -- whether drivers containing firmware download mechanisms have to go into contrib, whether GPL-incompatible Java code can be run on a GPL JVM, etc. -- have kept me engaged longer, and brought up more precedents, than I originally intended. > You don't have to convince me - in my home jurisdiction it is beyond > dispute that application of the GPL would be a matter for our contract > law, and I won't aspire to claim anything about how it works in a > common-law system. > > But the heat of the debate nevertheless leaves me wondering what it's > for. Does it make any difference, and if so, what? In US jurisdictions very different standards apply to actions under contract and under tort, and in particular under the tort of copyright infringement. If a plaintiff can demonstrate a likelihood of success on the facts of copyright infringement, then he is entitled to an automatic presumption that irreparable harm will come of allowing the defendant to continue publishing the infringing work while the case is fully argued, and that presumption is quite hard to rebut. That's the "big stick" that the FSF tries to wave over those who misuse (in their opinion) GPL material -- disruption of their business through preliminary injunction while the case grinds its way through court. The FSF's position would be subject to much closer scrutiny under contract law in other respects as well. As a matter of law, ambiguities in a contract have to be construed against the offeror, because it is presumed that the offeror could have written the terms of the contract to be as favorable to himself as the offeree would tolerate. Statutory overrides and principles of equity may be used to alter the contract provisions and find additional implied provisions during the court's interpretation of its text. And the remedies applied are subject to pragmatic tests such as the "balance of harms" and reasonable standards of "cure of breach". Under either legal standard, I don't believe that linking GPL and non-GPL material creates a derivative work in violation of the actual terms of the GPL. But that's another debate. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > Which Eclipse packages? The old ones we have in SID now? Irrelevant. > There would have been nothing whatsoever to discuss in such case. > > The *new* Eclipse packages that are being prepared now and which we've > been discussing (I already said it in another email, but you must > have crossed yours) have it this way: > > Build-depends: kaffe > Depends: kaffe | java2-runtime > > [ From http://kyoto.larvalstage.net/ubuntu/warty/ ] > > So a user who does either 'apt-get source eclipse' or 'apt-get install > eclipse' will link (either at compilation time or at runtime) to Kaffe's > Java library, and to Kaffe JVM bindings which are all GPL. > > I hope this clarifies _at least_ this issue. Can you clarify one more? Is Eclipse then just building as well-specified JVM code, or is it linking against GPL'd class libraries as well? I don't actually know whether Kaffe is a JVM or also includes the rest of the Java runtime environment. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: how to mention GPL in the debian/copyright file
On Thu, 13 Jan 2005, Jochen Voss wrote: > I have a question about how to write the debian/copyright file > for packages which are distributed under the GPL. > > Currently the debian/copyright file of chbg contains the paragraph > > Chbg is copyrigthed by Ondrejicka Stefan ([EMAIL PROTECTED]). It is > license under the GPL. On Debian systems, the complete text of the > GNU General Public License can be found in the > /usr/share/common-licenses/GPL file. Unfortunatly, this is incorrect. The code is licensed under GPL 2 or later. (See below where I discuss the issues with this.) [SNIP] > My questions: > > 1) Is it required to include the above three paragraphs into the > debian/copyright file? The debian/copyright file must include the upstream's copyright statement. This typically includes the three paragraphs listed above. In your case, it looks like the copyright statement is just the following: /***/ /* This code is part of Desktop Background changer*/ /* called ChBg*/ /* Copyright (c) 1999,2000 Ondrejicka Stefan */ /* ([EMAIL PROTECTED]) */ /* Distributed under GPL 2 or later */ /***/ However, I strongly suggest that you talk to upstream, and have upstream use the form of copyright statement and licensing statement mentioned in the GNU GPL itself, namely: Copyright (C) 19yy This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; see the file COPYING. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. > 2) In case it is not required, is it for some other reason > preferable to include them? It is preferable to include them from the upstream maintainer's point of view, because it makes it explicit what license the work is released under. In the case of this work, it's very difficult to accertain what license the images are released under, as there is no LICENSE or similar file that contains a copyright statement and license statement covering the entire archive. While this may seem a bit overdone, it's really in the best interest of the upstream maintainer to follow the instructions of the GNU GPL when upstream places code under the GPL. Don Armstrong -- There are two types of people in this world, good and bad. The good sleep better, but the bad seem to enjoy the waking hours much more. -- Woody Allen http://www.donarmstrong.com http://rzlab.ucr.edu
Re: how to mention GPL in the debian/copyright file
Hello Henning, thank you for your help. On Thu, Jan 13, 2005 at 10:25:58PM +, Henning Makholm wrote: > What you should include is the exact notice found in the upstream > source which says that the program is covered by the GPL. Does this mean we need all the notes from the source files with duplicates removed? Do you have any reference for this? Maybe debian-policy (this is where I looked) could be changed to include this information? I find for example the appended notices. Should I replace my text blurb by the concatenation of all these notices? Does different white space count as being different? Now confused, Jochen PS.: I looked at the vroot.h license (last one in my list) which I did not spot before. I think is is ok for our purposes. Do you agree? == * from the README: This is public release of ChBg distributed under GPL. [...] License : - Chbg is licensed under terms of GPL. See COPYING. * from src/absimg.c: /***/ /* This code is part of Desktop Background changer*/ /* called ChBg*/ /* Copyright (c) 1999 - 2001 Ondrejicka Stefan*/ /* ([EMAIL PROTECTED]) */ /* Distributed under GPL 2 or later */ /***/ * from src/gdk_imlib1.c: (different copyright year) /***/ /* This code is part of Desktop Background changer*/ /* called ChBg*/ /* Copyright (c) 1999,2000 Ondrejicka Stefan */ /* ([EMAIL PROTECTED]) */ /* Distributed under GPL 2 or later */ /***/ * from fnmatch.c: (different copyright holder) /* Copyright (C) 1991, 1992, 1993, 1996, 1997 Free Software Foundation, Inc. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ * from gimpgradient.c: (even more different copyright holder) /* The GIMP -- an image manipulation program * Copyright (C) 1995 Spencer Kimball and Peter Mattis * * Gradient editor module copyight (C) 1996-1997 Federico Mena Quintero * [EMAIL PROTECTED] * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURIGHTE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ * from gtkgbpixmap.c: (gimp again, but different names) /* GTK - The GIMP Toolkit * Copyright (C) 1995-1997 Peter Mattis, Spencer Kimball and Josh MacDonald * GtkBgPixmap Copyright (C) 2000 Stefan Ondrejicka <[EMAIL PROTECTED]> * * Insensitive pixmap building code by Eckehard Berns from GNOME Stock * Copyright (C) 1997, 1998 Free Software Foundation * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Library General Public * License as published by the Free Software Foundation; either * version 2 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Library General Public License for more details. * * You should have received a copy of the GNU Library General Public * License along with this library; if not, write to the * Free S
Re: how to mention GPL in the debian/copyright file
Scripsit Joey Hess <[EMAIL PROTECTED]> > Henning Makholm wrote: >> > found in /usr/share/debhelper/dh_make/native/copyright", which turn out >> this notice happens to be identical to the blurb you quoted from >> debhelper > Debhelper does not contain such a GPL copyright blurb. Sorry. Damn dh-make's creative installation directory choices. -- Henning Makholm "Der er ingen der sigter på slottet. D'herrer konger agter at triumfere fra balkonen når de har slået hinanden ihjel."
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, 2005-13-01 at 22:51 +0100, Måns Rullgård wrote: > >> > Do you understand that a program being interpreted is effectively > >> > linked to these facilities it uses thru these bindings? > >> > >> Yes. Which bindings does Eclipse use? > > > > I told you. Plenty. And if we're making Eclipse Build-depend on > > a GPLed version of these, then we're explicitely forcing these bindings > > to be GPLed. > > Guess what, Eclipse does not have a Build-depends on any GPLd JVM. It > has a Build-depends on j2sdk1.3 | j2sdk1.4, which are virtual > packages. Guess what else, Kaffe doesn't provide either of these. > Surprised? I'm amused. Which Eclipse packages? The old ones we have in SID now? Irrelevant. There would have been nothing whatsoever to discuss in such case. The *new* Eclipse packages that are being prepared now and which we've been discussing (I already said it in another email, but you must have crossed yours) have it this way: Build-depends: kaffe Depends: kaffe | java2-runtime [ From http://kyoto.larvalstage.net/ubuntu/warty/ ] So a user who does either 'apt-get source eclipse' or 'apt-get install eclipse' will link (either at compilation time or at runtime) to Kaffe's Java library, and to Kaffe JVM bindings which are all GPL. I hope this clarifies _at least_ this issue. GBP -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> SableVM - Free, LGPL'ed Java VM http://sablevm.org Why SableVM ?!? http://sablevm.org/wiki/Features Debian GNU/Linux - the Free OS http://www.debian.org
Re: how to mention GPL in the debian/copyright file
Scripsit Jochen Voss <[EMAIL PROTECTED]> > On Thu, Jan 13, 2005 at 10:25:58PM +, Henning Makholm wrote: >> What you should include is the exact notice found in the upstream >> source which says that the program is covered by the GPL. > Does this mean we need all the notes from the source files with > duplicates removed? Yes. All authors who claim copyright in a source file should be credited in the Debian copyright file, together with the exact statement of license they issued. For many free licences this is a legal requirement, because the notices in the source are not shipped in the .deb otherwise, and even when it isn't it would be discourteous in extreme not to quote it anyway. This is what /usr/share/doc/*/copyright is _for_. > Does different white space count as being different? Current best practice is, as far as I'm aware, something like: 1. Minor formatting differences, including different styles of comment markup, line wrapping and other whitespace, can be compressed away in the copyright file. 2. Similarly, two authors who assert copyright but give identical license notices can be compressed into just giving both copyright assertions in the copyright file, followed by the common license notice. 3. Actual differences in wording should be preserved, even if they may seem insignificant to the packager, except perhaps where the difference is beyond any conceivable doubt due to a mere typo. > Do you have any reference for this? Policy section 12.5. A "verbatim copy of its copyright and distribution license" means just what it says. Policy perhaps neglects to explicitly point out that this applies simultaneously to every copyright [notice] and every distribution licence that covers the package, but I still think this can safely be left to the reader's imagination. > I find for example the appended notices. Should I replace my > text blurb by the concatenation of all these notices? Yes. See e.g. /usr/share/doc/xlibs/copyright for an example of how large this can be in complex cases, but it all has to be there. > PS.: I looked at the vroot.h license (last one in my list) which I > did not spot before. I think is is ok for our purposes. Do you agree? Yes, it looks like a minor rewording of the common 3-clause BSD license: > Permission to use, copy, modify, and distribute this software and > its documentation for any purpose and without fee is hereby > granted, provided that the above copyright notice appear in all > copies and that both that copyright notice and this permis- > sion notice appear in supporting documentation, and that the > name of Solbourne not be used in advertising > in publicity pertaining to distribution of the software without > specific, written prior permission. > > ANDREAS STOLCKE AND SOLBOURNE COMPUTER INC. DISCLAIMS ALL WARRANTIES > WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF > MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL ANDREAS STOLCKE > OR SOLBOURNE BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL > DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA > OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER > TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE > OR PERFORMANCE OF THIS SOFTWARE. -- Henning Makholm"I ... I have to return some videos." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why is graphviz package non-free?
Scripsit Raul Miller <[EMAIL PROTECTED]> > On Thu, Jan 13, 2005 at 09:18:21PM +, Henning Makholm wrote: >> To make what I fear explicit, here is a fleshed-out scenario: >> 1. A writes a program and releases it under the current CPL. >> 2. B takes A's program, hacks on it, distributes his Contributions >> on a website under the current CPL. >> 3. IBM notices B's modified program and decides that they would like >> to include it in their proprietary program suite for frobitzing >> foobars, with private modifications that they don't release >> source for. So, >> 4. IBM releases new version of CPL which gives IBM carte blanche to >> do anything at all with covered code. >> 5. C (a strawman for IBM) picks up B's modified program, makes some >> inconsequential little changes and releases it under the new >> amended CPL - as allowed by the original CPL under which B >> distributed his changes. >> 6. IBM picks up C's distribution and starts abusing B's contribution >> proprietarily. > The same thing is possible with the GPL, with it's "any later version" > clause. No - the GPL would allow B to distribute his hacked code under "GPL, version 2 only" if he wants to prevent this. > For that matter, the same thing is possible with the BSD license, > because it makes no attempt to provide copyleft protection. No - the BSD license would allow B to distribute his hacked code under "GPL, version 2 only" if he wants to prevent this. The CPL does *not* allow B to distrubte his hacked code under "CPL, version 1 only". In fact, "CPL, version 1 only" is not even a internally consistent license specification, because CPL *intrinsically* allows any downstream recipient to switch everything to any later version published by IBM. -- Henning Makholm"Jeg køber intet af Sulla, og selv om uordenen griber planmæssigt om sig, så er vi endnu ikke nået dertil hvor ordentlige mennesker kan tillade sig at stjæle slaver fra hinanden. Så er det ligegyldigt, hvor stærke, politiske modstandere vi er."
GNU Classpath based execution environments (Was: Eclipse 3.0)
Hi, On Thu, 2005-01-13 at 12:21 -0500, Brian Thomas Sniffen wrote: > Måns Rullgård <[EMAIL PROTECTED]> writes: > > AFAIK, Eclipse uses only the standard Java API > > as published by Sun, and will run equally well with any implementation > > of said interface. > > Great -- which implementation does Debian ship it with? That's all > that really matters. Both runtimes in question (as most free runtimes) are based on the GNU Classpath core class library (which is the same as libgcj which comes with GCC and provides the runtime library for the gij interpreter and gcj ahead of time compiler). It is distributed under the terms mentioned here: http://www.gnu.org/software/classpath/license.html There have been questions about how this license precisely interacts when combined with other code (like the LGPL in the sablevm case and the GPL in the kaffe case). The FSF wants to make the intent of the GNU Classpath distribution terms as clear as possible and has setup a GNU Classpath license clarification wiki were people can add suggestions or concerns about the current wording (if any): http://www.gnu.org/licensing/classpath/ > > This whole discussion is something between ridiculous and hilarious, > > definitely not useful. > > If it causes even one person to understand that the generation or > transportation of a copy is what matters, and not technical > workarounds, I'll consider it useful. I believe this pissing contest between the sablevm and kaffe packagers is a big waste of time. There are obviously important issues to be worked out like the ASL and GPL compatibility and making sure the interpretations and intend of the various licenses are clear. But I don't believe the best way to do that is by constantly claiming someone else work is "illegal" and/or "a complete waste of time". Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: how to mention GPL in the debian/copyright file
Scripsit Jochen Voss <[EMAIL PROTECTED]> > Recently Justin Pryzby filed bug #290087 against chbg, claiming that > the debian/copyright file should instead contain "the 3 paragraphs as > found in /usr/share/debhelper/dh_make/native/copyright", which turn out > to be [snip standard GPL blob] > 1) Is it required to include the above three paragraphs into the > debian/copyright file? What you should include is the exact notice found in the upstream source which says that the program is covered by the GPL. As far as I can see from a random sample (src/fnmatch.c) from the source package, this notice happens to be identical to the blurb you quoted from debhelper, but if it had been different, you should add the notice actually found in the upstream source. -- Henning Makholm"We can hope that this serious deficiency will be remedied in the final version of BibTeX, 1.0, which is expected to appear when the LaTeX 3.0 development is completed."
JVM = interpreter + VM bindings
On Thu, 2005-13-01 at 18:18 -0500, Brian Thomas Sniffen wrote: > "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > > > On Thu, 2005-13-01 at 15:58 -0500, Raul Miller wrote: > >> On Thu, Jan 13, 2005 at 03:19:36PM -0500, Grzegorz B. Prokopski wrote: > >> > >> > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > >> > > >> > "However, when the interpreter is extended to provide "bindings" to > >> > other facilities (often, but not necessarily, libraries), the > >> ... > >> > Do you understand that an interpreter for Java IS such an interpreter > >> > that provides "bindings" to other facilities? > >> > >> But was Kaffe _extended_ to provide such bindings for Eclipse 3.0? > > > > This FAQ entry discusses 2 cases. One is when we have an interpreter, > > that basically goes over the pseudo-code and purely "interprets" it > > (an old BASIC interpreter would fit here). No Java VM/interpreter > > _ever_ fits in this first, simple casse. > > I think you're making untenable conclusions based on your knowledge of > accidents of implementation of Java VMs. Sorry about that, now that the flaming part is hopefully over, I'll be more than happy to give some more technically detailed informations. I've just posted a hopefuly more meaningful sketch of what the interconnections of program, java library, interpreter and its bindings are. > A Java bytecode interpreter is just an interpreter. The class > libraries matter, and the libraries exposed through the JNI interface > matter. Sure they do. But it's hard to agree (after seeing how complicated machinery a JVM is) that JVM is "just an interpreter". Actually the interpreter part of SableVM (that is, where you take bytecodes one by one and interpret them) is maybe 10-15% of it. > > On the contrary. A Java Virtual Machine (Java interpreter) inevitably > > has to provide such bindings to support Java specification. In other > > words the interpreter itself has to be extended with a library that > > provides these bindings to support Java specs. There's plenty of these > > bindings required to exist in core java.lang.* classes. > > This confuses me, though. Can you provide an unambiguous example? I'll do my best, and I'll try to show things that are not in any way SableVM-specific. Say a thread of your program acquired a lock (mutex, with a monitor in C) and wants to wait on it, until it's signalled by another thread. Your program has a VIRTUALCALL bytecode with reference to string "java.lang.Object.wait()". Interpreter will see the bytecode, read the string, make sure the object on which you're trying to invoke wait() does actually implement it, then it will see that it's a native method. It will therefore call a native (usually JNI) library, which is part of the JVM itself to find a function ie. Java_java_lang_Object_wait(). If a VM has moving garbage collector (SableVM, Sun, IBM, have) the first thing this function will do is to call "resuming_java()" function (this means "resuming java virtual machine internal code") to ensure that ie. garbage collection will not happen, which would result in objects being relocated. It will then proceed by checking whether the current thread actually owns the lock of the object on which it wants to wait() and will instantiate and throw an exception if it doesn't. Let's assume the excaption is to be thrown. Actually instantiating an exception for the first time will make use of a class loading facilities, which will have to go thru the hierarchy of class loaders. Ie. it might be that an application's class loader will be asked first to load the exeception class code, thus we'll be dumped back to the interpreter and it will invoke some of the application code. Then, after a class of the exception is loaded we will also have to instantiate it, thus if it contained any "static initializers" - they will need to be ran (again, we'll get back to the interpreter, which might execute any amount of code static initializer called, even including calling wait() or some other internal VM method again). So we saw the following boundary crossings: - Application is interpreted and calls java library - java library is interpreted and calls VM library binding - VM library method does some magic, possibly touching structures shared between the VM library part and interpreter - VM library calls interpreter again as a result of what happened - interpreter executes application or library code - this code can call the VM library again ... - ... The java library and the application of course can have their own native libraries that are being called under way, but this is not part of the discussion. Now, the VM library is pretty much always statically linked (is part of) to the "interpreter" part, because they often share many data structures. I have not shown an example, but even simple loading of the very first class of an application which is about to run requires interaction with VM library part. In s
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, Jan 13, 2005 at 08:25:49PM +0100, M?ns Rullg?rd wrote: > Andrew Suffield <[EMAIL PROTECTED]> writes: > > > On Thu, Jan 13, 2005 at 07:58:53PM +0100, M?ns Rullg?rd wrote: > >> >> Then how can things like thepiratebay.org be legal? > >> > > >> > They aren't with any degree of certainty. > >> > >> It's certain enough that Microsoft have failed to shut them down. > > > > They haven't tried. All Microsoft have done to them so far is send > > them some nastygrams in the mail. > > And for some reason you believe Microsoft would be content with that, > if they believed they had any real chance to stop them? It's sheer hubris to think that Microsoft cares about this site. There's a million others like it and one more doesn't make much difference. Pursuing it would merely use up time which their lawyers could instead have spent eroding our civil liberties. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, Jan 13, 2005 at 04:35:50PM -0500, Grzegorz B. Prokopski wrote: > > But was Kaffe _extended_ to provide such bindings for Eclipse 3.0? > > This FAQ entry discusses 2 cases. One is when we have an interpreter, > that basically goes over the pseudo-code and purely "interprets" it > (an old BASIC interpreter would fit here). No Java VM/interpreter > _ever_ fits in this first, simple casse. The FAQ discusses far more than 2 cases. I imagine you're concerned about this part: If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses? When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone. However, when the interpreter is extended to provide "bindings" to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a binding mechanism; libraries that are accessed in this way are linked dynamically with the Java programs that call them. These libraries are also linked with the interpreter. If the interpreter is linked statically with these libraries, or if it is designed to link dynamically with these specific libraries, then it too needs to be released in a GPL-compatible way. > Second case is where the code being interpreted may request to access > bindings provided by the JVM. In Java these are done thru JNI calls, > so usually JVM itself is a JNI library that provides these bindings. > > So an interpreter has to be "extended" to provide these "bindings" to > other facilities. In such case, as the FAQ states "the interpreted > program is effectively linked to the facilities it uses through these > bindings." Is this relevant to Eclipse? I was under the impression that Eclipse was pure java -- that it did not use JNI at all. If Eclipse does use JNI, would still a question about whether or not Kaffe's JNI implementation constitute some kind of extension designed to work around the GPL or whether they are some kind of implementation of some Java standard. > > Or is Eclipse 3.0 using only the facilities which Kaffe provides for > > arbitrary byte code? > > There is nothing in the FAQ that would suggest that these "facilities" > have to be provided for a specific program. There is nothing in the FAQ to suggest that a GPLed JNI implementation has to be a problem for arbitrary code, though of course it does point out JNI as a issue that can be a problem. But for problem resolution, the FAQ is saying that certain things need to be released in a GPL-compatible way, not that no release can happen. > On the contrary. A Java Virtual Machine (Java interpreter) inevitably > has to provide such bindings to support Java specification. In other > words the interpreter itself has to be extended with a library that > provides these bindings to support Java specs. There's plenty of these > bindings required to exist in core java.lang.* classes. > > Hope this clarifies the issue, You seem to be claiming that a JVM has to provide non-standard JNI capabilities or it isn't a standard implementation of the JVM. I'm not sure what that is supposed to clarify. I'm rather doubtful that it's correct. -- Raul
Re: why is graphviz package non-free?
On Thu, Jan 13, 2005 at 04:43:57PM -0500, Raul Miller wrote: > The same thing is possible with the GPL, with it's "any later version" > clause. You can release your modifications in a way that allows this, but by contrast, you're not required to do so. You can take a GPL-licensed work with the "any later version" clause active, hack on it, and release your modifications without that clause. http://lists.debian.org/debian-legal/2004/08/msg00821.html > For that matter, the same thing is possible with the BSD license, > because it makes no attempt to provide copyleft protection. With BSD-licensed code, you're not required to grant permissions to your modifications that the license doesn't grant you in the first place, which is the issue Henning is concerned about. Would you consider a license free that said: If you use this software in another work, you must include the text "includes code written by Glenn Maynard" in supporting documentation. You must grant Glenn Maynard a license to distribute your modifications without a similar acknowledgement (a bare copyright and license notice must be sufficient). You're required to grant me permission to your modifications that he didn't grant us. This has come up in the past, under the argument that requiring this violates the "under the same terms as the license of the original software" provision of DFSG#3: you aren't allowed to distribute modifications under the same terms you received them, but instead must grant extra permissions. I'm not convinced it's a problem, and the argument doesn't work well in some cases--there are many licenses which give special treatment to the upstream author, which are generally considered very poor, obnoxious licenses, but not quite non-free. I do think it's worth thinking about, though. -- Glenn Maynard
Re: Illustrating JVM bindings
> > Is this relevant to Eclipse? I was under the impression that Eclipse > > was pure java -- that it did not use JNI at all. > > > > If Eclipse does use JNI, would still a question about whether or not > > Kaffe's JNI implementation constitute some kind of extension designed > > to work around the GPL or whether they are some kind of implementation > > of some Java standard. On Thu, Jan 13, 2005 at 06:33:20PM -0500, Grzegorz B. Prokopski wrote: > I fail to see anything in the FAQ you cited above about extensions > designed to _work around GPL_. Please refrain from creating meanings. I believe the GPL takes precedence over the FAQ. And, no, I will not restrict my use of the english language words to literal quotes taken from a FAQ. If I've provided too much meaning for you to deal with, I feel some mild regret at inflicting such agony on you, but not so much regret that I'll start posting nonsense. > This is about the way Java works. You cannot merely interpret > bytecode. Sure I can. I've done it. Mind you, I'm not very fast when I interpret bytecode logically, but that wasn't your claim. > The program you're interpreting has to be able to call back > into the JVM (or if you wish into a JNI library that is bound to a VM) > to be able to run at all. http://google.com/search?q=define:jni When a java program uses JNI, you basically have to treat it as a non-java program, because it can use non-java facilities. However, a pure java program doesn't need to use JNI and the presence of JNI facilities in the interpreter is moot at that point. This case is typically simpler than the case of a non-java program, which is why JNI gets special mention -- so that the two cases aren't confused. > > > > Or is Eclipse 3.0 using only the facilities which Kaffe provides for > > > > arbitrary byte code? > > > > > > There is nothing in the FAQ that would suggest that these "facilities" > > > have to be provided for a specific program. > > > > There is nothing in the FAQ to suggest that a GPLed JNI implementation has > > to be a problem for arbitrary code, though of course it does point out JNI > > as a issue that can be a problem. But for problem resolution, the FAQ is > > saying that certain things need to be released in a GPL-compatible way, > > not that no release can happen. > > It says "if these facilities are released under the GPL, the interpreted > program that uses them must be released in a GPL-compatible way". Indeed. But I question whether the phrase "these facilities" is at all relevant to this context. Until I have some reason to believe that it is relevant, I don't find discussion of the consequences of releasing "these facilities" to be very interesting. > > > On the contrary. A Java Virtual Machine (Java interpreter) inevitably > > > has to provide such bindings to support Java specification. In other > > > words the interpreter itself has to be extended with a library that > > > provides these bindings to support Java specs. There's plenty of these > > > bindings required to exist in core java.lang.* classes. > > > > > > Hope this clarifies the issue, > > > > You seem to be claiming that a JVM has to provide non-standard JNI > > capabilities or it isn't a standard implementation of the JVM. > > I am sorry, but where do you see the "non-standard" is wrriten? I see it written two lines and five lines above this sentence. [You asked.] Now, if you'd have asked a relevant question I'd have made an effort to provide a relevant answer. But relevance has to do with concepts and ideas. A strong devotion to literal quotes won't get you there if you've abandoned the meaning of the material you're quoting. > The only part that would suggest somethign like that is "when the > interpreter is extended to provide "bindings" to other facilities". > > Is that the part you're referring to? No. I'm talking about my understanding of the significance of various aspects of computer programming technology within the scope of my understanding of the GPL, as they relate to the context being discussed in that part of the FAQ. While I'm prepared to restate my ideas using different words, if my words are a problem for you, I'm not prepared to pretend ignorance where it doesn't exist. Likewise, I'm not really prepared to pretend that I know about something I don't know about. Finally, while I'm prepared to admit my mistakes, if they're pointed out to me (and I do make mistakes, at times), I'm not going to pretend that <> is always a mistake. > I am trying to explain, since the very beginning, that it is not > possible for a Java interpreter not to provide these facilities that > are being called by the program being interpreted. Therefore *every* > JVM has to consists of an interpreter (be it JIT or ahead of time) > extended with these "callback" functions. I know that's what you're trying to explain. What I don't see is any convincing reason to believe that you are correct. However, take
Re: Questions about legal theory behind (L)GPL
Scripsit "Michael K. Edwards" <[EMAIL PROTECTED]> > On Thu, 13 Jan 2005 07:46:18 -0500, Nathanael Nerode >> I guess I'm convinced. :-) > That the GPL is legally an offer of contract? If so, it's good to > know that the substance of my argument is persuasive to at least one > person besides myself. :-) I got lost somewhere along the way: Why is it important to you whether the GPL is a "contract" or not? You don't have to convince me - in my home jurisdiction it is beyond dispute that application of the GPL would be a matter for our contract law, and I won't aspire to claim anything about how it works in a common-law system. But the heat of the debate nevertheless leaves me wondering what it's for. Does it make any difference, and if so, what? -- Henning Makholm "Larry wants to replicate all the time ... ah, no, all I meant was that he likes to have a bang everywhere."
Re: why is graphviz package non-free?
Raul Miller wrote: > On Thu, Jan 13, 2005 at 09:18:21PM +, Henning Makholm wrote: >>To make what I fear explicit, here is a fleshed-out scenario: >> 1. A writes a program and releases it under the current CPL. >> 2. B takes A's program, hacks on it, distributes his Contributions >> on a website under the current CPL. >> 3. IBM notices B's modified program and decides that they would like >> to include it in their proprietary program suite for frobitzing >> foobars, with private modifications that they don't release >> source for. So, >> 4. IBM releases new version of CPL which gives IBM carte blanche to >> do anything at all with covered code. >> 5. C (a strawman for IBM) picks up B's modified program, makes some >> inconsequential little changes and releases it under the new >> amended CPL - as allowed by the original CPL under which B >> distributed his changes. >> 6. IBM picks up C's distribution and starts abusing B's contribution >> proprietarily. > > The same thing is possible with the GPL, with it's "any later version" > clause. > > For that matter, the same thing is possible with the BSD license, > because it makes no attempt to provide copyleft protection. > > I don't think this is worth worrying about. While I agree that this scenario is not worth worrying about, the same thing is quite avoidable in the case of the GPL. If you don't trust the FSF for whatever reason, you can always redistribute under GPL 2 only, not permitting later versions of the GPL. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > Putting it differently: if that was allowed, then why do we need glibc > to be LGPLed, and not GPLed? After all the C language and its basic > libraries are also standarized to great extent. I can see no real reason. > But having glibc purely GPL just doesn't sound good, does it? It sounds like it would make for a lot of arguing with FSF, nothing else. -- Måns Rullgård [EMAIL PROTECTED]
Re: LCC and blobs
Anthony DeRobertis wrote: > Glenn Maynard wrote: >> It'd be useful to have a real-life example of a server that >> needs to be sent proprietary data for a "legitimate" reason (in the >> sense that a device needing to be sent firmware is "legitimate"). > > Habeas SWE. > > I believe SpamAssassin implements the server side (through hashes to > avoid actually having a copy of the SWE in it). Very good example. However, despite their laudable goal of aiding in spam detection, I think that since their trademark serves a _functional_ purpose, it can no more be trademarked than the names of functions in an API. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > On Thu, 2005-13-01 at 21:56 +0100, Måns Rullgård wrote: >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> >> > On Thu, 2005-13-01 at 20:58 +0100, Måns Rullgård wrote: >> >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> >> > Now, in our case, Eclipse is linked agains a libraries that ARE GPLed. >> >> >> >> No, it is being interpreted by an interpreter that is covered by the >> >> GPL. Even the FSF admits that this does not create a derived work. >> > >> > You really should reread FSF FAQ: >> > >> > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL >> > >> > "However, when the interpreter is extended to provide "bindings" to >> > other facilities (often, but not necessarily, libraries), the >> > interpreted program is effectively linked to the facilities it uses >> > through these bindings. So if these facilities are released under the >> > GPL, the interpreted program that uses them must be released in a >> > GPL-compatible way. The JNI or Java Native Interface is an example of >> > such a binding mechanism; libraries that are accessed in this way are >> > linked dynamically with the Java programs that call them. These >> > libraries are also linked with the interpreter. If the interpreter is >> > linked statically with these libraries, or if it is designed to link >> > dynamically with these specific libraries, then it too needs to be >> > released in a GPL-compatible way." >> > >> > Do you understand that an interpreter for Java IS such an interpreter >> > that provides "bindings" to other facilities? >> >> The paragraph above concerns JNI interfaces to libraries *separate* >> from the interpreter. For instance, one could imagine a JNI binding >> to GNU readline. The use of such bindings is independent of the JVM >> being used (bindings might not exist for all JVM implementations, but >> that's irrelevant). The existence of a binding facility does not make >> a program using them derived from the interpreter. In FSF logic, it >> is derived from the bound libraries, no more, no less. > > It shows you have no idea how a JVM is organized. The "interpreter" > part on which you're hanging so strongly is only part of a JVM. The > part that actually gets to interpret the bytecode. But there's also > a lot of functionality (think about it as a VM-specific library) that > is being used from within java library, and via JNI bindings calls > library functions of a JVM. > > Yes. A JVM migh be seen as an interpter + a library of native calls > used by the java library. And in case we're discussing this native > library is GPLed. The license of the library does not matter. Eclipse is written to work with any implementation of the standard Java API. >> > Do you understand that a program being interpreted is effectively >> > linked to these facilities it uses thru these bindings? >> >> Yes. Which bindings does Eclipse use? > > I told you. Plenty. And if we're making Eclipse Build-depend on > a GPLed version of these, then we're explicitely forcing these bindings > to be GPLed. Guess what, Eclipse does not have a Build-depends on any GPLd JVM. It has a Build-depends on j2sdk1.3 | j2sdk1.4, which are virtual packages. Guess what else, Kaffe doesn't provide either of these. Surprised? I'm amused. >> >> > Please see Linus's email I cited in my other emails for more info. >> >> > >> >> > Would it have been compiled against a differently licensed library, >> >> > this particular problem would be solved. Wouldn't it? >> >> >> >> It is compiled against an interface, not an implementation. Which >> >> particular implementation was used while compiling is irrelevant. >> > >> > Ok, so please compile Eclipse agains an *interface* which is not its >> > implementation (covered by GPL, in our case). Sure, if you use ie. >> > some stubs covered by IPC-compatible license, I won't say a word. >> >> If the implementations are fully compatible, the compiled bytecode >> should be bit-identical no matter which one was used. > > Does it matter? What however IS different is the fact which actual > implementation you use as the interface against which you're compiling, > and also with which implementation of library an app will be used. > These informations are explicitely and clearly encoded in debian control > files. Oh, you are saying Debian can dictate what some program is derived from simply by adding a Depends line? >> > But in our case you're using an implementation that also at the same >> > time defines the interface (this if functional equivalent of header >> > files). You cannot simply take a GPL implementation, compile against it >> > (never mind whether it's C, Java, Python or whatever), and they claim >> > you just didn't create a derivative work of the implementation you used. >> >> That's precisely what I am claiming, and several court cases support >> my claim. > > Voila! let's make glibc GPLed! Go ah
how to mention GPL in the debian/copyright file
Hello, I have a question about how to write the debian/copyright file for packages which are distributed under the GPL. Currently the debian/copyright file of chbg contains the paragraph Chbg is copyrigthed by Ondrejicka Stefan ([EMAIL PROTECTED]). It is license under the GPL. On Debian systems, the complete text of the GNU General Public License can be found in the /usr/share/common-licenses/GPL file. This is there to satisfy the requirement of policy section 12.5: Every package must be accompanied by a verbatim copy of its copyright and distribution license in the file /usr/share/doc/package/copyright. This file must neither be compressed nor be a symbolic link. [...] Packages distributed under the [...] GNU GPL [...], should refer to the files [...] /usr/share/common-licenses/GPL, [...] respectively, rather than quoting them in the copyright file. Recently Justin Pryzby filed bug #290087 against chbg, claiming that the debian/copyright file should instead contain "the 3 paragraphs as found in /usr/share/debhelper/dh_make/native/copyright", which turn out to be This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this package; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. My questions: 1) Is it required to include the above three paragraphs into the debian/copyright file? 2) In case it is not required, is it for some other reason preferable to include them? Thank you very much in advance, Jochen PS.: I am not subscribed to debian-devel, so please Cc: me on replies. -- http://seehuhn.de/ signature.asc Description: Digital signature
Re: how to mention GPL in the debian/copyright file
Henning Makholm wrote: > > found in /usr/share/debhelper/dh_make/native/copyright", which turn out > > What you should include is the exact notice found in the upstream > source which says that the program is covered by the GPL. As far as I > can see from a random sample (src/fnmatch.c) from the source package, > this notice happens to be identical to the blurb you quoted from > debhelper Debhelper does not contain such a GPL copyright blurb. -- see shy jo, who will keep correcting people who confuse dh-make and debhelper forever, I suppose signature.asc Description: Digital signature
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Michael K. Edwards" <[EMAIL PROTECTED]> writes: > From: "Michael K. Edwards" <[EMAIL PROTECTED]> > Subject: Re: Eclipse 3.0 Running ILLEGALY on Kaffe > To: Brian Thomas Sniffen <[EMAIL PROTECTED]> > Cc: Michael Poole <[EMAIL PROTECTED]>, debian-legal@lists.debian.org > Date: Thu, 13 Jan 2005 13:35:31 -0800 > Reply-To: [EMAIL PROTECTED] > > On Thu, 13 Jan 2005 16:16:53 -0500, Brian Thomas Sniffen > <[EMAIL PROTECTED]> wrote: > [quoting Michael Poole] >> > It is not hard: Some distribution of Eclipse is only encumbered by the >> > GPL if it requires a GPLed work to correctly operate. You may have >> > some odd version of Eclipse, but the standard releases have no such >> > requirement. > > A distribution of Eclipse is only encumbered by the GPL if it is a > derivative work of the GPL, such as by cut-and-paste of a piece of GPL > code in excess of "de minimis" standards. The GPL simply doesn't > address the "needs GPL code to work properly" case; consider Makefiles > that only work with GNU make. That's a nice example. > [snip] >> Some distribution of Eclipse is encumbered by the GPL if it, that >> distribution, includes a copy of a GPL'd work (and it is not mere >> aggregation, which this certainly isn't). So shipping Eclipse+Kaffe >> is not OK. Shipping Eclipse+otherJVM is fine. > > Copies are OK, derivative works aren't. Eclipse+Kaffe isn't a > derivative work and doesn't create one during execution either. Why are copies OK, and derivative works not? I see GPL 2b talking about any work that in whole or in part contains the Program. Eclipse+Kaffe contains Kaffe, GPL 2 then exempts mere aggregation -- which this is not. It also exempts separate sections *when distributed separately* -- and explicitly covers them when the Program is distributed as a whole. That feels like it's written to address this particular case -- or at least a tarball containing Kaffe and Eclipse. This is similar enough to count, it's just a funny compression scheme. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, 2005-13-01 at 22:02 +0100, Måns Rullgård wrote: > Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > > > Måns Rullgård <[EMAIL PROTECTED]> writes: > > > >> The Eclipse authors do not tell you which JVM to use. > > > > But Debian does, when it says: > > Depends: j2re1.4 | j2re1.3 | java2-runtime > > > > So the eclipse-platform distributed by Debian *does* call on a > > particular JVM. And it isn't kaffe, it's Sun's. > > Then why on earth does the license of Kaffe have any relevance > whatsoever to Eclipse? Because in the packages that are being prepared currently this reads: Build-depends: kaffe Depends: kaffe | java2-runtime So a user who does either 'apt-get source eclipse' or 'apt-get install eclipse' will link (either at compilation time or at runtime) to Kaffe's Java library, and to Kaffe JVM bindings which are all GPL. > > Can you support this assertion? The program, including its libraries, > > which the developer intends to put on end-user systems appears quite > > relevant to me. > > If I write a program in Java (it has happened), I intend for the > end-user to run it under any JVM of his choice. I don't care which > one chooses. The only reason I can see for suggesting a specific > implementation is for support issues, e.g. "we only provide support > for running our product under JVM implementation X". In principle you're right. Yet, if you *package* this program together with a JVM, so that when the user says "I want to build this package" or "I want to run this package" the user gets your program with a specific JVM, then it's not a mere aggregation, but these two are explicitely bound together. And GPL also says, that the person who packages and then distributes breaks the rules of GPL, it has no longer right to distribute nor use the GPLed work. And we do want to be able to distribute Kaffe, for it's very good for all GPL-compatible programs on platforms it supports. HTH, Grzegorz B. Prokopski -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> SableVM - Free, LGPL'ed Java VM http://sablevm.org Why SableVM ?!? http://sablevm.org/wiki/Features Debian GNU/Linux - the Free OS http://www.debian.org
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, 2005-13-01 at 18:13 -0500, Brian Thomas Sniffen wrote: > "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > > Which Eclipse packages? The old ones we have in SID now? Irrelevant. > > There would have been nothing whatsoever to discuss in such case. > > > > The *new* Eclipse packages that are being prepared now and which we've > > been discussing (I already said it in another email, but you must > > have crossed yours) have it this way: > > > > Build-depends: kaffe > > Depends: kaffe | java2-runtime > > > > [ From http://kyoto.larvalstage.net/ubuntu/warty/ ] > > > > So a user who does either 'apt-get source eclipse' or 'apt-get install > > eclipse' will link (either at compilation time or at runtime) to Kaffe's > > Java library, and to Kaffe JVM bindings which are all GPL. > > > > I hope this clarifies _at least_ this issue. > > Can you clarify one more? Is Eclipse then just building as > well-specified JVM code, or is it linking against GPL'd class > libraries as well? I am unsure what you understand as "well-specified JVM code". But any Java application you compile (unless you're compiling the most and self-contained core classes) surely has to link to a java library, just as you cannot compile your application w/o having .so and .h files of a library you're linking to. In case of Kaffe at least the core part of the java libraries is GPLed, and yes, you have to link against it during compilation. > I don't actually know whether Kaffe is a JVM or > also includes the rest of the Java runtime environment. Kaffe includes a JVM along with java libraries. The whole JVM is GPLed, and part of the very core libraries also is. Kaffe also includes some tools (a compiler among others). Cheers, Grzegorz B. Prokopski -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> SableVM - Free, LGPL'ed Java VM http://sablevm.org Why SableVM ?!? http://sablevm.org/wiki/Features Debian GNU/Linux - the Free OS http://www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: >> It is not hard: Some distribution of Eclipse is only encumbered by the >> GPL if it requires a GPLed work to correctly operate. You may have >> some odd version of Eclipse, but the standard releases have no such >> requirement. > > While most of what you said seemed perfectly reasonable, this does > not. > > Some distribution of Eclipse is encumbered by the GPL if it, that > distribution, includes a copy of a GPL'd work (and it is not mere > aggregation, which this certainly isn't). So shipping Eclipse+Kaffe > is not OK. Shipping Eclipse+otherJVM is fine. Your definition of "include" appears to be a little broader than the one most of us use. > I do not think anyone will disagree with this. Can we now confine > this argument to whether a program distributed as a > package with Depends: jre | java-runtime contains a copy of a package > with Provides: java-runtime? > > I'm inclined to say no, that that is not the intended operating state, > merely an incidental of technically compatible packages -- and so even > if Eclipse had a Depends: some-non-kaffe-jvm | java-runtime and Kaffe > a Provides: java-runtime, there would be no conflict with the GPL here. You're starting to make sense. -- Måns Rullgård [EMAIL PROTECTED]
Re: why is graphviz package non-free?
Glenn Maynard <[EMAIL PROTECTED]> wrote: > This has come up in the past, under the argument that requiring this violates > the "under the same terms as the license of the original software" provision > of DFSG#3: you aren't allowed to distribute modifications under the same > terms you received them, but instead must grant extra permissions. I'm still somewhat confused as to what DFSG 3 is meant to mean. As written, yes, it does sound like it's trying to prevent that sort of situation. But I've no real idea /why/ that sort of situation is supposed to be avoided. It was never discussed in the debian-private thread that lead to the DFSG being adopted. Bruce hasn't replied to my email asking what he meant it to mean. We've ended up with a sentence and nothing much in the way of meaning. Personally, I'm inclined to believe it was intended to mean "The license must allow modifications and derived works, and it must be possible to provide all recipients with a full set of DFSG rights". The current language has the advantage of not being self-referential, which might explain it to some extent. Does anyone actually have any compelling reason for believing that the literal interpretation is what was meant? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, 2005-13-01 at 15:58 -0500, Raul Miller wrote: > On Thu, Jan 13, 2005 at 03:19:36PM -0500, Grzegorz B. Prokopski wrote: > > > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > > > > "However, when the interpreter is extended to provide "bindings" to > > other facilities (often, but not necessarily, libraries), the > ... > > Do you understand that an interpreter for Java IS such an interpreter > > that provides "bindings" to other facilities? > > But was Kaffe _extended_ to provide such bindings for Eclipse 3.0? This FAQ entry discusses 2 cases. One is when we have an interpreter, that basically goes over the pseudo-code and purely "interprets" it (an old BASIC interpreter would fit here). No Java VM/interpreter _ever_ fits in this first, simple casse. Second case is where the code being interpreted may request to access bindings provided by the JVM. In Java these are done thru JNI calls, so usually JVM itself is a JNI library that provides these bindings. So an interpreter has to be "extended" to provide these "bindings" to other facilities. In such case, as the FAQ states "the interpreted program is effectively linked to the facilities it uses through these bindings." > Or is Eclipse 3.0 using only the facilities which Kaffe provides for > arbitrary byte code? There is nothing in the FAQ that would suggest that these "facilities" have to be provided for a specific program. On the contrary. A Java Virtual Machine (Java interpreter) inevitably has to provide such bindings to support Java specification. In other words the interpreter itself has to be extended with a library that provides these bindings to support Java specs. There's plenty of these bindings required to exist in core java.lang.* classes. Hope this clarifies the issue, Grzegorz B. Prokopski -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> SableVM - Free, LGPL'ed Java VM http://sablevm.org Why SableVM ?!? http://sablevm.org/wiki/Features Debian GNU/Linux - the Free OS http://www.debian.org
Illustrating JVM bindings
On Thu, 2005-13-01 at 17:24 -0500, Raul Miller wrote: > On Thu, Jan 13, 2005 at 04:35:50PM -0500, Grzegorz B. Prokopski wrote: > > > But was Kaffe _extended_ to provide such bindings for Eclipse 3.0? > > > > This FAQ entry discusses 2 cases. One is when we have an interpreter, > > that basically goes over the pseudo-code and purely "interprets" it > > (an old BASIC interpreter would fit here). No Java VM/interpreter > > _ever_ fits in this first, simple casse. > > The FAQ discusses far more than 2 cases. > > I imagine you're concerned about this part: > > If a programming language interpreter is released under the GPL, > does that mean programs written to be interpreted by it must be under > GPL-compatible licenses? > When the interpreter just interprets a language, the answer is > no. The interpreted program, to the interpreter, is just data; > a free software license like the GPL, based on copyright law, > cannot limit what data you use the interpreter on. You can run it > on any data (interpreted program), any way you like, and there are > no requirements about licensing that data to anyone. > > However, when the interpreter is extended to provide "bindings" > to other facilities (often, but not necessarily, libraries), the > interpreted program is effectively linked to the facilities it uses > through these bindings. So if these facilities are released under > the GPL, the interpreted program that uses them must be released in > a GPL-compatible way. The JNI or Java Native Interface is an example > of such a binding mechanism; libraries that are accessed in this way > are linked dynamically with the Java programs that call them. These > libraries are also linked with the interpreter. If the interpreter > is linked statically with these libraries, or if it is designed to > link dynamically with these specific libraries, then it too needs > to be released in a GPL-compatible way. > > > Second case is where the code being interpreted may request to access > > bindings provided by the JVM. In Java these are done thru JNI calls, > > so usually JVM itself is a JNI library that provides these bindings. > > > > So an interpreter has to be "extended" to provide these "bindings" to > > other facilities. In such case, as the FAQ states "the interpreted > > program is effectively linked to the facilities it uses through these > > bindings." > > Is this relevant to Eclipse? I was under the impression that Eclipse > was pure java -- that it did not use JNI at all. > > If Eclipse does use JNI, would still a question about whether or not > Kaffe's JNI implementation constitute some kind of extension designed > to work around the GPL or whether they are some kind of implementation > of some Java standard. I fail to see anything in the FAQ you cited above about extensions designed to _work around GPL_. Please refrain from creating meanings. This is about the way Java works. You cannot merely interpret bytecode. The program you're interpreting has to be able to call back into the JVM (or if you wish into a JNI library that is bound to a VM) to be able to run at all. > > > Or is Eclipse 3.0 using only the facilities which Kaffe provides for > > > arbitrary byte code? > > > > There is nothing in the FAQ that would suggest that these "facilities" > > have to be provided for a specific program. > > There is nothing in the FAQ to suggest that a GPLed JNI implementation has > to be a problem for arbitrary code, though of course it does point out JNI > as a issue that can be a problem. But for problem resolution, the FAQ is > saying that certain things need to be released in a GPL-compatible way, > not that no release can happen. It says "if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way". The IPL/APL are not GPL-compatible, that is, they cannot be released in a GPL-compatible way. These "facilities" of a java interpreter are (usually) available via JNI, which is basically a library call interface (no magic here). These library calls have to be used by any program that runs on a JVM. That library is usually part of JVM, and in the case we're discussing, is whole GPLed. According to the above citation, it imposes that you must be able to release a program (the one you're running on a JVM, the one that uses these bindings) in a GPL-compatible way. You cannot do it for a program that is GPL-incompatible. > > On the contrary. A Java Virtual Machine (Java interpreter) inevitably > > has to provide such bindings to support Java specification. In other > > words the interpreter itself has to be extended with a library that > > provides these bindings to support Java specs. There's plenty of these > > bindings required to exist in core java.lang.* classes. > > > > Hope this clarifies the issue, > > You seem to be claiming that a JVM has to provide
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, Jan 13, 2005 at 03:29:13PM -0800, Michael K. Edwards wrote: > copyrightable. To get at the cases the FSF is shooting for, they > would have to use terms of art instead of "derivative or collective > works", and would have to insert far more draconian provisions to > create an action for breach of contract when GPL and non-GPL works are > combined. I think we might disagree about which cases the FSF is shooting for. That they've provided a FAQ which states things a certain way probably has more to do with the questions they've been asked than it does the design intent of the GPL. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why is graphviz package non-free?
On Thu, Jan 13, 2005 at 09:18:21PM +, Henning Makholm wrote: > To make what I fear explicit, here is a fleshed-out scenario: > 1. A writes a program and releases it under the current CPL. > 2. B takes A's program, hacks on it, distributes his Contributions > on a website under the current CPL. > 3. IBM notices B's modified program and decides that they would like > to include it in their proprietary program suite for frobitzing > foobars, with private modifications that they don't release > source for. So, > 4. IBM releases new version of CPL which gives IBM carte blanche to > do anything at all with covered code. > 5. C (a strawman for IBM) picks up B's modified program, makes some > inconsequential little changes and releases it under the new > amended CPL - as allowed by the original CPL under which B > distributed his changes. > 6. IBM picks up C's distribution and starts abusing B's contribution > proprietarily. The same thing is possible with the GPL, with it's "any later version" clause. For that matter, the same thing is possible with the BSD license, because it makes no attempt to provide copyleft protection. I don't think this is worth worrying about. -- Raul
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, 13 Jan 2005 18:21:52 -0500, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > "Michael K. Edwards" <[EMAIL PROTECTED]> writes: [snip] > > As is the creation of a critical essay on libc. But that's not a > > derivative work either. > > But an annotated edition of libc is. A program seems far more similar > to an annotated edition than to a critical essay -- since it includes > a copy of the library, after all, and pointers into it. A creatively human-annotated edition of the libc source code is certainly a derivative work if the source code has any expressive content at all (which I, NAL, think a court would certainly rule that it does). A creatively annotated edition of its header files may or may not be, to the extent that it can be defended as having used those header files entirely according to their functional aspect. A program that uses a libc binary through its published functional interface isn't, no matter what mechanical details of compiling against header files, linking statically or dynamically, etc. may be involved. At most it creates an uncopyrightable combination of the two. Copyright law protects expression, not function. It isn't even really the right tool to protect a software publisher's ownership right in binaries, which is one reason why most commercial software tries to force you to accept a license in order to use it. But even to the extent that binaries are copyrightable, and that copying and using a binary of libc requires a license under copyright, that's about libc itself and not a derivative work of libc. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, 2005-13-01 at 21:56 +0100, Måns Rullgård wrote: > "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > > > On Thu, 2005-13-01 at 20:58 +0100, Måns Rullgård wrote: > >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > >> > Now, in our case, Eclipse is linked agains a libraries that ARE GPLed. > >> > >> No, it is being interpreted by an interpreter that is covered by the > >> GPL. Even the FSF admits that this does not create a derived work. > > > > You really should reread FSF FAQ: > > > > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > > > > "However, when the interpreter is extended to provide "bindings" to > > other facilities (often, but not necessarily, libraries), the > > interpreted program is effectively linked to the facilities it uses > > through these bindings. So if these facilities are released under the > > GPL, the interpreted program that uses them must be released in a > > GPL-compatible way. The JNI or Java Native Interface is an example of > > such a binding mechanism; libraries that are accessed in this way are > > linked dynamically with the Java programs that call them. These > > libraries are also linked with the interpreter. If the interpreter is > > linked statically with these libraries, or if it is designed to link > > dynamically with these specific libraries, then it too needs to be > > released in a GPL-compatible way." > > > > Do you understand that an interpreter for Java IS such an interpreter > > that provides "bindings" to other facilities? > > The paragraph above concerns JNI interfaces to libraries *separate* > from the interpreter. For instance, one could imagine a JNI binding > to GNU readline. The use of such bindings is independent of the JVM > being used (bindings might not exist for all JVM implementations, but > that's irrelevant). The existence of a binding facility does not make > a program using them derived from the interpreter. In FSF logic, it > is derived from the bound libraries, no more, no less. It shows you have no idea how a JVM is organized. The "interpreter" part on which you're hanging so strongly is only part of a JVM. The part that actually gets to interpret the bytecode. But there's also a lot of functionality (think about it as a VM-specific library) that is being used from within java library, and via JNI bindings calls library functions of a JVM. Yes. A JVM migh be seen as an interpter + a library of native calls used by the java library. And in case we're discussing this native library is GPLed. > > Do you understand that a program being interpreted is effectively > > linked to these facilities it uses thru these bindings? > > Yes. Which bindings does Eclipse use? I told you. Plenty. And if we're making Eclipse Build-depend on a GPLed version of these, then we're explicitely forcing these bindings to be GPLed. > > Do you understand that in case we're discussing these facilities are > > released under the GPL? > > We are discussing the case where the interpreter is released under the > GPL, nothing has been said about third-party library bindings. As I said, JVM is not a "pure interpreter". Much of its functinality is exported in form of JNI bindings used from java library. Actually FSF FAQ says (could you *PLEASE* finally READ IT WITH UNDERSTADING?): "...other facilities (often, but not necessarily, libraries)" There's NOTHING about "thrid-party", they don't even have to be "libraries". > >> > Please see Linus's email I cited in my other emails for more info. > >> > > >> > Would it have been compiled against a differently licensed library, > >> > this particular problem would be solved. Wouldn't it? > >> > >> It is compiled against an interface, not an implementation. Which > >> particular implementation was used while compiling is irrelevant. > > > > Ok, so please compile Eclipse agains an *interface* which is not its > > implementation (covered by GPL, in our case). Sure, if you use ie. > > some stubs covered by IPC-compatible license, I won't say a word. > > If the implementations are fully compatible, the compiled bytecode > should be bit-identical no matter which one was used. Does it matter? What however IS different is the fact which actual implementation you use as the interface against which you're compiling, and also with which implementation of library an app will be used. These informations are explicitely and clearly encoded in debian control files. > > But in our case you're using an implementation that also at the same > > time defines the interface (this if functional equivalent of header > > files). You cannot simply take a GPL implementation, compile against it > > (never mind whether it's C, Java, Python or whatever), and they claim > > you just didn't create a derivative work of the implementation you used. > > That's precisely what I am claiming, and several court cases support > my claim. Voila! let's make glibc GPLed! > > Please look at FS
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, 13 Jan 2005 16:16:53 -0500, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: [quoting Michael Poole] > > It is not hard: Some distribution of Eclipse is only encumbered by the > > GPL if it requires a GPLed work to correctly operate. You may have > > some odd version of Eclipse, but the standard releases have no such > > requirement. A distribution of Eclipse is only encumbered by the GPL if it is a derivative work of the GPL, such as by cut-and-paste of a piece of GPL code in excess of "de minimis" standards. The GPL simply doesn't address the "needs GPL code to work properly" case; consider Makefiles that only work with GNU make. [snip] > Some distribution of Eclipse is encumbered by the GPL if it, that > distribution, includes a copy of a GPL'd work (and it is not mere > aggregation, which this certainly isn't). So shipping Eclipse+Kaffe > is not OK. Shipping Eclipse+otherJVM is fine. Copies are OK, derivative works aren't. Eclipse+Kaffe isn't a derivative work and doesn't create one during execution either. Cheers, - Michael
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > "Michael K. Edwards" <[EMAIL PROTECTED]> writes: > >> [no longer relevant to debian-java, I think] >> >> On Thu, 13 Jan 2005 15:28:57 -0500, Brian Thomas Sniffen >> <[EMAIL PROTECTED]> wrote: >> [snip] >>> You are ignoring the >>> creative act performed by the programmer who arranged calls to >>> functions within libc. That was creative effort on his part which >>> critically involves a copy of libc. >> >> As is the creation of a critical essay on libc. But that's not a >> derivative work either. > > But an annotated edition of libc is. A program seems far more similar > to an annotated edition than to a critical essay -- since it includes > a copy of the library, after all, and pointers into it. Now you stopped making sense. A program includes only references to a library, not the library itself. A distribution, e.g. Debian, might include both the program and the library. I don't see a problem with distributing a collection of programs, where some of them can be combined in ways that violate some license, as long as all of them still have legitimate uses. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why is graphviz package non-free?
Scripsit Andrew Suffield <[EMAIL PROTECTED]> > On Thu, Jan 13, 2005 at 04:09:17PM +, Henning Makholm wrote: >> I am not convinced that this is free, but I strongly doubt that the >> people at graphviz org intended it either. > The Program (including Contributions) may always be distributed > subject to the version of the Agreement under which it was > received. In addition, after a new version of the Agreement is > published, Contributor may elect to distribute the Program > (including its Contributions) under the new version. Yes, but "the version of the Agreement under which it was received" already gives recipients further downstream the option of using an unknown future IBM licence. If you remove this option (say, because you don't trust IBM), you are not distributing the program "subject to the version of the Agreement under which it was received." To make what I fear explicit, here is a fleshed-out scenario: 1. A writes a program and releases it under the current CPL. 2. B takes A's program, hacks on it, distributes his Contributions on a website under the current CPL. 3. IBM notices B's modified program and decides that they would like to include it in their proprietary program suite for frobitzing foobars, with private modifications that they don't release source for. So, 4. IBM releases new version of CPL which gives IBM carte blanche to do anything at all with covered code. 5. C (a strawman for IBM) picks up B's modified program, makes some inconsequential little changes and releases it under the new amended CPL - as allowed by the original CPL under which B distributed his changes. 6. IBM picks up C's distribution and starts abusing B's contribution proprietarily. If this sequence is _not_ possible according to the license text, I'd be very happy to be convinced otherwise. But as it is, it seems to me that 7. In effect, the license requires B to give IBM rights to B's code that B did not himself get to A's code. I think we agree that (7) is non-free, but perhaps we disagree about whether (7) actually follows from the license? -- Henning Makholm "Monsieur, vous êtes fou."
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, 13 Jan 2005 17:02:52 -0500, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: [snip] > Why are copies OK, and derivative works not? I see GPL 2b talking > about any work that in whole or in part contains the Program. > Eclipse+Kaffe contains Kaffe, GPL 2 then exempts mere aggregation -- > which this is not. It also exempts separate sections *when > distributed separately* -- and explicitly covers them when the Program > is distributed as a whole. GPL section 2 is all about "works based on the Program", read in the context of copyright law. Later in that section, it says that "the intent is to exercise the right to control the distribution of derivative or collective works based on the Program." Eclipse+Kaffe isn't a "work based on the Program" because it isn't copyrightable as a derivative or collective work. In other words, you can't combine Eclipse and Kaffe, by running Eclipse on Kaffe, and then sue me for copyright infringement for doing the same. The "mere aggregation ... on a volume of storage or distribution medium" bit may clarify the contract writer's intent to some degree, but it doesn't automatically make other ways of combining two works copyrightable. To get at the cases the FSF is shooting for, they would have to use terms of art instead of "derivative or collective works", and would have to insert far more draconian provisions to create an action for breach of contract when GPL and non-GPL works are combined. > That feels like it's written to address this particular case -- or at > least a tarball containing Kaffe and Eclipse. This is similar enough > to count, it's just a funny compression scheme. It's written to address that case, all right; but I think that it's irrelevant and that the FSF is trying (unsuccessfully) to have it both ways. By inserting the "mere aggregation is OK" clause, and by publishing an aggressive stance on other forms of combination in their FAQ, the FSF tries to control interpretation and distract from the fact that courts will interpret "derivative or collective works" according to their meaning in the copyright law context that the preamble proclaims. Meanwhile, they claim the existence of a "law of license" outside contract law (with no basis that I can find), trying to avoid contract law standards such as "balance of harms" and take advantage of the relative ease of obtaining a preliminary injunction under copyright law. As I have detailed previously, the Progress Software v. MySQL case makes it pretty clear that they don't succeed in avoiding contract law standards once they actually get into court. Also, the judge in that case didn't rule on the factual issue of whether Progress Software had created a derivative work, but did make it quite clear that the FSF has no more authority on that point than any other expert witness that files an affidavit. The question "does linking create a derivative work" won't really be settled in the US unless and until a new case arises, is adjudicated in a court of fact, is appealed, and is properly analyzed with reference to precedent by a circuit court. I think (IANAL) that the outcome is quite predictable in light of precedents I have cited from several circuits. Ultimately, linking against the public interface to a published library doesn't detract from the rights in authorship that copyright law was created to protect, and US appellate courts are surprisingly good at sticking to the purpose of copyright in the face of legal and technical contortions that attempt to leverage a copyright monopoly beyond its legitimate bounds. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
[no longer relevant to debian-java, I think]
On Thu, 13 Jan 2005 15:28:57 -0500, Brian Thomas Sniffen
<[EMAIL PROTECTED]> wrote:
[snip]
> You are ignoring the
> creative act performed by the programmer who arranged calls to
> functions within libc. That was creative effort on his part which
> critically involves a copy of libc.
As is the creation of a critical essay on libc. But that's not a
derivative work either.
A contract could contain a clause to the effect of: "FooSoft is an
unpublished work of BigSoft, Inc. You may extend it, for use within
your organization, by writing programs that use the unpublished API
contained in foosoft.h and linking against foosoft.a or foosoft.so.
You may not distribute the result outside your organization, with or
without inclusion of material owned by FooSoft, unless you do X, Y,
and Z." This differs from the GPL in two respects: publication status
of the work and its interface, and use of a term of art rather than
status as a derivative work to define the scope of the conditional
license.
If you violate this clause by not doing X, Y, and Z, depending on
whether BigSoft could demonstrate your acceptance of this contract,
they could sue for breach of contract or for copyright infringement.
The breach of contract claim would be based on what you did (link
against foosoft.{a,so}), not on the copyright status of the results.
A breach of contract claim would probably also claim misappropriation
of trade secrets in foosoft.h; but GPL works are published, so you
don't have to cleanroom reverse engineer an API in order to claim that
you didn't breach contract by using the header files in an unapproved
manner.
A suit for copyright infringement would hinge on whether a recipient
who runs your program is infringing BigSoft's copyright, and hence
whether you are liable for contributory infringement. But your
program is not, by itself on paper, a derivative work of FooSoft, and
you were within your rights to run it yourself while developing it, so
a claim of direct infringement just won't wash. (IANAL, etc.) See
Micro Star v. Formgen for a similar scenario.
Cheers,
- Michael
Re: why is graphviz package non-free?
Scripsit Glenn Maynard <[EMAIL PROTECTED]> > I have difficulty thinking of anything a commercial user of software > could do that would cause the upstream author to legitimately be sued > in the first place--if the problem is really caused by my action, then > the author being sued is frivilous almost by definition. > I suppose I could cause that through misrepresentation, but I'd expect > to be liable in that case anyway (once it found its way back to me). That's kind of my problem too. -- Henning Makholm "We will discuss your youth another time."
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Michael K. Edwards" <[EMAIL PROTECTED]> writes: > [no longer relevant to debian-java, I think] > > On Thu, 13 Jan 2005 15:28:57 -0500, Brian Thomas Sniffen > <[EMAIL PROTECTED]> wrote: > [snip] >> You are ignoring the >> creative act performed by the programmer who arranged calls to >> functions within libc. That was creative effort on his part which >> critically involves a copy of libc. > > As is the creation of a critical essay on libc. But that's not a > derivative work either. But an annotated edition of libc is. A program seems far more similar to an annotated edition than to a critical essay -- since it includes a copy of the library, after all, and pointers into it. -Brian -- Brian Sniffen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > On Thu, 2005-13-01 at 15:58 -0500, Raul Miller wrote: >> On Thu, Jan 13, 2005 at 03:19:36PM -0500, Grzegorz B. Prokopski wrote: >> >> > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL >> > >> > "However, when the interpreter is extended to provide "bindings" to >> > other facilities (often, but not necessarily, libraries), the >> ... >> > Do you understand that an interpreter for Java IS such an interpreter >> > that provides "bindings" to other facilities? >> >> But was Kaffe _extended_ to provide such bindings for Eclipse 3.0? > > This FAQ entry discusses 2 cases. One is when we have an interpreter, > that basically goes over the pseudo-code and purely "interprets" it > (an old BASIC interpreter would fit here). No Java VM/interpreter > _ever_ fits in this first, simple casse. I think you're making untenable conclusions based on your knowledge of accidents of implementation of Java VMs. A Java bytecode interpreter is just an interpreter. The class libraries matter, and the libraries exposed through the JNI interface matter. > On the contrary. A Java Virtual Machine (Java interpreter) inevitably > has to provide such bindings to support Java specification. In other > words the interpreter itself has to be extended with a library that > provides these bindings to support Java specs. There's plenty of these > bindings required to exist in core java.lang.* classes. This confuses me, though. Can you provide an unambiguous example? -Brian -- Brian Sniffen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > Måns Rullgård <[EMAIL PROTECTED]> writes: > >> The Eclipse authors do not tell you which JVM to use. > > But Debian does, when it says: > Depends: j2re1.4 | j2re1.3 | java2-runtime > > So the eclipse-platform distributed by Debian *does* call on a > particular JVM. And it isn't kaffe, it's Sun's. Then why on earth does the license of Kaffe have any relevance whatsoever to Eclipse? > We do document the technical fact that you can programatically > substitute kaffe for any java-runtime. So? How does this make Eclipse a derivative of Kaffe? >> It is compiled against an interface, not an implementation. Which >> particular implementation was used while compiling is irrelevant. > > Can you support this assertion? The program, including its libraries, > which the developer intends to put on end-user systems appears quite > relevant to me. If I write a program in Java (it has happened), I intend for the end-user to run it under any JVM of his choice. I don't care which one chooses. The only reason I can see for suggesting a specific implementation is for support issues, e.g. "we only provide support for running our product under JVM implementation X". -- Måns Rullgård [EMAIL PROTECTED]
Re: how to mention GPL in the debian/copyright file
On Thu, 13 Jan 2005, Henning Makholm wrote: > Scripsit Jochen Voss <[EMAIL PROTECTED]> > > Recently Justin Pryzby filed bug #290087 against chbg, claiming > > that the debian/copyright file should instead contain "the 3 > > paragraphs as found in > > /usr/share/debhelper/dh_make/native/copyright", which turn out to > > be > > [snip standard GPL blob] > > > 1) Is it required to include the above three paragraphs into the > > debian/copyright file? > > What you should include is the exact notice found in the upstream > source which says that the program is covered by the GPL. As far as > I can see from a random sample (src/fnmatch.c) from the source > package, this notice happens to be identical to the blurb you quoted > from debhelper, but if it had been different, you should add the > notice actually found in the upstream source. I actually missed this particular one... fnmatch.c is not copyrighted by Stefan Ondrejicka either. Nor is gtkclrbutton.c. The copyright file needs to include the copyright statements for the different works that have been included in chbg, since there are at least 5 copyright holders that I've identified so far. (FSF, Stefan, Peter, Spencer, and Josh.) [I'm ignoring the auto* stuff, but since that's owned by the FSF as well, you're probably ok.] Don Armstrong -- If it jams, force it. If it breaks, it needed replacing anyway. -- Lowery's Law http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, 2005-13-01 at 15:28 -0500, Brian Thomas Sniffen wrote: > "Michael K. Edwards" <[EMAIL PROTECTED]> writes: > > > On Thu, 13 Jan 2005 12:21:51 -0500, Brian Thomas Sniffen > > <[EMAIL PROTECTED]> wrote: > > [snip] > >> So in answer to your direct question: the unlinked binary isn't > >> derived from any of them. The complete binary, including its > >> libraries, included whichever one Debian shipped it with. > > > > No, it's not a derivative work in a copyright sense at any stage. > > I didn't say it was. I said that the complete program includes the > libraries. That is, the program called vim distributed by Debian > includes libc, because when I say "apt-get install vim" I get libc6 > installed onto my system, and when I then instruct my computer to run > vim, it loads libc and some vim-specific code into memory. > > > That's a phrase with a legal meaning, and combining by any means that > > isn't itself a creative act doesn't create one. > > I understand that quite well, thank you. You are ignoring the > creative act performed by the programmer who arranged calls to > functions within libc. That was creative effort on his part which > critically involves a copy of libc. > > Put differently: my claim is not that vim is derivative of libc. My > claim is that Vim includes a copy of libc! It may also be a > derivative -- I don't think the vim-specific parts are, but the > vim-specific parts plus the libc copy might be. I think Debian 'control' files that state Build-depends: and Depends: show quite explicitely what pieces of software Debian distributes "bound together", which is actually rather nice. Of course (just to make sure nobody misunderstands) having a GPL-incompatible program depend on a GPL program is not yet a problem. But if such a program is linked against GPLed libraries, whose are additionally constrained by explicit 'depends' on a specific library, it pretty much says: a) when you apt-get source, we'll compile this GPL-incompatible program against this GPLed library b) when you apt-get install, we'll run this GPL-incompatible program with a GPLed library. Putting it differently: if that was allowed, then why do we need glibc to be LGPLed, and not GPLed? After all the C language and its basic libraries are also standarized to great extent. But having glibc purely GPL just doesn't sound good, does it? Grzegorz B. Prokopski -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> SableVM - Free, LGPL'ed Java VM http://sablevm.org Why SableVM ?!? http://sablevm.org/wiki/Features Debian GNU/Linux - the Free OS http://www.debian.org
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
> It is not hard: Some distribution of Eclipse is only encumbered by the > GPL if it requires a GPLed work to correctly operate. You may have > some odd version of Eclipse, but the standard releases have no such > requirement. While most of what you said seemed perfectly reasonable, this does not. Some distribution of Eclipse is encumbered by the GPL if it, that distribution, includes a copy of a GPL'd work (and it is not mere aggregation, which this certainly isn't). So shipping Eclipse+Kaffe is not OK. Shipping Eclipse+otherJVM is fine. I do not think anyone will disagree with this. Can we now confine this argument to whether a program distributed as a package with Depends: jre | java-runtime contains a copy of a package with Provides: java-runtime? I'm inclined to say no, that that is not the intended operating state, merely an incidental of technically compatible packages -- and so even if Eclipse had a Depends: some-non-kaffe-jvm | java-runtime and Kaffe a Provides: java-runtime, there would be no conflict with the GPL here. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Måns Rullgård <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > >>> It is not hard: Some distribution of Eclipse is only encumbered by the >>> GPL if it requires a GPLed work to correctly operate. You may have >>> some odd version of Eclipse, but the standard releases have no such >>> requirement. >> >> While most of what you said seemed perfectly reasonable, this does >> not. >> >> Some distribution of Eclipse is encumbered by the GPL if it, that >> distribution, includes a copy of a GPL'd work (and it is not mere >> aggregation, which this certainly isn't). So shipping Eclipse+Kaffe >> is not OK. Shipping Eclipse+otherJVM is fine. > > Your definition of "include" appears to be a little broader than the > one most of us use. I am using the plain English meaning: if I ship you a CD with Eclipse and Kaffe so that all you have to do is double-click some icon and it runs, that is a distribution of Eclipse including Kaffe. >> I do not think anyone will disagree with this. Can we now confine >> this argument to whether a program distributed as a >> package with Depends: jre | java-runtime contains a copy of a package >> with Provides: java-runtime? >> >> I'm inclined to say no, that that is not the intended operating state, >> merely an incidental of technically compatible packages -- and so even >> if Eclipse had a Depends: some-non-kaffe-jvm | java-runtime and Kaffe >> a Provides: java-runtime, there would be no conflict with the GPL here. > > You're starting to make sense. Merely because I'm reaching a conclusion which you find palatable? This reasoning is grounded on the same axioms and rules I've been using all along. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Firefox/Thunderbird trademarks: a proposal
Here's my attempt at something which hopefully everyone can accept. I've tried to take into account all the excellent feedback over the past few weeks, for which I thank all involved. Comments are in square brackets. This assumes that DFSG #8 means that Debian can be given rights over and above the rights necessary to make a program free, as long as all the rights necessary to make it free are transferable. 1) The Foundation grants Debian, and all redistributors of the official Debian packages of the Foundation's products, the right to label those packages with a name containing the trademark. [This document would apply to "Firefox", "Thunderbird", and any other trademarks on software names we may hold in future. The name would be Firefox, Community Edition or whatever is agreed between the Foundation and the maintainer. It's not important to this document.] 2) The Foundation agrees to document the procedure for changing the name to its satisfaction, for the benefit of Debian and anyone else, and to work to make that procedure as simple as possible. [This means that if you or a Debian redistributor ever has to change the name, it hopefully won't be too onerous. And it means we can't blindside anyone with 'but you forgot to change *this* instance".] 3) The Foundation will review the current Debian package at freeze time, and at other times at their discretion, and bring any issues they have to the attention of the maintainer. The maintainer is not responsible for notifying the Foundation of any changes he may make to the package, or obligated to make any change that the Foundation may suggest. However, in the unlikely event of irreconcilable differences occurring between the maintainer and the Foundation, the name of the package will have to be changed in all as-yet-unreleased versions of Debian. [This gives you a free hand over the development process, and us the oversight that we need by law to be seen to be having.] 4) The Foundation agrees not to withdraw the permission more than three months into a freeze. [This is intended to mean that we can't require an inconvenient change just when you are about to release; if we don't notice until it's too late, it's our problem. My understanding of the Debian process is not complete; 'freeze' may not be the correct term here.] 5) The Foundation agrees not to withdraw the permission for versions of the product shipping in stable releases of Debian, provided all updates to the package are within Debian's guidelines for package updates in stable releases. [You have carte blanche to make security fixes. We are happy because your own procedures say you can't gut the package and replace it with something different. And you are happy because you have to follow your own procedures anyway, so it's not a burden.] 6) The Foundation agrees that it's not Debian's responsibility to make sure the distributors of any derivative works of Debian packages have an implicit or explicit trademark license from the Foundation. [No hassle for you.] 7) The Foundation requests that Debian document, in a place where it might be seen by package modifiers, the potential need to acquire such a trademark licence. [I hope you would view such a notice as a service to your users - but distributors of modified versions may need a license whether you add the notice or not. This is hopefully in line with DFSG #4, which says that packages are free even if derived works are required to carry a different name. It is also in line with free software licenses where changes require other changes, e.g. the GPL 2a) where code changes must be documented.] Is this a runner? Gerv One final note: I can't completely exclude the possibility that someone higher up at the Foundation (e.g. Mitchell Baker) will say that I've overreached myself. But I don't know of any reason why that would be the case, and I'm negotiating in good faith. I would, of course, get a final version approved by all necessary parties :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > Which Eclipse packages? The old ones we have in SID now? Irrelevant. > There would have been nothing whatsoever to discuss in such case. > > The *new* Eclipse packages that are being prepared now and which we've > been discussing (I already said it in another email, but you must > have crossed yours) have it this way: > > Build-depends: kaffe > Depends: kaffe | java2-runtime > > [ From http://kyoto.larvalstage.net/ubuntu/warty/ ] > > So a user who does either 'apt-get source eclipse' or 'apt-get install > eclipse' will link (either at compilation time or at runtime) to Kaffe's > Java library, and to Kaffe JVM bindings which are all GPL. > > I hope this clarifies _at least_ this issue. Can you clarify one more? Is Eclipse then just building as well-specified JVM code, or is it linking against GPL'd class libraries as well? I don't actually know whether Kaffe is a JVM or also includes the rest of the Java runtime environment. -Brian -- Brian Sniffen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > On Thu, 2005-13-01 at 20:58 +0100, Måns Rullgård wrote: >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> > Now, in our case, Eclipse is linked agains a libraries that ARE GPLed. >> >> No, it is being interpreted by an interpreter that is covered by the >> GPL. Even the FSF admits that this does not create a derived work. > > You really should reread FSF FAQ: > > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > > "However, when the interpreter is extended to provide "bindings" to > other facilities (often, but not necessarily, libraries), the > interpreted program is effectively linked to the facilities it uses > through these bindings. So if these facilities are released under the > GPL, the interpreted program that uses them must be released in a > GPL-compatible way. The JNI or Java Native Interface is an example of > such a binding mechanism; libraries that are accessed in this way are > linked dynamically with the Java programs that call them. These > libraries are also linked with the interpreter. If the interpreter is > linked statically with these libraries, or if it is designed to link > dynamically with these specific libraries, then it too needs to be > released in a GPL-compatible way." > > Do you understand that an interpreter for Java IS such an interpreter > that provides "bindings" to other facilities? The paragraph above concerns JNI interfaces to libraries *separate* from the interpreter. For instance, one could imagine a JNI binding to GNU readline. The use of such bindings is independent of the JVM being used (bindings might not exist for all JVM implementations, but that's irrelevant). The existence of a binding facility does not make a program using them derived from the interpreter. In FSF logic, it is derived from the bound libraries, no more, no less. > Do you understand that a program being interpreted is effectively > linked to these facilities it uses thru these bindings? Yes. Which bindings does Eclipse use? > Do you understand that in case we're discussing these facilities are > released under the GPL? We are discussing the case where the interpreter is released under the GPL, nothing has been said about third-party library bindings. > Do you understand that in case we're discussing even the java library > itself is under GPL? (or at least parts of it, which is about the same) Doesn't matter. There exist other implementations, and a program can't possibly be derived from more than one. Don't you see the inconsistency? >> > We are compiling GPL-incompatible code against purely GPLed headers. >> >> Who is compiling what code? Since when does Java have headers? > > Either you're not capable of abstracting notion of headers as they're > used in C, or not willing to do so. What do you think, in Java, > provides you with the informations that you're given thru headers in C? > >> > Please see Linus's email I cited in my other emails for more info. >> > >> > Would it have been compiled against a differently licensed library, >> > this particular problem would be solved. Wouldn't it? >> >> It is compiled against an interface, not an implementation. Which >> particular implementation was used while compiling is irrelevant. > > Ok, so please compile Eclipse agains an *interface* which is not its > implementation (covered by GPL, in our case). Sure, if you use ie. > some stubs covered by IPC-compatible license, I won't say a word. If the implementations are fully compatible, the compiled bytecode should be bit-identical no matter which one was used. > But in our case you're using an implementation that also at the same > time defines the interface (this if functional equivalent of header > files). You cannot simply take a GPL implementation, compile against it > (never mind whether it's C, Java, Python or whatever), and they claim > you just didn't create a derivative work of the implementation you used. That's precisely what I am claiming, and several court cases support my claim. > Please look at FSF FAQ once again, please try to understand what the Reading the same FUD over and over again isn't going to alter the logic of the universe. -- Måns Rullgård [EMAIL PROTECTED]
Re: how to mention GPL in the debian/copyright file
On Thu, 13 Jan 2005, Jochen Voss wrote: > I have a question about how to write the debian/copyright file > for packages which are distributed under the GPL. > > Currently the debian/copyright file of chbg contains the paragraph > > Chbg is copyrigthed by Ondrejicka Stefan ([EMAIL PROTECTED]). It is > license under the GPL. On Debian systems, the complete text of the > GNU General Public License can be found in the > /usr/share/common-licenses/GPL file. Unfortunatly, this is incorrect. The code is licensed under GPL 2 or later. (See below where I discuss the issues with this.) [SNIP] > My questions: > > 1) Is it required to include the above three paragraphs into the > debian/copyright file? The debian/copyright file must include the upstream's copyright statement. This typically includes the three paragraphs listed above. In your case, it looks like the copyright statement is just the following: /***/ /* This code is part of Desktop Background changer*/ /* called ChBg*/ /* Copyright (c) 1999,2000 Ondrejicka Stefan */ /* ([EMAIL PROTECTED]) */ /* Distributed under GPL 2 or later */ /***/ However, I strongly suggest that you talk to upstream, and have upstream use the form of copyright statement and licensing statement mentioned in the GNU GPL itself, namely: Copyright (C) 19yy This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; see the file COPYING. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. > 2) In case it is not required, is it for some other reason > preferable to include them? It is preferable to include them from the upstream maintainer's point of view, because it makes it explicit what license the work is released under. In the case of this work, it's very difficult to accertain what license the images are released under, as there is no LICENSE or similar file that contains a copyright statement and license statement covering the entire archive. While this may seem a bit overdone, it's really in the best interest of the upstream maintainer to follow the instructions of the GNU GPL when upstream places code under the GPL. Don Armstrong -- There are two types of people in this world, good and bad. The good sleep better, but the bad seem to enjoy the waking hours much more. -- Woody Allen http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to mention GPL in the debian/copyright file
Hello Henning, thank you for your help. On Thu, Jan 13, 2005 at 10:25:58PM +, Henning Makholm wrote: > What you should include is the exact notice found in the upstream > source which says that the program is covered by the GPL. Does this mean we need all the notes from the source files with duplicates removed? Do you have any reference for this? Maybe debian-policy (this is where I looked) could be changed to include this information? I find for example the appended notices. Should I replace my text blurb by the concatenation of all these notices? Does different white space count as being different? Now confused, Jochen PS.: I looked at the vroot.h license (last one in my list) which I did not spot before. I think is is ok for our purposes. Do you agree? == * from the README: This is public release of ChBg distributed under GPL. [...] License : - Chbg is licensed under terms of GPL. See COPYING. * from src/absimg.c: /***/ /* This code is part of Desktop Background changer*/ /* called ChBg*/ /* Copyright (c) 1999 - 2001 Ondrejicka Stefan*/ /* ([EMAIL PROTECTED]) */ /* Distributed under GPL 2 or later */ /***/ * from src/gdk_imlib1.c: (different copyright year) /***/ /* This code is part of Desktop Background changer*/ /* called ChBg*/ /* Copyright (c) 1999,2000 Ondrejicka Stefan */ /* ([EMAIL PROTECTED]) */ /* Distributed under GPL 2 or later */ /***/ * from fnmatch.c: (different copyright holder) /* Copyright (C) 1991, 1992, 1993, 1996, 1997 Free Software Foundation, Inc. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ * from gimpgradient.c: (even more different copyright holder) /* The GIMP -- an image manipulation program * Copyright (C) 1995 Spencer Kimball and Peter Mattis * * Gradient editor module copyight (C) 1996-1997 Federico Mena Quintero * [EMAIL PROTECTED] * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURIGHTE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ * from gtkgbpixmap.c: (gimp again, but different names) /* GTK - The GIMP Toolkit * Copyright (C) 1995-1997 Peter Mattis, Spencer Kimball and Josh MacDonald * GtkBgPixmap Copyright (C) 2000 Stefan Ondrejicka <[EMAIL PROTECTED]> * * Insensitive pixmap building code by Eckehard Berns from GNOME Stock * Copyright (C) 1997, 1998 Free Software Foundation * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Library General Public * License as published by the Free Software Foundation; either * version 2 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Library General Public License for more details. * * You should have received a copy of the GNU Library General Public * License along with this library; if not, write to the * Free S
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, Jan 13, 2005 at 03:19:36PM -0500, Grzegorz B. Prokopski wrote: > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > > "However, when the interpreter is extended to provide "bindings" to > other facilities (often, but not necessarily, libraries), the ... > Do you understand that an interpreter for Java IS such an interpreter > that provides "bindings" to other facilities? But was Kaffe _extended_ to provide such bindings for Eclipse 3.0? Or is Eclipse 3.0 using only the facilities which Kaffe provides for arbitrary byte code? -- Raul
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, 13 Jan 2005 15:19:36 -0500, Grzegorz B. Prokopski <[EMAIL PROTECTED]> wrote: [snip] > But in our case you're using an implementation that also at the same > time defines the interface (this if functional equivalent of header > files). You cannot simply take a GPL implementation, compile against it > (never mind whether it's C, Java, Python or whatever), and they claim > you just didn't create a derivative work of the implementation you used. On the contrary; that doesn't create a derivative work under copyright law, no matter who (other than a legislature or a sitting court) says it does. Cheers, - Michael
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, 2005-13-01 at 22:51 +0100, Måns Rullgård wrote: > >> > Do you understand that a program being interpreted is effectively > >> > linked to these facilities it uses thru these bindings? > >> > >> Yes. Which bindings does Eclipse use? > > > > I told you. Plenty. And if we're making Eclipse Build-depend on > > a GPLed version of these, then we're explicitely forcing these bindings > > to be GPLed. > > Guess what, Eclipse does not have a Build-depends on any GPLd JVM. It > has a Build-depends on j2sdk1.3 | j2sdk1.4, which are virtual > packages. Guess what else, Kaffe doesn't provide either of these. > Surprised? I'm amused. Which Eclipse packages? The old ones we have in SID now? Irrelevant. There would have been nothing whatsoever to discuss in such case. The *new* Eclipse packages that are being prepared now and which we've been discussing (I already said it in another email, but you must have crossed yours) have it this way: Build-depends: kaffe Depends: kaffe | java2-runtime [ From http://kyoto.larvalstage.net/ubuntu/warty/ ] So a user who does either 'apt-get source eclipse' or 'apt-get install eclipse' will link (either at compilation time or at runtime) to Kaffe's Java library, and to Kaffe JVM bindings which are all GPL. I hope this clarifies _at least_ this issue. GBP -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> SableVM - Free, LGPL'ed Java VM http://sablevm.org Why SableVM ?!? http://sablevm.org/wiki/Features Debian GNU/Linux - the Free OS http://www.debian.org
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Grzegorz B. Prokopski writes: > Do you understand that an interpreter for Java IS such an interpreter > that provides "bindings" to other facilities? > > Do you understand that a program being interpreted is effectively > linked to these facilities it uses thru these bindings? > > Do you understand that in case we're discussing these facilities are > released under the GPL? Do you understand that the user has non-GPL options for those facilities, that the program works perfectly well with those non-GPL options, and that the user's choice to use a GPLed facility does not encumber the program? > Do you understand that in case we're discussing even the java library > itself is under GPL? (or at least parts of it, which is about the same) Do you understand that the FSF (and especially not the GPL FAQ) is not the final authority on questions of law? If you want to hear it from them, ask licensing_at_gnu_dot_org if that part of the FAQ applies when the linked APIs are part of the standard Java API. It is not hard: Some distribution of Eclipse is only encumbered by the GPL if it requires a GPLed work to correctly operate. You may have some odd version of Eclipse, but the standard releases have no such requirement. Michael Poole
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On 13 Jan 2005 15:05:36 -0500, Michael Poole <[EMAIL PROTECTED]> wrote: > Grzegorz B. Prokopski writes: [snip] > > Even according to Linus such "use" is not permitted > > > > http://seclists.org/lists/linux-kernel/2003/Dec/1042.html > > Linux header files are different from Java packages in a number of > ways. > > One difference is that C header files, especially those from Linux, > contain function bodies as well as function declarations; Java > packages define a functional interface but do not insert expressive > content in a file that imports the package. There's a case that functional use of these header files, in the course of compilation to create object code, doesn't create a derivative work even if the intermediate result of C preprocessing contains fragments in excess of a "de minimis" standard. As the Lexmark court pointed out, copyright infringement happens when use is made of the expressive content in creating a derivative work, but even "functional" use of the entire content needn't constitute infringement. I think (IANAL) that a court is especially likely to rule this direction if there is an added interoperability-related defense such as "we were following the only practical method of circumventing a technical restriction through a protected form of reverse engineering" (Lexmark) or "we were using the published API of a work which is licensed under terms which only attempt to reach derivative works" (Linux). >From another point of view, if a C header file is commonly understood to contain a public, arm's-length interface between one person's code and another's, then there can only be two reasons to embed fragments of code in excess of "de minimis" in that header file: because that's the practical, functional choice (in which case using them via the published API still doesn't create a derivative work) or because one is trying to force competitors to create a derivative work in order to interoperate. The latter case (which is related to the Lexmark facts and to situations like ICQ's use of partial checksums of the WinAIM binary) is often considered an attempt to abuse the statutory monopoly granted in copyright law, leading to decisions like Lexmark. > Another difference is that Linux is the only implementation of many > functions; using those means that you require Linux specifically, and > cannot use an alternative such as the FreeBSD kernel. Courts do use this sort of test when deciding whether a use that is prima facie a form of copyright infringement is justifiable under a "fair use" defense. (Compare Sony v. Connectix, Sega Enterprises, and Atari I, all cited in Lexmark, and see also Micro Star v. Formgen, in which Micro Star lost because the only way in which the works they published were usable was to feed them to the Duke Nukem engine and thereby create "derivative works" in the classical sense of sequels using the same characters and setting.) I doubt (IANAL) that a discussion about a published API, used under the terms of a license which only addresses the status of derivative works, would ever get that far. Cheers, - Michael
Re: why is graphviz package non-free?
Scripsit Raul Miller <[EMAIL PROTECTED]> > On Thu, Jan 13, 2005 at 09:18:21PM +, Henning Makholm wrote: >> To make what I fear explicit, here is a fleshed-out scenario: >> 1. A writes a program and releases it under the current CPL. >> 2. B takes A's program, hacks on it, distributes his Contributions >> on a website under the current CPL. >> 3. IBM notices B's modified program and decides that they would like >> to include it in their proprietary program suite for frobitzing >> foobars, with private modifications that they don't release >> source for. So, >> 4. IBM releases new version of CPL which gives IBM carte blanche to >> do anything at all with covered code. >> 5. C (a strawman for IBM) picks up B's modified program, makes some >> inconsequential little changes and releases it under the new >> amended CPL - as allowed by the original CPL under which B >> distributed his changes. >> 6. IBM picks up C's distribution and starts abusing B's contribution >> proprietarily. > The same thing is possible with the GPL, with it's "any later version" > clause. No - the GPL would allow B to distribute his hacked code under "GPL, version 2 only" if he wants to prevent this. > For that matter, the same thing is possible with the BSD license, > because it makes no attempt to provide copyleft protection. No - the BSD license would allow B to distribute his hacked code under "GPL, version 2 only" if he wants to prevent this. The CPL does *not* allow B to distrubte his hacked code under "CPL, version 1 only". In fact, "CPL, version 1 only" is not even a internally consistent license specification, because CPL *intrinsically* allows any downstream recipient to switch everything to any later version published by IBM. -- Henning Makholm"Jeg køber intet af Sulla, og selv om uordenen griber planmæssigt om sig, så er vi endnu ikke nået dertil hvor ordentlige mennesker kan tillade sig at stjæle slaver fra hinanden. Så er det ligegyldigt, hvor stærke, politiske modstandere vi er."
GNU Classpath based execution environments (Was: Eclipse 3.0)
Hi, On Thu, 2005-01-13 at 12:21 -0500, Brian Thomas Sniffen wrote: > Måns Rullgård <[EMAIL PROTECTED]> writes: > > AFAIK, Eclipse uses only the standard Java API > > as published by Sun, and will run equally well with any implementation > > of said interface. > > Great -- which implementation does Debian ship it with? That's all > that really matters. Both runtimes in question (as most free runtimes) are based on the GNU Classpath core class library (which is the same as libgcj which comes with GCC and provides the runtime library for the gij interpreter and gcj ahead of time compiler). It is distributed under the terms mentioned here: http://www.gnu.org/software/classpath/license.html There have been questions about how this license precisely interacts when combined with other code (like the LGPL in the sablevm case and the GPL in the kaffe case). The FSF wants to make the intent of the GNU Classpath distribution terms as clear as possible and has setup a GNU Classpath license clarification wiki were people can add suggestions or concerns about the current wording (if any): http://www.gnu.org/licensing/classpath/ > > This whole discussion is something between ridiculous and hilarious, > > definitely not useful. > > If it causes even one person to understand that the generation or > transportation of a copy is what matters, and not technical > workarounds, I'll consider it useful. I believe this pissing contest between the sablevm and kaffe packagers is a big waste of time. There are obviously important issues to be worked out like the ASL and GPL compatibility and making sure the interpretations and intend of the various licenses are clear. But I don't believe the best way to do that is by constantly claiming someone else work is "illegal" and/or "a complete waste of time". Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: how to mention GPL in the debian/copyright file
Scripsit Jochen Voss <[EMAIL PROTECTED]> > Recently Justin Pryzby filed bug #290087 against chbg, claiming that > the debian/copyright file should instead contain "the 3 paragraphs as > found in /usr/share/debhelper/dh_make/native/copyright", which turn out > to be [snip standard GPL blob] > 1) Is it required to include the above three paragraphs into the > debian/copyright file? What you should include is the exact notice found in the upstream source which says that the program is covered by the GPL. As far as I can see from a random sample (src/fnmatch.c) from the source package, this notice happens to be identical to the blurb you quoted from debhelper, but if it had been different, you should add the notice actually found in the upstream source. -- Henning Makholm"We can hope that this serious deficiency will be remedied in the final version of BibTeX, 1.0, which is expected to appear when the LaTeX 3.0 development is completed." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, 2005-13-01 at 20:58 +0100, Måns Rullgård wrote: > "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > > Now, in our case, Eclipse is linked agains a libraries that ARE GPLed. > > No, it is being interpreted by an interpreter that is covered by the > GPL. Even the FSF admits that this does not create a derived work. You really should reread FSF FAQ: http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL "However, when the interpreter is extended to provide "bindings" to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a binding mechanism; libraries that are accessed in this way are linked dynamically with the Java programs that call them. These libraries are also linked with the interpreter. If the interpreter is linked statically with these libraries, or if it is designed to link dynamically with these specific libraries, then it too needs to be released in a GPL-compatible way." Do you understand that an interpreter for Java IS such an interpreter that provides "bindings" to other facilities? Do you understand that a program being interpreted is effectively linked to these facilities it uses thru these bindings? Do you understand that in case we're discussing these facilities are released under the GPL? Do you understand that in case we're discussing even the java library itself is under GPL? (or at least parts of it, which is about the same) > > We are compiling GPL-incompatible code against purely GPLed headers. > > Who is compiling what code? Since when does Java have headers? Either you're not capable of abstracting notion of headers as they're used in C, or not willing to do so. What do you think, in Java, provides you with the informations that you're given thru headers in C? > > Please see Linus's email I cited in my other emails for more info. > > > > Would it have been compiled against a differently licensed library, > > this particular problem would be solved. Wouldn't it? > > It is compiled against an interface, not an implementation. Which > particular implementation was used while compiling is irrelevant. Ok, so please compile Eclipse agains an *interface* which is not its implementation (covered by GPL, in our case). Sure, if you use ie. some stubs covered by IPC-compatible license, I won't say a word. But in our case you're using an implementation that also at the same time defines the interface (this if functional equivalent of header files). You cannot simply take a GPL implementation, compile against it (never mind whether it's C, Java, Python or whatever), and they claim you just didn't create a derivative work of the implementation you used. Please look at FSF FAQ once again, please try to understand what the issue is, maybe ask some (finally!) *technical* questions about java, interconnections between java library and a JVM, etc. But if you intend to waste everybody's time, as you've been doing so far - please, pretty please - go away! Grzegorz B. Prokopski -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> SableVM - Free, LGPL'ed Java VM http://sablevm.org Why SableVM ?!? http://sablevm.org/wiki/Features Debian GNU/Linux - the Free OS http://www.debian.org
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Michael K. Edwards" <[EMAIL PROTECTED]> writes: > On Thu, 13 Jan 2005 09:08:59 -0500, Brian Thomas Sniffen > <[EMAIL PROTECTED]> wrote: >> Combining X+Y in the way that you have described is anything but >> mechanical: it is a task which typically takes a skilled programmer a >> great amount of time and thought. Different programmers might do it >> in different ways. I'm not referring here to the work done by ld, but >> to the process of building a new program which has libfoo as a >> component. > > I agree that competent build integration is hard; I've done it many > times, and it's real work. But "work" isn't the criterion for > copyright; it's "inclusion of copyright material". No matter how > complex the ld incantation required, the action performed by that > incantation is mechanical and un-creative. The ld incantation might > be a copyrightable fragment, but X+Y isn't a copyrightable collection. > I think (IANAL). And in any case it isn't a derivative work. I largely addressed this in a separate message I just sent, so don't feel obliged to reply here as well -- but I'm not talking about the build integration. I'm talking about programming. >> Additionally, the program ultimately delivered to the user isn't X >> with some minor bits of Y. It contains big chunks of Y -- one per >> function used, at least -- directly copied. Just being in a different >> memory space isn't enough to change the relationship between the >> creative parts of the works. The program vim encompasses a copy of >> libc. > > Do you have precedent on this? Check out the Lexmark decision for an > example of how a court will slice things along a "functional vs. > expressive" plane to find that one piece of software that uses another > doesn't infringe its copyright unless a human has selected expressive > portions for copying into the flow of the new work's source code. I think you've missed my point here -- > Lifting an implementation from one code base and placing it in another > is copyright infringement (Cadence v. Avant!, etc.). Calling the > implementation via a public API isn't. And as for the "header > fragments" bit, I would expect a court to rule that they're entirely > functional and, even if they weren't, there's an implied license to > use them for their functional purpose. -- yup, definitely. I'm not convinced by header fragments either. I'm talking about the entire copy of libc put onto my system when I say "apt-get install vim". -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Michael K. Edwards" <[EMAIL PROTECTED]> writes: > On Thu, 13 Jan 2005 12:21:51 -0500, Brian Thomas Sniffen > <[EMAIL PROTECTED]> wrote: > [snip] >> So in answer to your direct question: the unlinked binary isn't >> derived from any of them. The complete binary, including its >> libraries, included whichever one Debian shipped it with. > > No, it's not a derivative work in a copyright sense at any stage. I didn't say it was. I said that the complete program includes the libraries. That is, the program called vim distributed by Debian includes libc, because when I say "apt-get install vim" I get libc6 installed onto my system, and when I then instruct my computer to run vim, it loads libc and some vim-specific code into memory. > That's a phrase with a legal meaning, and combining by any means that > isn't itself a creative act doesn't create one. I understand that quite well, thank you. You are ignoring the creative act performed by the programmer who arranged calls to functions within libc. That was creative effort on his part which critically involves a copy of libc. Put differently: my claim is not that vim is derivative of libc. My claim is that Vim includes a copy of libc! It may also be a derivative -- I don't think the vim-specific parts are, but the vim-specific parts plus the libc copy might be. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, Jan 13, 2005 at 04:35:50PM -0500, Grzegorz B. Prokopski wrote: > > But was Kaffe _extended_ to provide such bindings for Eclipse 3.0? > > This FAQ entry discusses 2 cases. One is when we have an interpreter, > that basically goes over the pseudo-code and purely "interprets" it > (an old BASIC interpreter would fit here). No Java VM/interpreter > _ever_ fits in this first, simple casse. The FAQ discusses far more than 2 cases. I imagine you're concerned about this part: If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses? When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone. However, when the interpreter is extended to provide "bindings" to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a binding mechanism; libraries that are accessed in this way are linked dynamically with the Java programs that call them. These libraries are also linked with the interpreter. If the interpreter is linked statically with these libraries, or if it is designed to link dynamically with these specific libraries, then it too needs to be released in a GPL-compatible way. > Second case is where the code being interpreted may request to access > bindings provided by the JVM. In Java these are done thru JNI calls, > so usually JVM itself is a JNI library that provides these bindings. > > So an interpreter has to be "extended" to provide these "bindings" to > other facilities. In such case, as the FAQ states "the interpreted > program is effectively linked to the facilities it uses through these > bindings." Is this relevant to Eclipse? I was under the impression that Eclipse was pure java -- that it did not use JNI at all. If Eclipse does use JNI, would still a question about whether or not Kaffe's JNI implementation constitute some kind of extension designed to work around the GPL or whether they are some kind of implementation of some Java standard. > > Or is Eclipse 3.0 using only the facilities which Kaffe provides for > > arbitrary byte code? > > There is nothing in the FAQ that would suggest that these "facilities" > have to be provided for a specific program. There is nothing in the FAQ to suggest that a GPLed JNI implementation has to be a problem for arbitrary code, though of course it does point out JNI as a issue that can be a problem. But for problem resolution, the FAQ is saying that certain things need to be released in a GPL-compatible way, not that no release can happen. > On the contrary. A Java Virtual Machine (Java interpreter) inevitably > has to provide such bindings to support Java specification. In other > words the interpreter itself has to be extended with a library that > provides these bindings to support Java specs. There's plenty of these > bindings required to exist in core java.lang.* classes. > > Hope this clarifies the issue, You seem to be claiming that a JVM has to provide non-standard JNI capabilities or it isn't a standard implementation of the JVM. I'm not sure what that is supposed to clarify. I'm rather doubtful that it's correct. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why is graphviz package non-free?
On Thu, Jan 13, 2005 at 04:43:57PM -0500, Raul Miller wrote: > The same thing is possible with the GPL, with it's "any later version" > clause. You can release your modifications in a way that allows this, but by contrast, you're not required to do so. You can take a GPL-licensed work with the "any later version" clause active, hack on it, and release your modifications without that clause. http://lists.debian.org/debian-legal/2004/08/msg00821.html > For that matter, the same thing is possible with the BSD license, > because it makes no attempt to provide copyleft protection. With BSD-licensed code, you're not required to grant permissions to your modifications that the license doesn't grant you in the first place, which is the issue Henning is concerned about. Would you consider a license free that said: If you use this software in another work, you must include the text "includes code written by Glenn Maynard" in supporting documentation. You must grant Glenn Maynard a license to distribute your modifications without a similar acknowledgement (a bare copyright and license notice must be sufficient). You're required to grant me permission to your modifications that he didn't grant us. This has come up in the past, under the argument that requiring this violates the "under the same terms as the license of the original software" provision of DFSG#3: you aren't allowed to distribute modifications under the same terms you received them, but instead must grant extra permissions. I'm not convinced it's a problem, and the argument doesn't work well in some cases--there are many licenses which give special treatment to the upstream author, which are generally considered very poor, obnoxious licenses, but not quite non-free. I do think it's worth thinking about, though. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Måns Rullgård <[EMAIL PROTECTED]> writes: > The Eclipse authors do not tell you which JVM to use. But Debian does, when it says: Depends: j2re1.4 | j2re1.3 | java2-runtime So the eclipse-platform distributed by Debian *does* call on a particular JVM. And it isn't kaffe, it's Sun's. We do document the technical fact that you can programatically substitute kaffe for any java-runtime. > It is compiled against an interface, not an implementation. Which > particular implementation was used while compiling is irrelevant. Can you support this assertion? The program, including its libraries, which the developer intends to put on end-user systems appears quite relevant to me. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Questions about legal theory behind (L)GPL
Scripsit "Michael K. Edwards" <[EMAIL PROTECTED]> > On Thu, 13 Jan 2005 07:46:18 -0500, Nathanael Nerode >> I guess I'm convinced. :-) > That the GPL is legally an offer of contract? If so, it's good to > know that the substance of my argument is persuasive to at least one > person besides myself. :-) I got lost somewhere along the way: Why is it important to you whether the GPL is a "contract" or not? You don't have to convince me - in my home jurisdiction it is beyond dispute that application of the GPL would be a matter for our contract law, and I won't aspire to claim anything about how it works in a common-law system. But the heat of the debate nevertheless leaves me wondering what it's for. Does it make any difference, and if so, what? -- Henning Makholm "Larry wants to replicate all the time ... ah, no, all I meant was that he likes to have a bang everywhere." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
