[sldev] Proprietary dependencies

[Lawson English]

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

That last is where the whole thing gets silly (if it isn't already). 
What it means is that it is OK to ship a product that won't work 
properly (if at all) on a specific system unless it violates a license, 
and if a person happens to have QuickTime already installed (as many 
do), the fact Second Life is working properly means that he person has 
unknowingly violated a license.

>
>> 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.
>
I think the guiding light there is the fact that Linden Labs, which 
holds the license in the first place, is already in violation of their 
own license (according to you), so it would be hard for them to 
prosecute others for doing what they already do because they DO ship the 
SL client expecting WIndows users to have it available.


Lawson