[Ffmpeg-devel] Patch for dynamic liba52.so loading

[François Revol]

> Rich Felker <dalias at aerifal.cx> writes:
> 
> >> > Of course there are multiple codec contexts. Is there a good 
> > > > reason
> >> > for dynamic loading support? IMO it's unnecessary complexity 
> > > > that
> >> > should just be removed..
> >> 
> >> There is no technical reason for dynamic loading.  It allows
> >> libavcodec to be distributed under the LGPL, and still use liba52,
> >> even if you believe the lies being perpetrated by the FSF.
> >
> > As long as the party setting it up for this use is not also
> > distributing liba52 or outerwise doing something for it that 
> > requires
> > accepting the GPL on liba52 I agree. On the other hand, if someone
> > makes a proprietary program that needs to decode ac3, and 
> > distributes
> > it with libavcodec compiled for dynamic liba52 loading, then offers 
> > a
> > separate download of liba52 under GPL terms, they ARE infringing on
> > liba52. Making them separate downloads or separating them in other
> > ways does not get around the fact that they have prepared a non-GPL
> > derivative work of liba52, thus invalidating their rights to
> > distribute liba52 under the GPL.
> 
> The point is that linking against liba52 (or any other library) does
> not create a derived work.  There is a fair amount of evidence that
> making use of a library through its API, does not amount to creating 
> a
> derived work.  The bits from the library that end up in the 
> executable
> linking to it (names of functions, mainly), are not subject to
> copyright protection.  This is analogous to writing an article, in
> which references to various books are made.  This does in no way
> infringe on the copyright of the books referenced.
> 
> If APIs were protected by copyright, then creating a compatible
> implementation would also be creating a derived work, and would
> require proper permission from the copyright holder.  Creating a
> compatible implementation is precisely what the FSF has done in the
> case of the OpenSSL compatibility layer of GnuTLS.  If the FSF
> requires users of the APIs of their libraries to allow the GPL to
> extend the using application, then how can they consider themselves
> having the right to duplicate the interfaces of others?

Now that's an interesting pov on the GPL :)
I always wondered if it applied at all to header files...
which define APIs.

Like, I made a tuntap driver for BeOS that is compatible with the Linux 
API.
I had to make a header file of course,  that ended up being quite the 
same (of course as it's the same API) as the Linux one. Except the 
Linux header is "covered by the GNU General Public Licence ...". Why 
would I be forced to put my driver under GPL while I never even read 
the code of the Linux one ?

Fran?ois.