[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use of GPL'd code with proprietary programs

From: Christopher C. Stacy
Subject: Re: Use of GPL'd code with proprietary programs
Date: Fri, 09 Jul 2004 23:28:52 GMT
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

>>>>> On Fri, 09 Jul 2004 23:15:49 +0200, Martin Dickopp ("Martin") writes:

 Martin> address@hidden (Christopher C. Stacy) writes:
 >>>>>>> On Fri, 09 Jul 2004 21:33:47 +0200, Martin Dickopp ("Martin") writes:
 Martin> address@hidden (Christopher C. Stacy) writes:
 >> >>>>>>> On Fri, 09 Jul 2004 21:04:01 +0200, Martin Dickopp ("Martin") 
 >> >>>>>>> writes:
 Martin> A memory dump of the running program could only be
 Martin> distributed if the license terms of both the executable
 Martin> and the library are followed.
 >> >> 
 >> >> But we're not making a memory dump and distributing it.
 Martin> I don't know what you mean by "we", but since making a memory dump is
 Martin> (or was; I'm not sure if it's still done this way) part of building GNU
 Martin> Emacs, there are indeed many entities which have made and distributed
 Martin> memory dumps.  In fact, I am one such entity.
 >> I thought we were talking about dynamic linking.

 Martin> I don't see how it makes a difference from a legal point of view if the
 Martin> dynamically loaded code is a compiled library or Lisp code, so I assume
 Martin> that this falls under the topic of dynamic linking.

 Martin> That said, I have indeed not fully understood what your point
 Martin> is.  I was explaining what I believe a court would and what I
 Martin> believe a court wouldn't consider a derivate work.  The fact
 Martin> that I believe a memory dump of a dynamically linked program
 Martin> would be considered a derivative work of both the program and
 Martin> the library is true irrespectively of whether that is
 Martin> actually done.

By "dynamically linked", I am referring to the scenario described
in my original message:  a non-GPL'd program begins executing and 
at that point requests that a library be called into memory.  
If the user happens to supply a library that is GPL'd, that does 
not somehow create any derivative work. It just means you have two
programs in memory at the same time, communicating with each other.

(Even if it did create a derivative work, the GPL says that the user
is free to do this.  But I am arguing that it does not create one.)

There is no "memory dump" involved there.  This scenario is what 
is generally meant by "dynamic linking", and is the only scenario 
that I was arguing about.

Perhaps you already agree with me about that.

Now you keep talking about "memory dump", and have mentioned Lisp.
In many Lisp implementations, one way to deliver an application
is to provide a kind of memory dump that includes both the main 
program and the libraries.  (By the way, this is not the only way 
to deliver a Lisp application.  For example, Lisp can do dynamic
linking as described in the above scenrio.  Emacs does that all
the time, where it's called "autoloading".)  The Lisp functions in
such a combined memory image might be called through the "dynamic
linking" mechanism that's part of how Lisp works.  But this is a
slightly different meaning of "dynamic linking" and is an entirely
different scenario than the one I described above.  In this Lisp
scenario, it is the act of the _distributor_ (not the _user_) of 
combining the non-GPL and GPL code into a single file for distribution.  
(In other words, this scenario is really the same as the "static linking"
delivery and distribution method used in other programming languages.
If statically linked images are derivative works, then such Lisp
programs probably are, too.)

A third scenario would be a Java JAR file.  In what way is 
this different than a TAR file, which is merely an aggregation?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]