[PyKDE] Fwd: Re: [Issue N6078] allowed distribution methods

[Greg Fortune]

On Thursday 19 September 2002 10:28 am, Phil Thompson wrote:
> On Thursday 19 September 2002 5:41 pm, Greg Fortune wrote:
> > In reference to the discussion going on right now about licensing... 
> > Yes, the qt dll can be distributed.  Thus, PyQt can be distrubuted
> > allowing that you are not using the new commercial version of PyQt.  The
> > end user, of course, would not be allowed to use qt in a development
> > fashion such as fixing bugs in your application.  I think this means that
> > if you develop an PyQt application that is meant to be run on windows,
> > you can *not* license it under the GPL because the GPL requires that
> > modification to the source is allowed, at least in my understanding. 
> > That kinda sucks in a big way... GPL apps for windows cannot be developed
> > with Qt.  And yes, Trolltech's license is in the way here, but Phil's
> > license is not helping things out...
> >
> > From the GPL, "You may modify your copy or copies of the Program or any
> > portion of it, thus forming a work based on the Program, and copy and
> > distribute such modifications or work under the terms of Section 1 above,
> > provided that you also meet all of these conditions: "
> >
> > Anyone want to make me really happy and point out where I'm wrong?
> >
> > btw, trolltech, I would certainly like to hear the official stance on
> > developing GPL applications in Qt in Windows.  It appears that even
> > though I've paid a chunk of money so I can develop commercial
> > Windows/Linux applications with Qt, I cannot license anything under the
> > GPL if I use Python/PyQt in any fashion (because it's crossplatform
> > itself and would be expected to run on Windows) and cannot develop *any*
> > Qt application for Windows that would be licensed under the GPL.
>
> This is from memory, but it's the GPL that prevents you from developing GPL
> applications with Qt on Windows. A GPL application cannot be linked against
> closed source libraries that don't come with the machine. This excludes
> commercial Qt on Windows but includes commercial Qt on the Zaurus.
>
> > Does this mean that PyQt previous to the new license Phil implemented was
> > violating the Qt license agreement.  Of course, this is a little silly,
> > but all the implications are in place...
>
> The previous PyQt license was based on the X11 license which doesn't impose
> the restrictions that the GPL does.

Which makes the conversation even more intersting.  The X11 license does not 
require I release my source, right?  So I could still develop an application 
in Python with PyQt and release pyc files or something.  Regardless, I must 
distribute pyqt in addition to my application so any end user instantly has 
the ability to develop Qt applications in Windows without obtaining a 
license.  This isn't an issue with the qt dll because I think you still need 
to headers to be able to compile an application.

So does the PyQt license need to explicitly state that the user can never 
ever open up an interactive python interpreter and type "import qt" ????  Or 
develop a python application that uses the PyQt library?

Furthermore, let's say that all was a moot point because the license takes 
care of it...  Consider a commerical application that distributes only the 
.pyc files (ie, as close to "compiled" as you can really get for Python)

import some_module #some pyc module distributed as part of my app
some_module.some_var = 'some value'
#some_var just happens to be a qt widget or a flag for manipulating a widget 
or etc....
import the_main_module #some pyc module that launches the app

So just like that, they've made modifications on the fly to my app which is 
written in a dynamic, interpreted language.


And what about a line that allowed users to execute arbitrary python (through 
exec() or eval()) on my PyQt program?  Am I obligated to insure that they 
don't execute any code that could control Qt in any way?  Or am I obligated 
to include something in my license that says "While it's possible for you to 
be a bad person, please don't."


I think the possibilities here are pretty endless, so the question is what am 
I resposibile for when developing applications using Python and Qt with 
regards to licensing?  I've got an application that I'm developing using a 
commercial license of Qt and need to know my obligations.  I clearly didn't 
understand or consider all the nuances before today.



>
> > Has trolltech considered developing
> > wrappers for languages other than C++ so we don't have to play these
> > games. I suggest you take a look at Smoke, a recent addition to KDE. 
> > Maybe something similar could be developed by Trolltech in house.
>
> I haven't looked at SMOKE but from what I've read I don't see how it can
> produce good quality bindings - at least for Python, maybe Perl doesn't
> have the same issues. As I understand it SMOKE means you can use the
> original C++ header files rather than having to maintain separate .sip-like
> files. The problem is that there is extra information that you need to
> specify somewhere (at least for Python bindings) to handle (for example)
> object ownership and threading.

I haven't looked at it closely either and your thoughts might be right on 
target.  Regardless, it would nice if Trolltech where to take responsibility 
for wrappers to popular languages in addition to C++.  C++, C#, Java, Python, 
Perl, and perhaps Ruby all strike me heavily used languages that would 
benifit from a Trolltech produced binding.  

In particular, it would resolve licensing issues with interpreted languages 
(ie, Trolltech would explicitly states the terms of the license as it applies 
to interpreted languages) and would also give me an upfront cost for 
developing applications in Python with Qt.  I'm going to be stuck with a pre 
commercial version of PyQt on my current project because I did not budget in 
the additional license cost of the newer PyQt versions.  Of course, from now 
on, I know to budget in the cost of a commercial PyQt license as well if I 
want an updated version.

Greg

>
> Phil
>
> _______________________________________________
> PyKDE mailing list    PyKDE at mats.gmd.de
> http://mats.gmd.de/mailman/listinfo/pykde