On 1/2/06, <b class="gmail_sendername">Aigars Mahinovs</b> &lt;<a href="mailto:aigarius@debian.org">aigarius@debian.org</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 ... however the binary is only distributed<br>under a non-free licence that does not allow redistribution or<br>modification. ... </blockquote><div><br>
So there are two (unrelated) issues then.&nbsp; (1) The binary license
does not allow redistribution or modification, and (2) The
GPL/LGPL/binary link issue under section 7.<br>
&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So, if you try to use the binary non-free plugin, Rythmbox combines<br>with Gstreamer in a memory of the computer forming a GPL derrivative
<br>work and then there is an open question whether the user can link a<br>non-free plugin into that GPL work. Basically it is the question<br>whether a LGPL glue library can protect a non-free program from GPL<br>&quot;contamination&quot;. I do not think so - that would have been a huge legal
<br>backdoor around GPL copyleft protection.</blockquote><div><br>
I agree that that is the question.&nbsp; But I don't see how it is a
backdoor for behavior that would violate the spirit of the GPL
regarding the GPLed program.&nbsp; Shipping Rhythmbox, Gstreamer, and
Fluendo-MP3, that is.<br>
<br>
The only potentially problematic scenario I can see would be the
reverse: a NonFreePlayer, LGPL glue, and a GPLedPlugin.&nbsp; In that
case, it could be argued that the LGPL glue permits NonFreePlayer to
effectively function as a derivative work of GPLedPlugin while
remaining non-free.&nbsp; But even then, it's pretty
order-dependant.&nbsp; GPLedPlugin does not function on its own;
NonFreePlayer is built on top of it.&nbsp; This is the opposite.&nbsp;
This is &quot;can you build a GPLed program as a derivative of a non-free
component&quot; by passing messages through a wall?<br>
</div><br>
It sounds like if you can build an application that way, you have kept
your hands clean.&nbsp; How are the intent or the effects different
from a GPLed app talking to a non-free app over a network socket?&nbsp;
That's allowed.<br>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I can only say that I agree to what has been written in this blog:<br><a href="http://thomas.apestaart.org/log/index.php?p=333">
http://thomas.apestaart.org/log/index.php?p=333</a><br><br>IANAL, but I can't seam to find any objections to that.</blockquote><div><br>
<br>
&nbsp;Well, those statements are fine and all, but they're not legally
binding.&nbsp; If you're convinced by them, okay, but I will not be
satisfied until I see proof.<br>
</div><br>
Are there no precedents for this scenario?&nbsp;  None?&nbsp; It doesn't seem like it should be that exotic.<br>
<br>
Thanks,<br>
Nate<br>
</div>-- <br>nathan.p.willis<br><a href="mailto:nwillis@glyphography.com">nwillis@glyphography.com</a><br>
<a href="http://flickr.com/photos/willis">flickr.com/photos/willis</a><br>