[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> cstacy@news.dtpq.com (Christopher C. Stacy) writes:
>>>>>>> On Fri, 09 Jul 2004 21:33:47 +0200, Martin Dickopp ("Martin") writes:
>>
Martin> cstacy@news.dtpq.com (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?
- Re: Use of GPL'd code with proprietary programs, (continued)
- Re: Use of GPL'd code with proprietary programs, Christopher C. Stacy, 2004/07/09
- Re: Use of GPL'd code with proprietary programs, Rui Miguel Seabra, 2004/07/09
- Re: Use of GPL'd code with proprietary programs, Martin Dickopp, 2004/07/09
- Re: Use of GPL'd code with proprietary programs, Christopher C. Stacy, 2004/07/09
- Re: Use of GPL'd code with proprietary programs, Martin Dickopp, 2004/07/09
- Re: Use of GPL'd code with proprietary programs, Christopher C. Stacy, 2004/07/09
- Re: Use of GPL'd code with proprietary programs, Martin Dickopp, 2004/07/09
- Re: Use of GPL'd code with proprietary programs,
Christopher C. Stacy <=
- Re: Use of GPL'd code with proprietary programs, Martin Dickopp, 2004/07/10
- Re: Use of GPL'd code with proprietary programs, Alexander Terekhov, 2004/07/10
- Re: Use of GPL'd code with proprietary programs, Rui Miguel Seabra, 2004/07/10
- Message not available
- Re: Use of GPL'd code with proprietary programs, Alexander Terekhov, 2004/07/10
- Re: Use of GPL'd code with proprietary programs, Rui Miguel Seabra, 2004/07/10
- Message not available
- Re: Use of GPL'd code with proprietary programs, Alexander Terekhov, 2004/07/10
- Re: Use of GPL'd code with proprietary programs, Rui Miguel Seabra, 2004/07/10
- Message not available
- Re: Use of GPL'd code with proprietary programs, Alexander Terekhov, 2004/07/10
- Re: Use of GPL'd code with proprietary programs, Rui Miguel Seabra, 2004/07/10
- Message not available
- Re: Use of GPL'd code with proprietary programs, Alexander Terekhov, 2004/07/10