openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ariel Constenla-Haile <>
Subject Re: GStreamer avmedia plugin as copyleft?
Date Wed, 05 Oct 2011 00:34:54 GMT
Hello Mathias,

On Tue, Oct 04, 2011 at 11:28:06PM +0200, Mathias Bauer wrote:
> Am 04.10.2011 17:27, schrieb Ariel Constenla-Haile:
> > Hi there,
> > 
> > The GStreamer avmedia plugin is disabled when copyleft is disabled (the
> > default in AOOo). 
> >
> > I cannot understand why this is treated as copy-left code. The plugin
> > was developed by Oracle and is on the software grant; building it only
> > requires system headers and linking against system libraries. 
> > In this sense, the code is just like the VCL GTK and KDE plugins, and the GTK
> > and KDE file pickers... these are not disabled as copy-left code.
> > 
> > So, is this code copy-left code? Does building and shipping the pulgin
> > break some Apache licensing rule?
> > 
> > Regards
> The GStreamer integration doesn't make sense without GStreamer - so we
> shouldn't build it when no GStreamer libs are available.

of course it does not make sense a GStreamer integration without
GStreamer, but OOo never shipped its own GStremer libraries, just like
OOo never shipped its own gtk libs for the VCL gtk plugin, nor Qt3/KDE3
libs for the VCL kde plugin (Qt4/KDE4 was never built by Hamburg, IIRC
pl made a cws for that).

So building the plugins was decided by configure when libs were
available on the system (I guess Hamburg built on Linux system with gtk and 
kde3  libraries - kde4 was never built).

> We decided that configure without switches should be the default Apache
> build. OTOH we didn't agree on linking against lgpl libraries in the
> system in this default build, so I disabled GStreamer by default (as
> well as some other copyleft components - there is no difference in that
> regard between GStreamer and hunspell!). 

IMHO there is a difference, the GStreamer case should be placed together
with gtk and Qt/KDE integration, see below.

> This is an open question that
> IIRC I already asked here on that list (at least I wanted to do that ;-)).

following this, we should also disable the vcl plugins; that is
a vanilla AOOo without Linux Desktop integration! A no-go, of course...

> If we decided that linking against LGPL libs installed in the local
> system is OK for a "vanilla Apache" build, we could enable e.g.
> GStreamer on Linux again, but then we also could enable Hunspell and the
> other stuff that are disabled when "copyleft" stuff isn't enabled
> explicitly. 

I think we should make a difference here between Linux-only features and 
multi-platform ones.
GStreamer, VCL gtk plugin, VCL kde plugins, gtk/kde filepickers always linked 
against system libraries, and it was never intended to ship own versions of 
In these Linux specific cases, we do not face the problem of finding
alternatives because Apache only ships software with an Apache
compatible license: OOo (and now AOOo) will never ship its own copies of
GStreamer, gtk, Qt nor KDE.

The Hunspell case is different, because it would be possible to link
against Hunspell libs on Linux systems, but AFAIK this is not possible on 

> Until then you have to use "--with-system..." switches to
> enable these copyleft components. 

there was never a --with-system-qt|kde|gtk and it makes no sense to have
a --with-system-gstreamer.

It looks like GStreamer, gtk, Qt/KDE integration should be treated
different from other copy-left components that AOOo is supposed to ship,
because it will always links against system libraries, not ship its own

It seems the question remains if vanilla AOOo can link  against copy-left 
system libraries.

Ariel Constenla-Haile
La Plata, Argentina

View raw message