[PyKDE] Deployment on Windows? > license compatible

[Ulrich Berning]

Michael Zimmermann schrieb:

> Well, after a bit of trial and error I understand the bit about 
> building a signed interpreter (Actually, this is working as I want it 
> to work).
>
> Currently I use my default installation that has QT and PyQT 
> installed. With this setup anyone would be able to use the existing 
> libraries with a generic python interpreter and bypass our signed 
> interpreter. Not good.
>
> What I think about doing is:
> - Compile the pyQT modules statically into python

Why do you want to do that? By protecting PyQt from beeing used by a 
generic interpreter, there is no need to build PyQt statically linked 
into Python.
Just distribute the protected PyQt dynamic loadable modules together 
with your application. I can't see any advantanges with a statically 
linked PyQt. You end up with huge executables, containing builtin 
modules that your applications may never use (e.g. qttable, qtxml, qtsql 
...).

> - Generate a singed interpreter for our applicaton
> - Distribute the signed interpreter + any additional scripts + the 
> python libs (including pyQT)
>
>
> But here are the questions:
>
> How about QT?
> Imho I do need a QT library before I can build pyQT. Then, is it 
> necessary to patch the code of QT to make it VendorId-aware? If so, 
> where? Or how should I deploy the QT libs?
>
No. Qt has nothing to do with VendorID.

The VendorID code is a kind of contract between signed python 
interpreters and protected extension modules (not only releated to PyQt):
"Tell me (the module) who you (the interpreter) are, and if I can accept 
you, I will allow you to use me."

There is no need to do anything with Qt. Just distribute the shared Qt 
library you have built together with your application and the protected 
PyQt modules.

> How about PyQT?
> Is it enough if I configure  PyQT with the -i command line switch to 
> make it vendorId aware?
>
Yes. The -i command line switch is enough to protect PyQt from beeing 
used by a generic interpreter.

Note, that there is no need to build two versions of PyQt (protected and 
unprotected), you only need to build a protected PyQt with -i. Because 
the VendorID package creates the dynamic loadable module vendorid.pyd, 
you and only you can use your PyQt modules with the generic interpreter. 
The signed interpreter and qt.pyd are linked with the static library 
vendorid.lib. If you do not distribute vendorid.pyd and vendorid.lib 
(you should never do this), nobody else can use your PyQt with a generic 
interpreter or can create a new signed interpreter.

> Once again our objective is not to make a self-contained .exe but 
> rather a solution, that leaves some of our code exposed to 
> modifcations ....
>
When using SIB, you decide which modules/packages should be frozen into 
the executable and which modules/packages should be left external. At 
minimum, you only freeze the applications main script, at maximum, you 
put all modules/packages of your application into the resulting 
executable. When you put only your main script into the executable, you 
should by sure, that this script contains a reasonable amount of 
application specific code. Something like "import foo; foo.run()" is 
definitely too generic, because someone could replace your foo.py with a 
completey different foo.py starting application development with your 
signed interpreter.

Note, that you can still use py2exe, to build a self containing 
application package with all dependent modules and libraries. You just 
have to replace the executable created by py2exe with an executable 
created by SIB.

If you think, it would be a good idea to modify py2exe or cx_Freeze to 
create signed interpreters for you: forget it. Both tools rely on 
prebuilt generic script starter executables and attach the applications 
main script to this executable using various techniques. Everybody can 
replace the attached main script with another one using the same 
technique. You definitely need a compile/link cycle.

---

If you think, you miss something in the documentation of VendorID (I'm 
sure you have read the docs at least twice :-) ), please let me know.

Ulli