[sldev] Proprietary dependencies

Dzonatas dzonatas at dzonux.net
Sat Jan 26 13:29:58 PST 2008


Argent Stonecutter wrote:
> 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.

This is the same old argument we have spoke about many time before, and 
even post the unofficial wiki page about it. What I'm saying here is 
people should have a choice to which modules goes with the client -- 
don't have it static built. We make an API for it, and agree on it.

If fact, I believe there has been some work on it with LLMedia; for 
example, but that change is being done internally.

>
>> 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.
>

Yes.

There is nothing stopping you or anyone to plug their TV into their VCR 
or amplifier of choice, and that is what I'm saying here.  That choice 
does not violate the GPL.



More information about the SLDev mailing list