PyQT Licensing and plugins/scripting

Hi all,
I'm about to write an application, and I'd like to use PyQt, but before
choosing this toolkit I would like to clarify some particular licensing
issues; if some user has already touched these, I would like to hear from
his experiences.

This app should be cross-platform, so, given qt licensing policies, I would
buy a commercial PyQt license and a commercial Qt license.

Could I license the application under the GPL for Gnu/Linux and under a
commercial license for Windows and Mac OS X? If this is possible, I guess
that contributions to the GPLed version could not be incorporated in the
commercial version, but this would not be a big problem.

The main issue with licensing is that I would like to give users of the
application a scripting framework (for macros and the like), and eventually
a plugin framework; PyQT redistribution policy states that if an user can
get in touch with PyQT directly it should have a commercial license itself;
how does this apply to those who want to develop commercial PyQT
applications with a plugin/scripting framework?

Thanks,
Fabio

Fabio wrote:

> I'm about to write an application, and I'd like to use PyQt, but before
> choosing this toolkit I would like to clarify some particular licensing
> issues; if some user has already touched these, I would like to hear from
> his experiences.
>
> This app should be cross-platform, so, given qt licensing policies, I woul
d
> buy a commercial PyQt license and a commercial Qt license.
>
> Could I license the application under the GPL for Gnu/Linux and under a
> commercial license for Windows and Mac OS X? If this is possible, I guess
> that contributions to the GPLed version could not be incorporated in the
> commercial version, but this would not be a big problem.

Right.

> The main issue with licensing is that I would like to give users of the
> application a scripting framework (for macros and the like), and eventuall
y
> a plugin framework; PyQT redistribution policy states that if an user can
> get in touch with PyQT directly it should have a commercial license itself
;
> how does this apply to those who want to develop commercial PyQT
> applications with a plugin/scripting framework?

This is vague, what one considers "get in touch"? If you perform any
calculations and display results to the user, would it be "get in touch
with PyQt"? I think not. If showing a window depends on your user's
scripting code, then I thing it's "get in touch", but if you simply show
a window with display widget (more or less advanced, be it QTextView or
even sort of grid) with results, this doesn't cover the case, as PyQt is
only used for display purposes -- just as with any other use of PyQt.

--
Jarek Zgoda
http://jpa.berlios.de/ | http://www.zgodowie.org/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

PyQt on OS X is also available under a GPL version. I have a binary
installer available at http://www.wordtech-software.com/pyqt-mac.html



Fabio wrote:

| Hi all,
| I'm about to write an application, and I'd like to use PyQt, but before
| choosing this toolkit I would like to clarify some particular licensing
| issues; if some user has already touched these, I would like to hear from
| his experiences.
|
| This app should be cross-platform, so, given qt licensing policies, I
would
| buy a commercial PyQt license and a commercial Qt license.
|
| Could I license the application under the GPL for Gnu/Linux and under a
| commercial license for Windows and Mac OS X? If this is possible, I guess
| that contributions to the GPLed version could not be incorporated in the
| commercial version, but this would not be a big problem.
|
| The main issue with licensing is that I would like to give users of the
| application a scripting framework (for macros and the like), and
eventually
| a plugin framework; PyQT redistribution policy states that if an user can
| get in touch with PyQT directly it should have a commercial license
itself;
| how does this apply to those who want to develop commercial PyQT
| applications with a plugin/scripting framework?
|
| Thanks,
| Fabio

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

 iD8DBQFBsO2QJmdQs+6YVcoRAmv5AKCClM58N6Eg
MVUkaVrp5gWzALxuCwCeI+Gt
5+gXRwfjtSPiu4DEnF5j86Q=
=WkvR
-----END PGP SIGNATURE-----

On Friday 03 December 2004 2:50 pm, Fabio wrote:
> Hi all,
> I'm about to write an application, and I'd like to use PyQt, but before
> choosing this toolkit I would like to clarify some particular licensing
> issues; if some user has already touched these, I would like to hear from
> his experiences.
>
> This app should be cross-platform, so, given qt licensing policies, I woul
d
> buy a commercial PyQt license and a commercial Qt license.
>
> Could I license the application under the GPL for Gnu/Linux and under a
> commercial license for Windows and Mac OS X?

As there is are GPL versions of Qt and PyQt for Mac OS X, it's only Windows
you need to handle differently.

> If this is possible, I guess
> that contributions to the GPLed version could not be incorporated in the
> commercial version, but this would not be a big problem.

"Minor" contributions you don't need to worry about. I think that the GPL FA
Q
covers what is considered "minor". For significant contributions you would
need to get the agreement of the contributors beforehand. Some projects stat
e
that contributions will only be accepted if the copyright of those
contributions are transferred to the main project author.

> The main issue with licensing is that I would like to give users of the
> application a scripting framework (for macros and the like), and eventuall
y
> a plugin framework; PyQT redistribution policy states that if an user can
> get in touch with PyQT directly it should have a commercial license itself
;
> how does this apply to those who want to develop commercial PyQT
> applications with a plugin/scripting framework?

The key is access to the Qt API. If your applications gives the users access
to the API then those users are developers and need their own licenses. On
the other hand if the API is sufficiently removed from the Qt API then you
shouldn't have a problem. Your API should restrict itself to extending the
capabilities of your application - the more general purpose you make it, the
more you risk a visit from the lawyers.

Phil

On Fri, 3 Dec 2004, Phil Thompson wrote:
...
> The key is access to the Qt API. If your applications gives the users acce
ss
> to the API then those users are developers and need their own licenses. On
> the other hand if the API is sufficiently removed from the Qt API then you
> shouldn't have a problem. Your API should restrict itself to extending the
> capabilities of your application - the more general purpose you make it, t
he
> more you risk a visit from the lawyers.

What about, for example, a XUL processor? Suppose I wanted to rewrite
Mozilla's front end to us Qt, I'd clearly need to implement a XUL
processor. Obviously such a thing is possible to do with PyQT as well.
Would I be able to do such a thing with a standard windows license for Qt
and PyQt? Everything I've read suggests that this would not be possible.

Users wouldn't have direct access to the Qt API, but they may have access
to the aspects Qt system, assuming a XUL type system, including the
ability to create new applications with new user interfaces (as one can
using Mozilla, XUL and Javascript).

ie one could envisage writing a wrapper around every part of the Qt API,
and then expose that as an API - is that breaking the rules? I'd assume
yes. Suppose then I simply change this to an XML processor (say a
tokenising on)that when it gets a directive it simply calls the Qt API,
and allow a user to change things in a config file. Is that too far? To me
they seem equivalent.

I don't tend to use windows much, if ever, and wouldn't want to do this at
present. However, it's fairly close to something I would like to do under
Linux (where this isn't a problem obviously), fairly close to the wind
having read the commercial licenses I could see and it just concerns me
that if I ever wanted to port such a system to windows I could get
extremely stung (Suppose I was redistributing an executeable).

It's a hypothetical question at present, due to using Linux, but it's
(realistically) possible at some point it may become less hypothetical.

Regards,


Michael.

On Saturday 04 December 2004 10:30 am, Michael Sparks wrote:
> On Fri, 3 Dec 2004, Phil Thompson wrote:
> ...
> 
>
> What about, for example, a XUL processor? Suppose I wanted to rewrite
> Mozilla's front end to us Qt, I'd clearly need to implement a XUL
> processor. Obviously such a thing is possible to do with PyQT as well.
> Would I be able to do such a thing with a standard windows license for Qt
> and PyQt? Everything I've read suggests that this would not be possible.
>
> Users wouldn't have direct access to the Qt API, but they may have access
> to the aspects Qt system, assuming a XUL type system, including the
> ability to create new applications with new user interfaces (as one can
> using Mozilla, XUL and Javascript).
>
> ie one could envisage writing a wrapper around every part of the Qt API,
> and then expose that as an API - is that breaking the rules? I'd assume
> yes. Suppose then I simply change this to an XML processor (say a
> tokenising on)that when it gets a directive it simply calls the Qt API,
> and allow a user to change things in a config file. Is that too far? To me
> they seem equivalent.
>
> I don't tend to use windows much, if ever, and wouldn't want to do this at
> present. However, it's fairly close to something I would like to do under
> Linux (where this isn't a problem obviously), fairly close to the wind
> having read the commercial licenses I could see and it just concerns me
> that if I ever wanted to port such a system to windows I could get
> extremely stung (Suppose I was redistributing an executeable).
>
> It's a hypothetical question at present, due to using Linux, but it's
> (realistically) possible at some point it may become less hypothetical.

At this point I would take the coward's way out and say "ask Trolltech". As 
a
matter of course I follow their model for PyQt (ie. if they are happy/unhapp
y
then I'm happy/unhappy).

I suspect that you are right. Borland had to come to a special arrangement f
or
Kylix - it wasn't just a case of buying a Qt license for each of their
developers.

Phil