[XviD-devel] xvid license

[Christoph Lampert]

On 22 Apr 2003, Christian Fredrik Kalager Schaller wrote:

> Ok, first of all I don't want to spam you guys with this, so this is my
> last post to your list, appoligize to those who are already annoyed with
> my nagging :)

No, that's okay. I guess many people (possibly also on this list) don't
know exactly what GPL and LGPL is about etc., but don't dare to ask. 
So GStreamer/XVID is a good example for demonstration. 

 
> Well the issue I see is that Red Hat ships with GStreamer including the xvid
> plugin. Someone makes a video encoding application using a non-GPL compatible 
> license (doesn't need to be properietary, could be using the MPL for instance) 
> that is using the GStreamer framework to provide its encoding capabilities.
> 
> Red Hat decides to also bundle this application (because it is still
> free software, just not GPL compatible) which means a application
> incompatible with the GPL is shipping in a package (Red Hat Linux)
> together with the xvid plugin and the rest of  GStreamer. 
> 
> Question then is if a license violation occurs, and if so who is to
> blame. The application developer for not making sure his application do
> not call the xvid plugin, or us for not making sure the application is
> not able to call the xvid plugin or Red Hat for shipping the two
> together or the user who use the two together.

Okay, good example. I think the key word which appears most often in these
discussions is "derived works". You are not allowed to
distribute(!) derived works from GPLed code unless the application is GPL
itself. Unfortunately, GPL itself is not that clear in what way the
calling of plugins is creation of derived works, but I myself come to the
conclusion, that putting two programs side by side (on a webpage for
download, or on a CD or something) isn't. That just distribution of two
individual components, one under GPL (which grants the right of
redistribution), one under another license. No problem, even if one of the
apps can call the other or anything. It's the user's choice to download
both and combine them. 
But, if there was only 1 download link, with a common archive, and in
particular a common _installer_ (this include e.g. a common sourcetree
with one Makefile to compile all), that I would consider "derived works",
because it became one entity (from the user's eyes). 
I don't know if this is an official position, but again I find it the only
one that makes sense. 

So: If you created a single source tree with GStreamer and XVID, I would
say, it would be you who violated the license. I know that there are
projects where LGPLed and GPLed code parts are present, but strictly
speaking, I think that's not allowed (unless the whole is decleared GPL).

If RedHat modified your sources to make this connection instead of
separate archives, it would be them. If they just put on one disk what was
available, that's mere aggregation, no violation.  If the application
programmer included GSTreamer as shared or static library into his
programs, and XVID, too, he would of course violate GPL as well, also, if
he just put e.g. a binary of XVID into his installer. If he put a download
link just for XVID on his page, which works together with the application,
that's fine with me. 

None of these cases depends on whether thesource of the application is
available, and none of the violations would be changed if XVID's sources
were included. 

Maybe this is not the official reading of FSF, but I don't know any other
that would work in real life. 

gruel