[sldev] Proprietary dependencies

[Dzonatas]

>> 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...
The point is to not ship fmod or any other open-source package with the 
client. It wasn't about a replacement library of any sort.

As for the license bit, "same old argument" meaning its been on SLDev 
here many times and there is an unofficial faq on the wiki.  My point 
was not to start another license debate.


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

Just give the option to ship the dang client barebones without any 
proprietary piece to it. In order for that to work, there has to be 
APIs.  The multi-process client would be an example, just the core.

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

The GPL has nothing written in it to allow or not allow such linkage. 
Certainly, the GPL doesn't say "hey.. you can't take out that library 
because it would be a violation!"

I think under some people's understanding of the GPL they might as well 
throw away the memory in their computer because how it tightly works 
with free software instead of risk a GPL violation.

How a message is sent through an ABI, API, or even over the Internet is 
all the same in the eyes of the GPL.  The compile-time linkage or 
run-time linkage is not the determining factor under the GPL. It could 
be perfectly fine to link a proprietary library with a GPL program of 
vice-versa if both of those packages are separate works. That means that 
when one calls upon the other to do work that their context is not being 
shared. They may share content all they want. The Internet would come to 
a sudden legal and traumatic halt if GPL'd software couldn't share 
content with proprietary software. OK... non-issue.

The dependencies here are being shipped with the client. The option not 
available is to get an LL official build of the client without those 
dependencies.  A client that promotes being able to jack-in your own 
sound system jut like one can plug their own DVD player onto their 
entertainment system. Shipping the dependencies with the offical LL 
build is like DVD players shipping DRM technology that only let you play 
your movie on certain branded screens.


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

Right, the GPL and many licenses are bound by OSI to be technology 
neutral. There should be no DRM or force any preference to any 
proprietary library!!!

http://www.opensource.org/docs/definition.php #10

Look at Mozilla, it is open-source. You can buy proprietary add-ons to 
it. There is no violation there, and they have API linkage.