PyQT Licensing and plugins/scripting

Michael Sparks zathras at
Sat Dec 4 11:30:00 CET 2004

On Fri, 3 Dec 2004, Phil Thompson wrote:
> 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.

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.



More information about the Python-list mailing list