Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Fri, Jan 14, 2005 at 05:57:54PM +0100, Dalibor Topic wrote: > Now, before you go off ranting about Kaffe's native libraries, please > take a moment to let the fact sink in that while these native libraries > are the result of Kaffe developers being a somewhat clever bunch at > developing software and having heard about benefits of seperating one's > program into sepearte modules, those modules are nevertheless *a part of > the interpreter*, and as the copyright law law says, the GPLd > interpreter can't impose restrictions on its input. They even get > compiled in statically on Debian for debian's kaffe package. This part is overstated. As components of the interpreter, they don't impose restrictions on programs run by the interpreter. However, this does not exempt those programs from any other relations to this code. Programs which run on the interpreter may or may not be derivatives of the native libraries (for any given library and program, they probably aren't, but it is possible for programs to exist which are derivatives of some given native library). If they are, then the GPL crosses that connection independently. The fact that it's part of the interpreter just isn't relevant. Given that eclipse runs on other JVMs, I'm inclined to expect that it isn't a derivative of any of them, but I really have no idea. That's the only question here which matters though. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Illustrating JVM bindings
On Fri, Jan 14, 2005 at 04:42:44PM -0500, Brian Thomas Sniffen wrote: > > An example. I am writing an app. A GPL-incompatible or even > > closed-source one. I'd love to use this conservative garbage collector > > library, but it's under GPL, so I cannot. I'd also love to use > > libreadline, but I can't - for it's GPL. > > > > According to what you've just said it would be enough to create own > > intermediate langauge, and an interpreter that according to its own > > specification should handle garbage collection and provide readline-like > > functionality. > > > > I would then just take the GPLed code of this GC library, GPLed code > > of readline, cut out the pieces I need, integrate into my interepreter > > and call it "interepter features". Thus, according to you, my > > GPL-incompatible program would be able to use GPLed code thanks to > > the simple virtue of my program being "interepted". > > Yes. Well, you have to distribute the interpreter for this new > language of yours under the GPL. So the GPL isn't useless. And > your proprietary program then must use the interpreter. > > But, for example, I *have* such an interpreter -- for the language > Python. I have many non-GPL'd scripts for it, even though the Python > I use incorporates GNU Readline. Bwah, you're all *still* doing it! Some of those python scripts may be derivatives of GNU readline. Most are probably not. Those that are must be licensed under the GPL. The rest do not have to be. All this interpreter crud in between is *irrelevant*. If the same program written in C would be a derivative then it's still a derivative even when you insert an interpreter in the middle. -- .''`. ** 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 08:02:57PM +0100, M?ns Rullg?rd wrote: > > Derivation is something that happens when you *write* the program. Not > > when you build it. > > How many times does it have to be stated that *using* an API does not > form a derivative work of *any* implementation of the API? More irrelevancy. Using an API is just a method for utilising part of another work. It may or may not be a derivative. This is just a variation on the 'linker' noise. -- .''`. ** 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:11:22PM +0100, M?ns Rullg?rd wrote: > Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > > > 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. > > > > 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. > > Wrong. A dynamically linked program in ELF format (the most common on > Linux systems) contains a list of undefined symbols, and a list of > sonames to search for those symbols. I have a hard time seeing how > this would make a program derived from the library. If multiple > independent implementations of the library exist, which would the > program be derived from? You've got the causality backwards here. The program is linked to the libraries because it is a derivative of the libraries. Not the other way around. Derivation is something that happens when you *write* the program. Not when you build it. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Kaffe's GPL and GPL incompatible Java software [Was: Undistributable java in main]
[This is no longer particularly important] On Mon, Nov 03, 2003 at 09:37:49AM -0500, Etienne Gagnon wrote: > Andrew Suffield wrote: > >Kaffe is essentially a filter that takes java > >bytecode as input and emits program code on the fly (this is > >technically incomplete, but effectively equivalent for the sake of > >this argument). The input to a filter cannot be a derivative work of > >it; we don't *care* about the state of the output (which is also not a > >derivative work in this case, but I'll skip the reasoning). > > I can live with this view (even though an argument could be made about > the fact that many VMs (I do not know specifically about Kaffe) internally > use bytecodes from the class library to handle internal data structures > [think of a just-in-time compiler written in Java; it would really be > part of the VM, not merely processed input, IMHO]). I considered this briefly, but the result of any such process is never copied or distributed[0], so copyright isn't directly applicable at all - we don't need to worry about it. The GPL doesn't place any restrictions on how you use works it covers, only on how you distribute them, so there's no possibility of trouble from that side. Freakish maybe-invalid licenses that try to place restrictions on use may have trouble here, but those aren't a concern as far as GPL compatibility is concerned; the worst case is that you have some non-distributable data in memory, where nothing will try to distribute it. We'll probably judge them to be non-DFSG-free in their own right, but that's an entirely separate issue. [0] Who wants to speculate on the legal status of core dumps? I don't think we can really do anything useful here, since it's all mixed up with the input fed to the process at runtime, but it might make an interesting diversion. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Kaffe's GPL and GPL incompatible Java software [Was: Undistributable java in main]
king on proprietary systems; the FSF could justifiably shift to the GPL if they wished. As always, this would restrict the range of things that you could do with it; it is the choice of the copyright holder how much to permit. Also, C programs directly include copyrightable program code from header files, which means that compiled binaries are frequently derivative works of the "library" (if glibc were GPLed, this would prohibit distribution of binaries generated from GPL-incompatible sources, as the GPL license on the glibc components would not permit this; it would be okay if the headers alone were licensed under the LGPL). Java has no comparable issue; a byte-compiled class contains nothing copyrightable taken from the class libraries that it was "compiled" against. [0] DERIVATIVE WORK - A work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a 'derivative work'. -- from title 17 of the United States Code. Other jurisdictions are very similar. [1] I'm skipping the rationale for this; it's just a list of all the things involved in the creation of the work under discussion, and classification of whether or not their use can constitute copyright infringement. Implementation of a specification does not usually constitute copyright infringement of the specification, for example, because there's no copying/distribution involved. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
