Re: Question regarding QPLed plugins for a GPLed app
On Fri, Mar 18, 2005 at 06:22:49PM +0000, Anthony W. Youngman wrote:
> In message <[🔎] 20050317044922.GB953@eclipse.debian.net>, Ben Burton
> <bab@debian.org> writes
> >Hi,
> >
> >I'm currently involved in a discussion on kde-core-devel regarding the
> >use of a QPLed plugin that is dlopened within a GPLed application. For
> >details:
> >
> > http://lists.kde.org/?l=kdevelop-devel&m=111102280128853&w=2
> >
> >I received the following response, claiming that dlopened plugins do not
> >need to be GPL-compatible:
> >
> >>> Given that the QPL is GPL-incompatible, this raises issues for GPLed
> >>> programs that wish to use this kpart. I believe this at least
> >>> includes quanta and kdevelop (unless I'm mistaken).
> >>
> >>kparts are loaded at runtime. It has always been understood in the
> >>community that the license restrictions based on copyright law do not
> >>apply to runtime components. The implications of reinterpreting USC 17
> >>this way are profound. The effects on Java development alone would be
> >>catastrophic.
> >>
> >>It is somewhat understood that a deliberate misuse of runtime components
> >>to circumvent copyrights is not allowed, but this is certainly NOT the
> >>case for quanta and kdevelop (you also forgot konqueror). These
> >>applications are designed to load available runtime components solely
> >>on the basis of the services made available. There is no copyright
> >>violation occuring when a user loads a plugin at runtime, particularly
> >>one with a generic interface like a kpart.
>
> Given that the GPL explicitly does not cover use of the software, and
> permits use as required, I would say it's definitely the case that no
> copyright violation occurs when the user loads the component. Assuming
> the main app is GPL, and the plug-in is QPL, the user has legal
> possession of both and therefore the GPL permits their use.
I believe (and check this list archive about problems concerning QPLed emacs
.el files) that the point here is if the QPLed code sole intention is to be
linked with a GPLed work, and it cannot be used with another program (cannot
or has not), then even if it is the final user who does the linking, it is
considered a derivative work.
Read the GPL FAQ and in particular the follozing entry :
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLAndPlugins
which applies to your case, and the next entries in the FAQ also. Also i
believe that the following one :
http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation
Has a nicer explanation :
What constitutes combining two parts into one program? This is a legal
question, which ultimately judges will decide. We believe that a proper
criterion depends both on the mechanism of communication (exec, pipes, rpc,
function calls within a shared address space, etc.) and the semantics of the
communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely
combined in one program. If modules are designed to run linked together in a
shared address space, that almost surely means combining them into one
program.
By contrast, pipes, sockets and command-line arguments are communication
mechanisms normally used between two separate programs. So when they are
used for communication, the modules normally are separate programs. But if
the semantics of the communication are intimate enough, exchanging complex
internal data structures, that too could be a basis to consider the two
parts as combined into a larger program.
and basically what this means is if the plugin interface is a industry-wide
standard, and the plugin makes no use of code hooks provided by the program it
plugs too, then it is two separate works, while if the plugin uses an
interface which is specific to the app, and makes use of code from the app it
plugs into, then it is a derivative work, and here the GPL and the QPL are
incompatible.
Friendly,
Sven Luther
Reply to: