[sldev] Proprietary dependencies

[Argent Stonecutter]

On 2008-01-26, at 18:58, Dzonatas wrote:
> The act to link against the shared library is not an absolute  
> factor to determine if a derived work exists.

According to the FSF it is. If Linden Labs doesn't agree, then it's  
up to Linden Labs to say so. They haven't said so.

>>> The compile-time linkage or run-time linkage is not the  
>>> determining factor under the GPL.
>>

>> I believe I made that point already.
>

> Your point is not clear because it appears here you agree that a  
> link with a shared library does not always denote a derived work is  
> being made, but...

No, my point is that it doesn't matter whether it's compile or run  
time linkage, because unless you're using a shared library technology  
out of the '80s that uses an explicit manually created jump table you  
still have to link with a shared library *at compile time* to create  
the symbol table to load and link *at run time*.

That's what makes it a derived work.

That doesn't mean that you can't craft a cutout for the GPL. People  
do it all the time. IPC, network communications, shared files and  
memory. At one point the GPL3 drafts had explicit sections to cover  
remote use of web services, because the GPL didn't do the job, and  
people went nuts, and the FSF backed down... so even teh FSF agrees  
that cutouts can be made.

But just switching from static to shared libraries doesn't do that.  
And that's the point I'm making.

> As long as they don't share execution context then they can be  
> linked and still be considered separate works. The GPL, however,  
> does not set an absolute, or cookie-cuter case, for kinds of  
> contexts and how they can or can not work with other contexts. It  
> provides a guideline and uses a 'take-it-to-court' explanation for  
> all other diversions.

And when the FSF said "we'll take it to court" for *this specific  
case* the lawyers and techs on the other side said "we'd probably  
lose" and settled. Linus Torvalds, on the other hand, has made it  
clear that HE doesn't consider kernel modules automatically invoking  
the GPL, depending on what APIs they use. The bottom line is it comes  
down to what the copyright holder decides to allow.

Linden Labs has not said what their position is.

I am calling on them to do so.

> What if one doesn't include Quicktime headers at all.

You're still linking against the library.

If you change it so that the Quicktime API is sufficiently tenuous,  
then you can say "OK, we have a cutout". But that's not what we have  
*right now*, and it's not what you'd get for FMOD and anything else  
they use if they just made them shared libraries. There's a lot of  
work that would have to be done to create those cutouts.

And Linden Labs would have to buy into it, otherwise it wouldn't get  
into the SL client.

Linden Labs, again, has not said what their position is.

They could do this, sure. They could also extend the FOSS exception  
to include Quicktime, which would have the same result, and for a lot  
less effort.

But, again, they would have to actually do it. Either way.

> I think you got the gist of this and understand it but wasn't sure  
> about my point or even question if I understood my own gist. lol

My point is that no matter what design you're talking about, it's up  
to Linden Labs to actually make it happen.

And they could accomplish the same thing, with less effort and less  
likelihood of someone figuring out a way to shove something they  
don't want on the other side of the GPL cutout, by explicitly  
including *just* the components SL depends on in their GPL exception.

Eg:

"Linking with the following libraries:
* Quicktime
* XYZs Quicktime CODEC for FLAC
* ABCs Quicktime CODEC for WMA
* Adobe FLV Codec
..."

But, again, they haven't indicated that this is something they want  
to see happen. They haven't even explicitly stated their position on  
the much simpler question of what they consider a derived work to  
consist of. And that is what this is all about.