uraeus www: www/src/htdocs/documentation/

CVS Root:       /cvs/gstreamer
Module:         www
Changes by:     uraeus
Date:           Fri Jan 02 2009  12:40:37 UTC

Log message:
update licensing advisory to be more explicit on patents and folow our current
practice. Also remove the item about a planned 'GPL plugins' blocking mechanism as it was realized to be a stupid idea as GPL issues are only distribution related, not use.

Modified files:
    src/htdocs/documentation: licensing.xml

Links:
http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/www/src/htdocs/documentation/licensing.xml.diff?r1=1.9&r2=1.10

====Begin Diffs====
Index: licensing.xml
===================================================================
RCS file: /cvs/gstreamer/www/src/htdocs/documentation/licensing.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- licensing.xml	10 Dec 2008 13:03:01 -0000	1.9
+++ licensing.xml	2 Jan 2009 12:40:23 -0000	1.10
@@ -28,6 +28,11 @@
 in order to understand how GStreamer works in a licensing context.
 </p>
 <p>
+This text is also meant to explain a little about our thinking in regards to how to deal with
+the problem of software patents which is an even bigger pain in the field of multimedia than other
+fields of programming.
+</p>
+<p>
 
 For more information on licensing you can check out our
 <a href="&site;/data/doc/gstreamer/head/faq/html/chapter-legal.html">
@@ -41,27 +46,30 @@
 To keep this policy viable, the GStreamer community has made a few licensing
 rules for code to be included in GStreamer's core or GStreamer's
-official modules, like our plugin packages. 
+official modules, like our plugin packages.
 <B>We require that all code going into our core packages is LGPL</B>.
 For the plugin code, we require the <B>use of the LGPL for all plugins written
 from scratch or linking to external libraries</B>.  The only exception to this
-is when plugins contain older code under the BSD and MIT license.  They can use those licenses instead and will still be considered for
-inclusion, we do prefer that all new code written though is at least dual licensed LGPL. 
-We do not accept GPL code to be added to our plugins modules, but we
-do accept LGPL-licensed plugins using an external GPL library for some of our plugin modules.  The reason we demand plugins be licensed under the LGPL, even 
-when they are using a GPL library, is that other developers might want to use 
-the plugin code as a template for plugins linking to non-GPL libraries. We also accept dual licensed plugins for inclusion as long as one of the licenses offered for dual licensing is the LGPL.
+is when plugins contain older code under the BSD and MIT license.  They can use those licenses 
+instead and will still be considered for inclusion, we do prefer that all new code written 
+though is at least dual licensed LGPL. We do not accept GPL code to be added to our plugins modules, 
+but we do accept LGPL-licensed plugins using an external GPL library for some of our plugin modules.  
+The reason we demand plugins be licensed under the LGPL, even when they are using a GPL library, is that other 
+developers might want to use the plugin code as a template for plugins linking to non-GPL libraries. We also accept 
+dual licensed plugins for inclusion as long as one of the licenses offered for dual licensing is the LGPL.
-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 uses 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.
+We also do not allow plugins under any license into our core,base or good packages if they have known patent issues
+associated with them. This means that even a contributed LGPL/MIT licensed implementation of something which there is a 
+licensing body claiming fees for, those plugins would need to go into our gst-plugins-ugly module.
+All new plugins, regardless of licensing or patents tend to have to go through a period in our incubation module, gst-plugins-bad 
+before moving to ugly, base or good.
+
 <h2>Licensing of applications using GStreamer</h2>
 The licensing of GStreamer is no different from a lot of other libraries out 
@@ -109,9 +117,9 @@
 be used together with proprietary plugins or not</b>. 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 proprietary plugins to be bundled 
-with GStreamer and your applications, in order to make sure that as many
-vendors as possible go with GStreamer instead of less free solutions.
+software using a license that will allow non-free, patent implementing or non-GPL
+compatible plugins to be bundled with GStreamer and your applications, in order to make 
+sure that as many vendors 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
 <A href="http://www.xiph.org/">Xiph.org</A> formats.
@@ -146,7 +154,7 @@
 other LGPL using projects.
-I have above outlined the practical reasons for why the GStreamer community
+We have above outlined the practical reasons for why the GStreamer community
 suggest you allow non-free plugins to be used with your applications. We feel
 that in the multimedia arena, the free software community is still not strong
 enough to set the agenda and that blocking non-free plugins to be used in our

------------------------------------------------------------------------------