[MPlayer-dev-eng] PATCH dynamic link loader for libaf, audio filter package

[Ivan Kalvachev]

2007/6/16, Marc Hoffman <mmhoffm at gmail.com>:
> Hi,
>
> On 6/15/07, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> >
> > On Fri, 2007-06-15 at 07:49 -0400, Marc Hoffman wrote:
> > > On 6/15/07, Reimar Doeffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>
> > > wrote:
> > > > Why would someone want this though?
> > >
> > >
> > > 1. I need to link at runtime a  module which  can't be integrated with
> > the
> > > code itself directly due to proprietary IP issues.  As long as Mike and
> > the
> > > rest of the crew don't get a hold of the so's.
> >
> > This sounds basically like an attempt to circumvent the GPL. Whether or
> > not it would actually be legal it might not be something we want to
> > encourage.
>
>
> Not completely, this is for some internal tools which someone plans to use
> as part of their service infrastructure.   So the software doesn't not get
> distributed as far a I know at least the software is not sold but the
> service is.  I think this is ok.
>
> > 2. The functionality which I have been asked to add to mplayer is a bit
> > > esoteric and specific to SMPTE time codes.  And I have been asked to
> > make my
> > > work private.
> >
> > This also sounds potentially questionable. You can agree to develop
> > GPLed code and not distribute the result without permission, but any
> > distribution that does happen must be under the terms of the GPL. Does
> > whatever party you're working for intend to keep the result for private
> > use? Anyone else but you who receives it gets it under the terms of the
> > GPL (and even you if you get it back from someone else), and cannot be
> > asked to keep it private.
>
>
>
> Private use, I believe.   Actually, I have been going around and around on
> the issue of to integrate or not integrate.  And to mainline the code to
> reduce long term maintenance costs but the group doesn't want to disclose
> the technology at the current time.
>
> > Well I don't want to patch the player thats too complex to do for
> > ever.  So
> > > I was thinking that this would be a good mechanism to tie the things
> > > together for a very long time and minimizing costs etc.
> >
> > I think we do not want to make any kind of API or ABI stability
> > guarantees for the audio filters. Thus if there is a module interface it
> > should have some kind of version information to detect incompatible
> > modules; but so far I'm not convinced there should be a module interface
> > at all.
>
>
>
> I agree there are no Guarantees here at all the internal data structure
> layouts change and these modules will cease to work.  I know the issue all
> to well.
>
>
> Putting the political issues aside will the group accept my patch?  I also
> think its fairly useful in that it does in someways simplify filter
> development.  Where you can just work on your filter and link it into the
> big system.

Can you explain what your filter does, that cannot be done if it is
reworked as ladspa filter?

As political matter, if you don't distribute mplayer then you can put
any kind of private code in it, meaning you don't even need the binary
modules.

I'm also against creation of common interface just to circumvent GPL,
we already support one.