Re: [Linphone-developers] G729 support in mediastremer2

[Sergei Steshenko]

--- On Mon, 8/2/10, Petr Pisar <address@hidden> wrote:

> From: Petr Pisar <address@hidden>
> Subject: Re: [Linphone-developers] G729 support in mediastremer2
> To: address@hidden
> Date: Monday, August 2, 2010, 12:11 AM
> 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
> 


So, do we agree on a practical scenario:

1) fake plugin with GPL source is distributed with the real GPL
application;

2) user on his/her premises replaces the fake plugin with the real non-GPL 
one and does _no_ (re)distribution of the combined

?

Technicalities ('dlopen', LD_PRELOAD, LD_LIBRARY_PATH, etc.) are not that
important. Even 'objcopy' and friends can be used to hack the binary
on user's premises.

Thanks,
  Sergei.