Re: GPL, yet again. (The kernel is a lot like a shared library)
> The difference is that when you talk about dynamic linking, the
> 'replacement' means fiddling with linker options or package
> dependencies. It is indeed nonsense to conclude that doing these
> things would change the copyright status of the program using the
> libraries.
in the case of dynamic linking, IMHO, 'replacement' means:
cd /usr/lib
rm libopenssl.so
ln -sf libnovossl.so libopenssl.so
This did not change programX; next time programX is loaded, it will
execute with libnovossl instead of libopenssl. I can't see how can
programX possibly be a derivative work of libopenssl or of libnvossl.
Can you please explain it to me, like if I was a four-year-old? I am
asking politely.
> Your entire argument is based on the fact that it's nonsense for
> dynamic linking because replacing one external run-time library with
> another shouldn't change the copyright status of the program using
> it. Yes, it's nonsense - but you're the one who introduced it. The
> introduction of dynamic linking was the mistaken assumption.
Why is the introduction of dynamic linking the mistaken assumption?
Almost every program vs. lib relationship in Debian is via dynamic
linking. What is really on the table here is: Debian distributes
programX.deb (containing /usr/bin/programX), openssl.deb (containing
/usr/lib/libopenssl.so.X.Y), and novossl.deb (containing
/usr/lib/libnovossl.so.X.Y). [programX = GPL, novossl = GPL]
I want to know exactly why and how the GPL forbids the postinst
script for any of the libraries of setting up the /usr/lib/libssl.so
symlink pointing to its own library. If someone gives me a nice,
logically sound argument, I'll shut up.
--
Massa
Reply to: