Automatic update of common submodule

From 3cb3d3c to 5edcd85

MAINTAINERS

@@ -5,7 +5,8 @@ of people, including, but not limited to:
  Wim Taymans <wim.taymans@gmail.com>
  David Schleef <ds@schleef.org>
  Tim-Philipp Müller <tim centricular net>
+ Sebastian Dröge <slomo circular-chaos org>
 
 Maintainer-related issues should be addressed to:
 
-  gstreamer-devel@lists.sourceforge.net
+  gstreamer-devel@lists.freedesktop.org

README

@@ -1,3 +1,5 @@
+GStreamer 1.1.x development series
+
 WHAT IT IS
 ----------
 
@@ -21,8 +23,8 @@ We track bugs in GNOME's bugzilla; see the website for details.
 
 You can join us on IRC - #gstreamer on irc.freenode.org
 
-GStreamer 0.10 series
----------------------
+GStreamer 1.0 series
+--------------------
 
 Starring
 
@@ -135,13 +137,14 @@ PLATFORMS
 ---------
 
 - Linux is of course fully supported
-- FreeBSD is reported to work; other BSD's should work too
+- FreeBSD is reported to work; other BSDs should work too
 - Solaris is reported to work; a specific sunaudiosink plugin has been written
-- MacOSX is reported to work; specific audio and video sinks have been written
-- Windows support is experimental but improving.  Output sinks have been
-  written but are not yet included in the code. We support
+- MacOSX works, binary 1.x packages can be built using the cerbero build tool
+- Windows works; binary 1.x packages can be built using the cerbero build tool
   - MSys/MinGW builds
-  - Microsoft Visual Studio 6 builds (see win32/README.txt)
+  - Microsoft Visual Studio builds are not yet available or supported
+- Android works, binary 1.x packages can be built using the cerbero build tool
+- iOS works
 
 INSTALLING FROM PACKAGES
 ------------------------
@@ -193,7 +196,7 @@ COMPILING FROM SOURCE TARBALLS
 COMPILING FROM GIT
 ------------------
 
-When building from git sources, you will need to run autogen.sh to generate 
+When building from git sources, you will need to run autogen.sh to generate
 the build system files.
 
 You will need a set of additional tools typical for building from git,
@@ -208,10 +211,7 @@ them.  You can also specify specific versions of automake and autoconf with
 
 Check autogen.sh options by running autogen.sh --help
 
-autogen.sh can pass on arguments to configure - you just need to separate them
-from autogen.sh with -- between the two.
-prefix has been added to autogen.sh but will be passed on to configure because
-some build scripts like that.
+autogen.sh can pass on arguments to configure
 
 When you have done this once, you can use autoregen.sh to re-autogen with
 the last passed options as a handy shortcut.  Use it.
@@ -219,9 +219,17 @@ the last passed options as a handy shortcut.  Use it.
 After the autogen.sh stage, you can follow the directions listed in
 "COMPILING FROM SOURCE"
 
-You can also run your whole git stack uninstalled.  The script in
-the gstreamer module /scripts/gst-uninstalled) is helpful in setting
-up your environment for this.
+You can also run your whole git stack uninstalled in your home directory,
+so that you can quickly test changes without affecting your system setup or
+interfering with GStreamer installed from packages.  Many GStreamer developers
+use an uninstalled setup for their work.
+
+There is a 'create-uninstalled-setup.sh' script in
+
+  http://cgit.freedesktop.org/gstreamer/gstreamer/tree/scripts/
+
+to easily create an uninstalled setup from scratch.
+
 
 PLUG-IN DEPENDENCIES AND LICENSES
 ---------------------------------

README.static-linking

@@ -0,0 +1,174 @@
+=================================
+ GStreamer Static Linking README
+=================================
+
+DRAFT, April 2013
+
+
+   I. INTRODUCTION
+
+It is possible to link GStreamer libraries, plugins and applications
+statically, both in case of free/libre/open-source software applications
+and proprietary applications. On some platforms static linking may even
+be required.
+
+However, distributing statically linked binaries using GStreamer usually
+requires additional effort to stay compliant with the GNU LGPL v2.1 license.
+
+The purpose of this document is to draw attention to this fact, and to
+summarise in layman's terms what we believe is required from anyone
+distributing statically linked GStreamer binaries. Most of this also
+applies to dynamically linked GStreamer binaries.
+
+
+   II. DISCLAIMER
+
+This document is not legal advice, nor is it comprehensive. It may use
+words in ways that do not match the definition or use in the license
+text. It may even be outright wrong. Read the license text for all the
+details, it is the only legally binding document in this respect.
+
+This document is primarily concerned with the implications for the
+distribution of binaries based on LGPL-licensed software as imposed by
+the LGPL license, but there may be other restrictions to the distribution
+of such binaries, such as terms and conditions of distribution channels
+(e.g. "app stores").
+
+
+   III. THE SPIRIT OF THE LGPL LICENSE
+
+The GNU LGPL v2.1 license allows use of such-licensed software by
+proprietary applications, but still aims to ensure that at least the
+LGPL-licensed software parts remain free under all circumstances. This
+means any changes to LGPL-licensed source code must be documented and
+be made available on request to those who received binaries of the
+software. It also means that it must be possible to make changes to the
+LGPL-licensed software parts and make the application use those, as far
+as that is possible. And that recipients of an application using
+LGPL-licensed software are made aware of their rights according to the
+LGPL license.
+
+In an environment where GStreamer libraries and plugins are used as
+dynamically-loaded shared objects (DLL/.so/.dyn files), this is usually
+not a big problem, because it is fairly easy to compile a modified version
+of the GStreamer libraries or LGPL plugins, and the application will/should
+just pick up and use the modified version automatically. All that is needed
+is for the original, LGPL-licensed source code and source code modifications
+to be made available, and for a way to build the libraries or plugins for
+the platform required (usually that will be using the build system scripts
+that come with GStreamer, and using the typical build environment on the
+system in question, but where that is not the case the needed build scripts
+and/or tools would need to be provided as well).
+
+
+   IV. THINGS YOU NEED TO DO
+
+  * You must tell users of your application that you are using LGPL-licensed
+    software, which LGPL-licensed software exactly, and you must provide them
+    with a copy of the license so they know their rights under the LGPL.
+
+  * You must provide (on request) all the source code and all the changes
+    or additions you have made to the LGPL-licensed software you are using.
+
+    For GStreamer code we would recommend that the changes be provided either
+    in form of a branch in a git repository, or as a set of "git format-patch"-
+    style patches against a GStreamer release or a snapshot of a GStreamer git
+    repository. The patches should ideally say what was changed and why it
+    was changed, and there should ideally be separate patches for independent
+    changes.
+
+  * You must provide a way for users of your application to make changes to
+    the LGPL-licensed parts of the code, and re-create a full application
+    binary with the changes (using the standard toolchain and tools of the
+    target platform; if you are using a custom toolchain or custom tools
+    you must provide these and document how to use them to create a new
+    application binary).
+
+    Note that this of course does not mean that the user is allowed to
+    re-distribute the changed application. Nor does it mean that you have
+    to provide your proprietary source code - it is sufficient to provide a
+    ready-made compiled object file that can be relinked into an application
+    binary with the re-compiled LGPL components.
+
+
+   V. THINGS TO LOOK OUT FOR
+
+While most GStreamer plugins and the libraries they depend on are licensed
+under the LGPL or even more permissive licenses, that is not the case for
+all plugins and libraries used, esp. those in the gst-plugins-ugly or
+some of those in the gst-plugins-bad set of plugins.
+
+When statically linking proprietary code, care must be taken not to
+statically link plugins or libraries that are licensed under less permissive
+terms than the LGPL, such as e.g. GPL-licensed libraries.
+
+
+   VI. SPECIAL CONSIDERATIONS FOR SPECIFIC USE-CASES
+
+
+   1. Proprietary GStreamer/GLib-based Application On iOS
+
+Let's assume an individual or a company wants to distribute a proprietary
+iOS application that is built on top of GStreamer and GLib through
+Apple's App Store. At the time of writing the Apple iPhone developer
+agreement didn’t allow the bundling of shared libraries, so distributing
+a proprietary iOS application with shared libraries is only possible using
+distribution mechanisms outside of the App Store and/or only to jailbroken
+devices, a prospect that may not appeal to our individual or company. So the
+only alternative then is to link everything statically, which means the
+obligations mentioned above come into play.
+
+
+   2. Example: Jabber on iOS
+
+Tandberg (now Cisco) created a Jabber application for iOS, based on GStreamer.
+On request they provided an LGPL compliance bundle in form of a zip file, with
+roughly the following contents:
+
+buildapp.sh
+readme.txt
+Jabber/Jabber-Info.plist
+Jabber/libip.a [236MB binary with proprietary code]
+Jabber/main.mm
+Jabber/xcconfig/Application.xcconfig
+Jabber/xcconfig/Debug.xcconfig
+Jabber/xcconfig/Release.xcconfig
+Jabber/xcconfig/Shared.xcconfig
+Jabber/Resources/*.lproj/Localizable.strings
+Jabber/Resources/{Images,Audio,Sounds,IB,Message Styles,Emoticons,Fonts}/*
+Jabber/Resources/*
+Jabber.xcodeproj/project.pbxproj
+Jabber.xcodeproj/project.xcworkspace/contents.xcworkspacedata
+opensource/build/config.site
+opensource/build/m4/movi.m4
+opensource/build/scripts/clean-deps.sh
+opensource/build/scripts/fixup-makefile.sh
+opensource/build/scripts/MoviMaker.py
+opensource/build.sh
+opensource/env.sh
+opensource/Makefile
+opensource/external/glib/*
+opensource/external/gstreamer/{gstreamer,gst-plugins-*}/*
+opensource/external/openssl/*
+opensource/external/proxy-libintl/*
+opensource/toolchain/darwin-x86/bin/{misc autotoools,m4,glib-mkenums,glib-genmarshal,libtool,pkg-config,etc.}
+opensource/toolchain/darwin-x86/share/{aclocal,aclocal-1.11,autoconf,automake-1.11,libtool}/*
+opensource/toolchain/darwin-x86/share/Config.pm
+opensource/toolchain/darwin-x86/share/Config.pm.movi.in
+patches/glib/glib.patch
+patches/gst-plugins-bad/gst-plugins-bad.patch
+patches/gst-plugins-base/gst-plugins-base.patch
+patches/gst-plugins-good/gst-plugins-good.patch
+patches/gstreamer/gstreamer.patch
+patches/openssl/openssl.patch
+
+readme.txt starts with "This Readme file describes how to build the Cisco 
+Jabber for iPad application. You need to install Xcode, but the final package
+is built by running buildapp.sh." and describes how to build project,
+prerequisites, the procedure in detail, and a "How to Include Provisioning
+Profile Manually / Alternate Code Signing Instructions" section.
+
+
+   3. Random Links Which May Be Of Interest
+
+[0] http://multinc.com/2009/08/24/compatibility-between-the-iphone-app-store-and-the-lgpl/

common

@@ -1 +1 @@
-Subproject commit 3cb3d3cbbf794c18a6f91866c6d7fa38880c1eb8
+Subproject commit 5edcd857b2107cd8b78c16232dd10877513ec157