A quick note to start with - thanks Luc-Eric for the detailed info on
the pros and cons you've found with the various approaches. It's good
to hear this stuff in relation to more complex packages.
I see. I didn't read their licensing page that way, but I see what you mean
now. What does this mean for XSI plugins if they were developed with QT?
Chris, I faced this very issue when developing Splish (a renderfarm
manager which my very generous bosses have allowed to be released
under the GPL). Dealing with combining open source and closed source
applications - particularly when it comes to open source plugins for
closed source packages (or vice versa) because a combination of
technical and legal issues.
Any application which links against a GPL application/library must
adhere to the details of the license it was the library it links
against (or any that application links against). So the issue in the
case of a Qt application becomes split. Other than the plugins for
applications all of splish is under the straight GPL (not sure whether
to hold off an official packaged release for v3 of the GPL or just
release under v2 until that time - for the purposes of this example
I'll just treat it as though it's v2 - though v3 shouldn't be
affecting what I'm saying here).
The main program heavily uses Qt so because we wish to distribute it
we are required to make it available under the GPL (as it links
against Qt which is GPLed). Qt is available under multiple licenses
though so we could purchase a license if we wished to keep it closed
source instead.
Though when it comes to the plugin for XSI you can see the issue - I'd
be linking against both XSI and Qt - which would require XSI to be
GPLed should I choose to distribute the plugin - which we want to do.
So this ruled out being able to use the Qt libraries within a plugin
we want to distribute.
As I wish to distribute this plugin, which links against XSI under the
GPL, that would still require XSI to be released under the GPL. The
resolution to this is to add an exception to the GPL for the plugin
allowing it to be linked against XSI through the XSI SDK. This is the
option I've chosen.
So in order to pass information to the main part of splish, rather
than linking to splish (which would link to Qt etc) I've chosen to use
pipes and external applications. To submit to the farm I've written a
program called splishsubmit - this does use the Qt libraries, but
because my plugin is executing this program, not linking against it
I've met the requirements of the GPL (allowing for the exception I put
in the plugin to allow linking against XSI). As far as executing this
you could either pass arguments to the command, or pipe information
through stdin/stdout (check the popen function). A combination of the
two could also be used.
The linking exception added to the license couldn't work with the main
program (if I did want to try linking against that in a program I'm
distributing) because that would require Trolltech to also provide the
same linking exception in the GPL when they license Qt.
I hope that explains it clearly. The short of it is - if you're not
distributing the program you are free to do as you wish. If you are
then a little planning may be able to give you an option which
satisfies the license, but I'd not want to attempt it for anything
much more complicated than this example as you start getting into
territory where you'll be enforcing technical limitations which could
either make development significantly harder, performance
significantly worse or both.
Hope this helps :-)
Cheers,
Alan.
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
