[sldev] Proprietary dependencies

Argent Stonecutter secret.argent at gmail.com
Sat Jan 26 11:27:33 PST 2008


On 2008-01-26, at 08:43, Dzonatas wrote:
> We've heard the issue saying that it makes installation easier, but  
> that is all that is being said. If the installation scripts and  
> procedure were made to handle dynamic libraries, the issue of there  
> being a proprietary or open-source library attached become really a  
> non-issue as long as they are dynamically linked.

The GPL 2 doesn't work that way. The GNU MP library was shipped as a  
shared library, it still made the final work a derivative work under  
the GPL. Korn had to change the way he was building GCC for the same  
reason. It doesn't matter whether the libraries are linked in to the  
same executable or shipped as shared libraries.

> Further, the client code could change separate out its features  
> into different processes or tasks. Surely there is no need to keep  
> every piece of the entire client to run in synchronous fashion  
> under a single CPU.

Fifteen years ago I'd agree with you, but threads and lightweight  
processes do as good a job of that. And whether it's shared libraries  
or statically linked doesn't change that.

On the other hand, pulling components out to separate executable  
talking through some IPC mechanism does provide a GPL cutout.




More information about the SLDev mailing list