Andrew said:
Can you provide evidence to support this claim?
Mmm, evidence, always fun to research...
A quick search didn't turn up any statements which are black and white
on the particular issue of a "scripting language" API. As noted in the
paragraph above, I was going by other people's statements. Closest
thing I could find were these:
What is the difference between "mere aggregation" and
"combining two modules into one program"?
<
http://www.fsf.org/licenses/gpl-faq.html#TOCMereAggregation>
Mere aggregation of two programs means putting them side by side on
the same CD-ROM or hard disk. We use this term in the case where
they are separate programs, not parts of a single program. In this
case, if one of the programs is covered by the GPL, it has no effect
on the other program.
Combining two modules means connecting them together so that they
form a single larger program. If either part is covered by the GPL,
the whole combination must also be released under the GPL--if you
can't, or won't, do that, you may not combine them.
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.
Also:
However, in many cases you can distribute the GPL-covered software
alongside your proprietary system. To do this validly, you must make
sure that the free and non-free programs communicate at arms length,
that they are not combined in a way that would make them effectively
a single program.
The difference between this and "incorporating" the GPL-covered
software is partly a matter of substance and partly form. The
substantive part is this: if the two programs are combined so that
they become effectively two parts of one program, then you can't
treat them as two separate programs. So the GPL has to cover the
whole thing.
And:
If the program dynamically links plug-ins, and they make function
calls to each other and share data structures, we believe they form
a single program, so plug-ins must be treated as extensions to the
main program. This means that linking the GPL-covered plug-in with
the main program would violate the GPL. However, you can resolve
that legal problem by adding an exception to your program's license
which gives permission to link it with the non-free main program.
Which is from the GNU.org FAQ. here:
http://www.fsf.org/licenses/gpl-faq.html
Now, the first two quotes don't explicitly state that, in the event that
you let *someone else* distribute the GPL software, you are okay with
using direct and intimate communication (which the Python module being
discussed would, I think, qualify as). However, that is the image that
arises. That is, if you are not distributing the GPL software you might
be okay, if not for that third paragraph.
The first two quotes suggest that, if your software links "intimately"
with the GPL software and you distribute both pieces of software (even
though only "alongside" one another, (such as two download links from a
web-site?)), though, then your package is a derivative work and thus
GPL-requiring.
The third quote, however, goes much farther. A plug-in, presumably
downloaded entirely separately from an application (hence plug-in) is
somehow able to violate the license of the plug-in merely by being
loaded by the proprietary application, effectively by being "linked in"
by the user. In the situation we are describing, a GPL library with an
arguably more intimate linking (the Pythonic interface) is being loaded
into a proprietary application, we would seem to have met all of the
conditions outlined in that third paragraph (and more).
To make that work, the using application somehow has to be a derivative
work of the plug-in, which, particularly in the case of a plug-in API,
makes no sense, after all, the plug-in API is from the application and
almost certainly has no code specific to the GPL-licensed plug-in. What
would stop a user from using the plug-in with the application?
How this works, (other than wishful thinking) I don't know, as it had
been my impression that the unmodified use of GPL software on your own
computer wasn't affected by the GPL. The strange thing about the third
quote is that, from the GPL section 0 (the FAQ has no legal weight AFAIK):
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the
Program is covered only if its contents constitute a work based on
the Program (independent of having been made by running the
Program). Whether that is true depends on what the Program does.
which seems to allow the *end user* to combine proprietary code with
unmodified GPL-licensed software for their own use.
As mentioned in the earlier message, I don't think there's been too much
case law saying that you can claim copyright on something which doesn't
include any of your code, the LGPL even explicitly states (section 5),
if there's no LGPL code in the given element, then it is not a
derivative work. Still, there must be some logic which makes the
application above somehow a derivative of its plug-in. Though again, I
was under the impression that, for personal use, you could create
derivatives which linked against proprietary code (even intimately)...
Anywho, hope that's sufficient, must be off to write now.
Mike
(In case anyone is silly enough to think I were... "I am not a lawyer")
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
).