Re: GPL v LGPL for libraries
On Tue, 15 Dec 1998 aqy6633@acf5.nyu.edu wrote:
> > Not at all. Your "script" is parsed by bash, but not part of the
> > executable that has a process ID. When you link with a library, the
> > executable in memory contains both your code and code from the library.
> > The program "uses" them because it "owns" the data elements that those
> > routines opperate upon, but the "linked" routine is the only way to
> > manipulate those data elements. The program would fail if the shared
> > library were simply a shared block of memory containing the code which
> > could be executed by any program in memory.
>
> Isn't this really the case for shared libraries??? Yes, those routines would
> use heap and stack of the calling process, but so what?
NO! It isn't the case with libraries. There is executable code in the
library that the linker (at your request, by the external references you
placed there) actually copies into your program space so that your program
can execute it. The code that is executed by bash, when it parses the
meaning from your shell script, is only the code that the loader put there
(including any shared libraries) at link time. Your script is never used
to create an "executable" binary component.
>
> > > or the same way I use the code of others when I do
> > > system("/usr/bin/a2ps -X .....");
> >
> > Seriously? Are all your personal internal algorithms covered under the
> > GPL? Even then I'm not sure there would be a license problem, as you are
> > the individual spoken to by the license, not code whose interaction is
> > regulated by the license.
>
> Dale, I am sure there is a point here somewhere. I just don't see it.
The license gives you permission to execute the code. Whether you use the
system comand to do so, or some other feater of the system is not
relevant.
> What is that you are against? Do you see the crucial difference beween
> calling library function or calling executable via "system"?
I am against the idea that lining is not "using".
> I am sorry, but whether the process has the same PID or different is
> implementation dependent. I can easily imagine "system()" that doesn't use
> fork(). I can also write a program that will not be linked with a library on a
> compilation stage, but open a library file ar run time with dlopen() and
> resolve all the symbols on startup.
Please don't hide behind words like resolve as a euphamism for "include".
When you "resolve" a symbol, you do so by copying a piece of code from the
library into the executable image and pointing the "reference" tags for
that symbol to the included routine. The fact that this happens at run
time, instead of at compile time, doesn't change the fact that these
routines are being "used" by your code. Such inclusion requires the
copyright to be GPL if the library is GPL. The LGPL doesn't have these
problems for free software or proprietary software. Just because it allows
for proprietary linking doesn't mean that it is less free. For me it is
more free, as it lets more software execute not less. I also feel that
such software, by competing in a free environment, will be encouraged to
become more free as well. I give, as an example, Netscape. If libc6 were
not under the LGPL, then Netscape could never have run on a Linux machine,
and would never have gotten the opportunity to become more free.
Luck,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Reply to: