[gst-devel] Re: Multiple licenses and plugins

[Richard Stallman]

Please forgive me for taking time to get back to you.  On August 21 I
was giving a speech in Guatemala, and the next day I had to get up at
4am.

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

I think that is a very good idea.  Without this, many people are likely
to use GPL-covered plug-ins in non-free apps simply because they did not
realize it was an issue.  This would make sure they see there's an issue.

    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.

Yes and no.  A person who leaves a gun where anyone can easily get his
hands on it is partly responsible if someone gets shot.  If you left a
loaded gun where kids can get it, and a kid shoots another kid, I
suspect you'd be accused of negligence (at least).

The feature you proposed above is a good way to avoid leaving the gun
around loaded.

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

Correct.

    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?

We would try to help any free software project with advice and a
little help.  We would do it some what more if the program is a GNU
package, and even more if it is copyright FSF.

On the other hand, we can't promise to fight every case to the
death--partly because these companies could try to overwhelm our
resources, just as they could try to overwhelm yours.  We would always
have to try to judge whether the case can be won.

However, they could not overwhelm our resources quite so easily--we do
have some money in the bank to use if we think it will get us a good
outcome.  So there are situations where they could hope to crush you
easily where we could resist.

     (for using reverse engineered codecs, supporting playback
    encrypted DVD's etc.) 

If you're talking about including something equivalent to DeCSS, it
would be hopeless to try to fight that case again in the US.  The
problem is, our side has already lost.  Our lawyer's advice would
surely be that you have to leave that feature out, in the US and maybe
now in Europe as well.