Re: [MPlayer-dev-eng] Re: help on libmpdemux usage (Modifié par Jérôme Cornet)

Jérôme Cornet jerome at aldorande.net
Wed Jan 14 16:39:26 CET 2004


Le 14 janv. 2004, à 11:47, The Wanderer a écrit :

>
> The difference between the situations is that one involves non-GPL code
> (QuickTime) linking in GPL code (libmpdemux), whereas the other 
> involves
> GPL code (MPlayer) linking in non-GPL code (the Win32 codec). I can
> easily see the potential for a legal difference between these 
> scenarios.

Le 14 janv. 2004, à 15:57, D Richard Felker III a écrit :

> Yes it does say this. You need to understand that the "derived work"
> is the entire program -- everything linked, including dynamically. If
> your derived work contains QuickTime (even if you are distributing
> that separately or telling users to get it from Apple) then you cannot
> cause the whole work to be licensed under the GPL, and thus you cannot
> distribute your derived work.
>
> Rich

So, i have read all users's replies about that topic. I have also read 
the part
of the FAQ, which was also very interesting. To me, the main problem is 
about the
definition of "linking", especially what you are linking to what and in 
my case what
is "linking".

After reading all the answers, i have to impression you cannot port any 
GPL program
to a non GPL OS. Let's take an example. I want to port Emacs to Windows 
but in order
to do that, I have to translate some X calls into Win32 API calls. So 
the final binary
"is linked" with some "OS libraries". So D Richard Felker says, "it 
explicitly makes an
exception for OS libs". OK. So I have the right to port Emacs to 
Windows, right?

Now, let's take QuickTime. I understand perfectly you hate that piece 
of software but that
is not the point. Do you have any informations on the way QuickTime's 
Components work?
A QuickTime component is some kind of a "plug-in". It provides some 
routines which are
called by QuickTime itself when opening a video file. Inside the 
component, some system
calls are done, the same way Emacs for Windows would do under Windows.
QuickTime is a system library. The only reason for a "QuickTime 
component" to need QuickTime
is the fact that it makes system calls, including system calls to 
QuickTime's library (part of the system).
My QuickTime components could be used by Mplayer itself, provided there 
is a version or an
emulation of the OS's libraries. Mplayer would just have to call the 
appropriate routine and provide
correct parameters to use the component to decompress video.

To summarize (sorry for my english), my "QuickTime component" is an 
independant file making
system calls the same way as any others software. You need QuickTime to 
build that file because
of those system calls (the same way you need a description of Windows' 
libraries to compile
Windows' version of Emacs). When the component file is present in the 
system, QuickTime makes call to it
in order to compress/decompress video the same way as a shell makee a 
call to the main() routine of an
executable when you invoke it.

Jérôme



More information about the MPlayer-dev-eng mailing list