Richard:
> On Wed, 2008-03-19 at 12:56 -0500, Brian Cameron wrote:
>> I notice that Audacity is released under the GPL. The GPL does not
>> allow people to distribute GPL code that links in any code which
>> contains any non-royalty free patents.
>
> That does depend on the version of the GPL to some extent. Note that
> audacity has not yet upgraded to GPL v3 (although it may well do so).
My understanding is this is an issue with GPLv2. I haven't reviewed
GPLv3 well enough to understand the impact there.
>> I notice that audacity supports linking with libmad and libtwolame
>> for MP3 and MPEG2 support. Hoewver, since these are non-royalty free
>> this obviously means that no distribution can build audacity with
>> this code enabled and distribute it. This might be useful for
>> end-users who want to go through the trouble of building audacity
>> themselves to turn on this support, but not all users would be
>> likely able to figure out how to do this, and it might not be a
>> legally viable option for some users.
>
>> This also means that even if a distro has license to ship a particular
>> media codec (such as MP3 or MPEG2), they still would not be able to
>> distribute support with audacity because this violates the GPL license.
> That only applies if you are in a jurisdiction where the patents apply.
> In Europe (for example) there is not held to be any patent on MP3
> decoding (because of prior art in the standard), or on MPEG1 layer 2
> audio encoding or decoding.
While this may not apply to all distros, it does apply to distros
which are based in the U.S. or which distribute to the U.S. This
is probably most major distros, I'd think. It does include Solaris
at any rate.
>> This seems a better approach than linking libraries like libmad and
>> twolame directly into audacity.
> Depends on your definition of "better". It might be more flexible if you
> are paranoid about potential software patents in a non-free country
> (mainly the USA). On the other hand it's non-standard (every other
> open-source media application I know of links directly to these
> libraries), inefficient, inflexible (because the amount of information
> you can get back from a gst-launch command is minimal, e.g. no progress
> information) and a pain to configure on the user's system (because they
> need loads of different binaries installed and they all need to be able
> to find each other. This is a particular issue for Windows
> installations).
There are many media applications which use interfaces like GStreamer
to interact with different media types. I think linking against
GStreamer directly is better than using gst-launch, for the reasons you
explain.
The only problem with linking in GStreamer directly is that if you do
not have a license exception which allows distribution with non-free
GStreamer plugins, then you force the distribution to decide whether
to ship audacity or to ship non-free media plugins, or to disable
any potentially controversial media support in audacity.
The only reason I suggested using gst-launch instead of linking with
the GStreamer libraries is because it sounded like you weren't in
a position to put together a reasonable license clause to allow the
usage of non-free GStreamer plugins. Linking against GStreamer is
less useful if you force the distro between shipping your application
or shipping any non-free plugins they might have license to ship.
If you run gst-launch instead of linking then I believe this avoids
the need for a GPL exception since your application wouldn't be linking
against GStreamer.
> It's notable that Xine, Mplayer, VLC and (optionally) FFMPEG are all
> licensed under the GPL whilst including support for formats that in some
> jurisdiction may be patented (this is a statement that can be made about
> almost any non-trivial audio and video format, given the way patents
> have been granted in some jurisdictions). They are however all based in
> Europe (in so far as an open source project developed over the web is
> based at all).
I don't believe any major distro ships any of these programs because
these programs all have IP issues. The FFMPEG and MPlayer community is
very open about the fact that they disregard IP law.
http://ffmpeg.mplayerhq.hu/legal.htmlWhen you compare audacity to these products, are you suggesting that
the audacity community has a similar attitude? That it perhaps should
not be used in non-free countries?
Most distros don't ship a DVD player, for example.
> Your point that some users won't be able or know how to recompile media
> applications with extra libraries is a valid one, however it is one of
> the reasons that few users use the commercial Linux distributions for
> serious multimedia work, given that none of the non-commercial
> distributions have ever seen this as a problem. For the commercial
> distributions with active user communities there are considerable
> repositories of additional packages available which usually include full
> builds of multimedia software.
I think GStreamer and Fluendo are working to provide a realistic and
legal approach to providing more rich media on Linux/UNIX/Solaris. But
you are right that there is a long way to go.
Brian
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel
signature.asc (196 bytes) 
