<?xml version="1.0"?>
<!DOCTYPE xml
[
  <!ENTITY % site-entities SYSTEM "../entities.site">
  %site-entities;
  <!ENTITY % gst-entities SYSTEM "../entities.gst">
  %gst-entities;
]>

<?xml-stylesheet href="../page.xsl" type="text/xsl"?>
<page>
  <title>GStreamer: Licensing advice</title>
  <body>
<h1>Licensing your applications and plugins for use with GStreamer</h1>

<p>This document is the result of many discussions both inside the GStreamer 
community and with stakeholders outside the community. It includes the
results of discussions with many lawyers, including official representatives of the FSF to help us ensure we cover as much as possible as correctly as possible. The advice contained in here is meant for information and guidance for people developing free and open source software using the GStreamer library, so they are aware of the
consequences of their choices. People developing properietary software or 
people distributing GStreamer might also find this document useful in order
to understand how GStreamer works in a licensing context.</p>

<h2>Licensing of code contributed to GStreamer itself</h2>
<p>GStreamer is a plugin based framework licensed under the LGPL. The
reason for this choice in licensing was to ensure that everyone can use 
GStreamer to build applications using licenses of their choice. 
</p>
<p>
To keep this viable the GStreamer community has made a few licensing rules
for code to be included in GStreamer or GStreamer's central modules like our
official plugin packages. The first rule is that we demand that all new code written is licensed
under the LGPL. Plugins can use other licenses like MPL or BSD if they are based
on older code under these licenses. Plugins can use GPL libraries, but we ask that
the plugin developer mail the library developer(s) and ask if a relicensing to LGPL is possible. The actual plugin code put into GStreamer would have to be LGPL even 
if it it is utilizing a GPL licensed library. The reason for this is because
other developers might want to use the plugin code as a template for plugins
linking to LGPL libraries and similar.
</p>
<p>
We also plan on splitting out the plugins using GPL libraries into a separate 
package eventually and implement a system which makes sure an application
will not be able to access these plugins unless it utilize some special code 
to do so. The point of this is not to block GPL licensed plugins from being used
and developed, but to make sure people are not unintentionally violating the GPL
license of said plugins.
</p>
<h2>Licensing of applications using GStreamer</h2>
<p>
The licensing of GStreamer is no different from a lot of other libraries out 
there like GTK+ or glibc. What complicates things with regards to GStreamer 
is its plugin based nature and the heavily patented and proprietary nature 
of multimedia codecs. And while patents on software are currently only allowed in 
a small minority of world countries, the US and Australia being the most important
of those, the problem is that with the very central place the US hold in the world economy and the computing industry especially, software patents are hard to ignore
wherever you are.
</p>
<p>
Many companies, like major GNU/Linux distributions, who want to offer their
customers out of the box support for patented formats would need to do this
in a proprietary way or risk heavy litigation and punishment from patent owners.
This leaves them the choice of either using special proprietary applications
or try to integrate the support into the general multimedia infrastructure
provided by GStreamer. Faced with one of these two evils the GStreamer community
of course prefer the second option.
</p>
<p>
The problem which arise is that most Free and open source applications 
developed use the GPL as their license. While this is generally a good
thing it creates a dilemma for people who want to put together a distribution.
Because if they include proprietary plugins in GStreamer to support patented
formats in a way that is legal for them, they do risk running afoul with the 
GPL license of the applications. We have gotten some conflicting reports from
lawyers of whether this is actually a problem, but the official stance of the FSF is that it is a problem so that is what we go by as our measuring stick.
</p>
<p>
So what does this mean for you as an application developer? Well it means
you have to make an active decision on whether you want your application to
be used together with proprietary plugins or not. What you decide here will
also influence the chances of commercial distributions and Unix vendors
shipping your application. The GStreamer community suggest you license your
software using a license that will allow properietary plugins to be bundled 
with GStreamer and your applications in order to make sure that as many
people as possible go with GStreamer instead of less free solutions.
This in turn we hope and think will let GStreamer be a vehicle for wider 
use of free formats like the Ogg formats.
</p>
<p>
If you do decide that you want to allow for non-free plugins to be used with
your application you have a variety of choices. One of the simplest is using
licenses like LGPL, MPL or BSD for your application instead of the GPL. 
Another suggested option is adding a statement of interpretation to your GPL
license stating stating that you don't interpret the GPL to block anyone from
shipping your GStreamer based application together with non-free plugins.
We have made a example of such statement available <a href="statement.html">here</a>
</p>
<p>
If you do not want proprietary plugins to be used with your application you
are of course free to use the GPL for it. And distributions not targeting the US market
will of course still be able to combine your application with open source plugins
implementing the codecs in question, like our ffmpeg based plugin. Distributions
who do not want to distribute any non-free formats, only free formats like the
Ogg ones, will of course also be likely to distribute your application if
it ends up among the best of its kind.
</p>
  </body>
</page>
