[impdev] LLKDU

Aleric Inglewood aleric.inglewood at gmail.com
Mon Sep 20 06:18:11 PDT 2010


Hi all,

I'm sure that it is not a GPL violation. The GPL deals with
distribution, not linking.
Imprudence distributes a working binary that is not linked with non-GPL code.
As such it is perfectly allowed to (optionally) load a proprietary library, if
the user so wishes.

I'm inclined to say: get LL to understand that and offer them the "solution" to
make it really a user choice (even if the library can be found).

Moreover, imprudence should definitely load llkdu when it can find it, when
connecting to opensim-- shouldn't it?

Before LL starts to be honest about the real reason they desire to ban viewers
that can load the library, I don't think we should hasten to bow to
their demands.

I think the TPV's aren't organized enough: We need an organization for ALL
TPV's to discuss matters like this, and coordinate it, so everyone does the
same thing.

For now, I'd say: just release it with kdu support.

On Sat, Sep 18, 2010 at 6:46 AM, Jacek Antonelli
<jacek.antonelli at gmail.com> wrote:
> Earlier today, McCabe and I attended a meeting with Oz Linden and
> several other viewer developers, regarding some policy issues
> affecting third party viewers. The most significant issue is that LL
> considers it to be a GPL violation to use LLKDU or any other
> proprietary library with the open-source GPL code. And, therefore, we
> are supposed to remove Imprudence's ability to use LLKDU even when the
> user has copied it from a SL installation.
>
> I disagree with LL that this is a GPL violation. We do not include or
> distribute any proprietary KDU code in the viewer, not even
> proprietary header files. (LLKDU is loaded as a "dynamic shared
> object", not linked or compiled into the viewer like libraries usually
> are.) Plus, the viewer is fully functional (but slower and less
> stable) even if LLKDU is not present.
>
> However, it's obvious that we will need to get rid of LLKDU support
> sometime. For one thing, LL will eventually hit us with a hammer if we
> don't do it. Also, my impression is that LL made a big licensing
> mistake by distributing LLKDU as a dynamic library, and are now trying
> to fix the situation so that the KDU creators don't swing the hammer
> at them. If that's true, then LLKDU is not really "legitimate", so
> using it (or encouraging our users to use it) is legally questionable.
> Besides, I don't like to take unfair advantage of someone's mistake,
> for both moral reasons, and practical (hammer-avoiding) reasons.
>
> I have pushed a commit to my repository ("nokdu" branch) that I think
> completely removes the viewer's ability to load LLKDU. I've tested it
> on Linux32 and Mac so far, and it seems to work. Some day, it will go
> into the main code -- but the question is _when_.
>
> Tomorrow is Saturday, when we usually release a new Experimental.
> Additionally, 1.3 RC3 is 99.9% done, and I'd like to release it very
> soon, too. So, the question is whether we should cripple these two
> versions by disabling KDU, or not. If we do cripple them, it will
> cause serious problems for many users. If we don't cripple them, LL
> might get a bit annoyed at us, but I don't think they'd do anything
> yet.
>
> Weighing the two options, it seems clear to me that _not_ crippling
> these versions is more practical. But, I want to hear your guys'
> opinions (other team members and anyone else who cares to speak up)
> before we make a final decision about it. What say you?
>
> - Jacek
> _______________________________________________
> ImpDev mailing list
> ImpDev at lists.imprudenceviewer.org
> http://lists.imprudenceviewer.org/listinfo.cgi/impdev-imprudenceviewer.org
>



More information about the ImpDev mailing list