Re: [Linphone-developers] G729 support in mediastremer2

[Petr Pisar]

On Sun, Aug 01, 2010 at 06:35:22PM -0700, Sergei Steshenko wrote:
> 
> --- On Sun, 8/1/10, Petr Pisar <address@hidden> wrote:
> 
> > From: Petr Pisar <address@hidden>
> > Subject: Re: [Linphone-developers] G729 support in mediastremer2
> > To: address@hidden
> > Date: Sunday, August 1, 2010, 10:59 AM
> > On Sun, Aug 01, 2010 at 12:26:31AM
> > -0700, Sergei Steshenko wrote:
> > > 
> > > --- On Sat, 7/31/10, Mike Frysinger <address@hidden>
> > wrote:
> > > 
> > > Which issue ?
> > > 
> > > For example, on my SUSE new ATI closed source drivers are compiled with
> > > the kernel on my machine when I download the RPM.
> > > 
> > Do you talk about commercial SUSE or non-commercal OpenSUSE? Does the
> > package come from official repository, or is it a third party repository
> > hosted by someone somewhere outside of U.S.A. and west or central Europe?
> > (I just ask to check the repository).
> > 
> > Nevertheless, fact somebody violates license does not excuse others to do
> > so.
> > 
> > The issue is very simple: GPL (let's talk about version 2) states
> > recipient must get software under GPL terms (including linked objects) and
> > must be able to obtain source under the same terms.
> > 
> 
> I am talking about open SUSE. I am talking about AMD/ATI repository.
> 
If you talk about <http://www2.ati.com/suse/11.2/> repository, I cannot get
the content to check it as I cannot get a binary RPM from there (I have no
SUSE installed and I don't know SUSE repository protocol).

However if the RPM compiles the code at installation time, as somebody said
in other thread, then this is exactly the source only distribution method
I described formerly, and there is no problem.

> There is no GPL violation. ABSOLUTELY.
> 
> For example, suppose a GPL program is linked _dynamically_ to a function
> whose prototype is:
> 
GPL does not distinguish between dynamic and static linking. This is subject
of difference between GPL and LGPL.

Maybe you talk about indirect manual call, when calling executable is not
linked to called object at all (e.g., dlopen). This is a way how plugins
are usually implemented. And yes, this way allows to call non-GPL functions
from GPL binary. More ever it allows to create redistributable binaries (see
below).

However this is not a case of ATI drivers as the indirect call has serious
perfomance penalty and is not suitable for high pressured data path which
modern graphics accelerators require (in addition, the drivers are kernel
drivers and Linux does not support something like dlopen).

> void some_function(double *in, double *out, int n);
> 
> and the source of the function is available under GPL or GPL-compatible
> license.
> 
If the source of the function is under GPL-compatible license, then there is
no problem.

> GPL does _not_ mandate the function to do anything useful, in fact, it
> does not even mandate the function (or the whole program) to work.
> 
Talking about GPLv2. GPLv3 has much stronger requirements, like the resulting
binary must be equivalent to the original binary in provided functionality and
usability.

> Now, at home or at work I decide to replace the some_function DLL with
> another DLL. And I do _not_ distribute the new combination.
> 
> There is _no_ GPL violation.
> 
I thought we talked about redistribution and why ATI drivers are not this
case.

> So, the above 'some_function' there can be a function which happens to
> be named as some function from G729 codec (and GPL does _not_ impose
> limitations on function names), and instead of
> 
> "(double *in, double *out, int n);"
> 
> function signature there can be a function signature which happens to be
> the one of the above G729 codec function.
> 
Yes, this is a way how it works. You have propietary blob with known
interface. You write a BSD wrapper that encapsulates the blob and maps GPL
application plugin API to the blob API. Then you dlopen the wrapper from GPL
library and call the wrapper functions.

As GPL does not consider header files inclusion as code derivation, an non-GPL
source can include GPL headers without violation. This allows the BSD wrapper
to include headers from GPL application to provide plugin API.

The wrapper step is optinional but very usefull because plugin API application
defines is usually different from the blob's one.

-- Petr

pgpIopjpO6zzk.pgp
Description: PGP signature