[gst-devel] Re: Multiple licenses and plugins

[Christian Fredrik Kalager Schaller]

On Tue, 2002-08-20 at 19:21, Richard Stallman wrote:
>     > 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.)
I often do :)

> 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?
Well first of all since we are to be a GNOME system library we have to
be LGPL. There is a strict policy in GNOME that all libraries that are
to be officially considered part of the GNOME development platform
should be LGPL. 

Also remember that it is not only non-free software that gets 'hit' by
GStreamer becoming GPL. Free software under non-GPL compatible licenses
will also be unable to access the functionality we provide. Which means
that applications already available out there under such licenses will
not be able to get ported to use GStreamer.

Also making a media framework is a very huge undertaking which requires
the effort developer with expert knowledge in one of the most
complicated fields in computing. We also feel that in order to being
able to attract enough developers we need to use a license that a large
as possible pool of developers feel acceptable. We feel that the LGPL is
a good compromise in that regard. A compromise that feels acceptable to
people on all sides of the scale ranging from people who personaly
prefer BSD style licenses and to people who wants to use more
restrictive licenses. 

The choice of licensing is a controversial topic even among developers
of free and/or opensource software and we are trying the balance their
wishes at the best of our ability.  


> 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.
Well the system is set up so that developers can code their application
to access only plugin X or Y. We also have as part of our documentation
a file that lists our plugins and the license of the library they are
calling. So anyone making a non-gpl compatible application have ample
opportunity to see and make sure that his or her application do not
access anything they shouldn't. 

We have also been discussing implementing functions that will make it
even harder for a developer to use plugins illegally by mistake. 

Yet, in the end we believe in the principle of personal responsibility
and think that if someone gets shot it is the shooter who is to blame
and not the gun. I would think that GNU shares this belief with us as it
is an organization focusing on the principle of freedom which can't
truly exist without concepts such as trust and morale. 


>     > 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?
Well upon closer consideration I am not sure if this is an issue, cause
if I understand you correctly these issues only arise if non-gpl
compatible software tries accessing the plugin code (which in turn is
linked to a library covered under the GPL). As long as only gpl covered
apps are meant to access the gpl plugins we are in the clear, correct?


>     > 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.
> 
Well we have been discussing this some and we are not yet ready to make
any final decision (partly due to our lead maintainer being away on
vacation.) 
One thing we do wonder about however is if being a GNU project would
give us free legal aid in case we get attacked by the record or movie
industry? (for using reverse engineered codecs, supporting playback
encrypted DVD's etc.) 

Christian

> 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.
> 
>