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