[gst-devel] Re: Multiple licenses and plugins

[Richard Stallman]

    > How did you choose the LGPL for the base library?  In some cases
    > that is the right decision, but many libraries would do better using
    > the GPL.  What job does the library do?
    It is the GStreamer multimedia framework. The reason we choose the LGPL was both 
    wanting a license that protected our work yet one that was open enough
    to enable it to get us some convergence in the [GNU/]Linux multimedia
    landscape.

(Would you please call the system "GNU/Linux"?  Using the term "Linux"
for more than the kernel makes it harder for the GNU Project to do its
work.  See http://www.gnu.org/gnu/why-gnu-linux.html.)

That kind of reason is a good reason in some cases.  Miguel and I
decided together that certain basic GNOME libraries should be LGPL'd,
this kind of reason.

The question is, how much good does it really do in this instance?
How does it particularly help the Free World, or the GNU Project, if
non-free programs that run on GNU/Linux use GStreamer rather than
something else?

If it encourages developers to integrate these programs well with
GNOME and the rest of GNU--rather than, say, KDE--that could make
GNOME and GNU more successful.  Is that the result you are hoping for?

Meanwhile, the fact that you plan to use GPL-covered plug-ins means
that if some non-free app links with your library, it is very likely
to be led into violating the GPL for plug-ins.  In effect, your
library may be in effect designed to encourage GPL violations.  That
is a serious problem.  If that is the real situation, it is a very
strong argument for using the GPL for the library.  That way, the line
will be clear, rather than vague.

    > That is correct, in most cases.  If the plug-in is general purpose
    > and not designed specifically for use with your library, they could
    > make a valid argument that this is the equivalent of running a command
    > from the hsell.
    Yeah, that description would fit us well as all the plugins we made 
    ourselves from scratch are LGPL, so it is only plugins based on 3rd
    party libraries that will be GPL (even if we license the 'plugin code'
    itself as LGPL).

We may be miscommunicating here.  Whether the plug-in is *based on*
someone else's more general package is relevant for other purposes but
it is not the issue I am raising here.

The issue is whether the finished plug-in, ready to be loaded by your
library, including whatever glue you added to some other general
package, communicates in some specific special way with your library.
Is the interface between plug-in and library as basic and minimal as
fork-and-exec, or does it include other more specific kinds of
communication?

    > By the way, the GNU Project is looking to establish direct
    > relationships with developers of parts with GNOME, for them to be
    > directly GNU packages.  Are you interested in doing that?
    Not really sure. For one thing we do not mind people using our library
    for applications that is licensed under a non-free license or even a
    non-opensource license.

Whether to do that is an important issue, which we're discussing it
now, but making GStreamer directly a GNU package is a different issue.


Here's the explanation of what it means for a program to be a GNU
package:

======================================================================
Calling a program GNU software means that its developers and the GNU
project agree that "This program is part of the GNU project, released
under the aegis of GNU"--and say so in the program.

This means that we normally put the program on ftp.gnu.org (although
we could instead refer to the developer's choice of ftp site).

This means that the official site for the program is on www.gnu.org,
specifically in /software/PROGRAMNAME.  Whenever you give out the URL
for the package home page, you would give this address.  (It is ok to
use another site for more informal secondary pages, such as info and
discussions meant for people who want to help develop the package.)

It means that the developers agree to pay some attention to making the
program work well with the rest of the GNU system--and conversely that
the GNU project will encourage other GNU maintainers to pay some
attention to making their programs fit in well with it.

Just what it means to make programs work well together is mainly a
practical matter that depends on what the program does.  But there are
a few general principles.  Certain parts of the GNU coding standards
directly affect the consistency of the whole system.  These include
the standards for configuring and building a program, and the
standards for command-line options.  It is important to make all GNU
programs follow these standards, where they are applicable.

Another important GNU standard is that GNU programs should come with
documentation in Texinfo format.  That is the GNU standard documentation
format, and it can be converted automatically into various other formats.
You can use DocBook format or another suitable format for the
documentation sources, as long as you verify that converting it
automatically into Texinfo gives correct and reasonable results.

If a GNU program wants to be extensible, it should use GUILE
(http://www.gnu.org/software/guile/guile.html) as the programming
language for extensibility--that is the GNU standard extensibility
package.  If the program doesn't use GUILE today, at least there
should be a firm plan to support it in the future.

A GNU program should use the latest version of a license that the GNU
Project recommends--not just any free software license.

A GNU program should not recommend use of any non-free program, and it
should not refer the user to any non-free documentation for free
software.  The need for free documentation to go with free software is
now a major focus of the GNU project; to show that we are serious
about the need for free documentation, we must not contradict our
position by recommending use of documentation that isn't free.

Occasionally there are issues of terminology which are important for
the success of the GNU project as a whole.  So we expect maintainers
of GNU programs to follow them.  For example, the documentation files
and comments in the program should speak of Linux-based GNU systems or
GNU/Linux systems, rather than calling the whole system "Linux", and
should use the term "free software" rather than "open source".

Deciding that a program is GNU software does not necessarily require
transferring copyright to the FSF; that is a separate question.  If
you transfer the copyright to the FSF, the FSF will enforce the GPL
for the program if someone violates it; if you keep the copyright,
enforcement will be up to you.

As the GNU maintainer of the package, please make sure to stay in
touch with the GNU Project.  If we come across a problem in the
package or a problem in these arrangements for it, we need to tell you
about it, and to discuss with you how to solve it.  Sometimes we will
need to ask you to work with other maintainers to solve a problem that
affects multiple packages.  If simply contacting you is not
straightforward, easy problems become hard, and hard ones sometimes
become impossible.