Hi,
Sven Neumann wrote:
Dave Neary <dneary@xxxxxxx> writes:Following what you (Sven) said in the previous mail, it also seems like the libgimp parts are independent of the original code, and calls the original functions via a PDB proxy, so licence issues wouldn't come into it.
Well, there are license issues when a non-GPL application makes calls to GPL-ed code by whatever means.
I don' think this is an accurate representation of the issue. It certainly doesn't tally with my understanding. That said, I'm no expert.
But let's take an example...
I write a GPL network daemon (say red carpet). Someone write a non-GPL compliant client (say an LGPL encapsulation of the RedCarpet XML-RPC protocol to allow proprietary implementations). Now that library is calling GPL code, albeit via a network protocol. Is the client library in breach of the GPL?
How about if the relationship is via an ORB?
A GIMP plug-in is a completely different process space than the GIMP core. Information is passed via a wire protocol which is implemented at both ends using LGPL code. I don't see how this is different from viewing the GIMP as a server, and the plug-in as a client. Or alternatively, the PDB as a broker and both the plug-ins and the rest of the core as clients.
This is a difficult subject and it's hard to judge if a plug-in should be considered part of the GIMP application (which would mean that the GPL applies) or if it's a mere aggregation as per section 2 of the GNU General Public License. Our position on this is outlined in the file LICENSE which is included with the GIMP source tree.
While the exemption in the LICENCE file does indeed clear up any possible confusion, I'm not sure it's necessary. What it also clears up, though, is that there are no licence issues with exporting a core procedure to the PDB, and wrapping that procedure in libgimp, which was the case in point.
Cheers, Dave.
-- Dave Neary bolsh@xxxxxxxx
