[sldev] Proprietary dependencies

[Argent Stonecutter]

On 2008-01-26, at 15:29, Dzonatas wrote:
> 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,

I'm not sure I understand what you're getting at here, which old  
argument? Just switching to dynamic linking and loading for fmod  
wouldn't make a difference, and quicktime is already dynamically  
loaded but it also makes it a GPL violation to link to it from SL on  
Windows (it's OK on OS X because it's shipped with the OS).

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

That only works where there's a fully open source implementation of  
the code on the other side of the API that satisfies the FOSS  
exception. Not a stub, something you can actually use, like the BSD  
MP library or BSD editline. Where there is, this is already a non- 
issue, because you can build with the open source version. If there  
was, the open source version could just use that and it wouldn't be a  
dependency.