Re: GPL v LGPL for libraries
> 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?
> > 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.
What is that you are against? Do you see the crucial difference beween
calling library function or calling executable via "system"?
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.
Thanks,
Alex Y.
--
_
_( )_
( (o___ +-------------------------------------------+
| _ 7 | Alexander Yukhimets |
\ (") | http://pages.nyu.edu/~aqy6633/ |
/ \ \ +-------------------------------------------+
Reply to: