PySide - LGPL binding Qt pro Python (diskuse)

[xm]

Btw. Nokia se původně snažila s Riverbank Computing (firma co stojí za PyQt) vyjednávat, ale k žádné dohodě nakonec nedošlo. Proto vznikl PySide.

A vhledem k tomuhle:

Nokia will provide multiple developers working on the project, but contributions will be encouraged and the contributors need not transfer their copyright or accept a code reuse license;

si troufám tvrdit, že Riverbanku odzvonilo. Jejich uzavřený vývojový model PyQt a prodej komerčních licencí nemá proti zcela otevřenému komunitnímu vývoji (navíc s placenými vývojáři od Nokie) žádnou šanci.

[xkucf03]

Takže se můžeme těšit na skvělé proprietární aplikace.

[cezz]

 

Takže se můžeme těšit na skvělé proprietární aplikace.

V pythone?

 

[Ilfirin]

To je problém

[Jakub Lucký]

call me "bytecode"

[Jardík]

Proč ne, python skripty lze kompilovat ...

[cezz]

Ja netvrdim, ze nie, ale ze to nezvykne byt bezna prax.. (AFAIK)

[Jakub Lucký]

imho bude aspoň do nějaké míry, alespoň na Windows, když už existuje py2exe...

[cezz]

Nefunguje py2exe náhodou tak, že jednoducho zbalí do jednej binárky python interpreter aj s kódom samotným? Existuje vlastne rozumný spôsob tvorby uzavretých aplikácií v pythone? Niečo ako Zend? Ja som nič použiteľné nenašiel.. (nieže by som to potreboval, len mi napadlo..)

[Jardík]

http://effbot.org/zone/python-compile.htm

Kompilace do bytecode (pyc) by mohla stačit pro uzavřené aplikace. V javě taky máte bytecode (class), v .NET ho máte taky (exe/dll). Dekompilovat to jde vždy všechno, i když zkompilujete třeba c program.

[Jakub Lucký]

aha, máte pravdu, py2exe to přibalí a nekompiluje, takže by z toho teoreticky měli jít vyloupnout zdrojáky...

Ale určitě python-compile do .pyc vytvoří slušný bytecode, který by měl stačit...

[xm]

Zdrojové kódy pythonu jsou automaticky za běhu překládány do bytecodu (vznikají tak soubory .pyc) a až ten se interpretuje. .pyc soubor pak samozřejmě funguje i bez jeho .py předlohy, je to tedy obdoba binárky. Je to trochu podobné jako třeba u Javy.

[Ilfirin]

Problém ale je, že decompyle je víc než úspěšný.

[Jardík]

Minimálně .NET a určitě i javu jde taky sluště dekompilovat to původní podoby.

[xm]

Lepší je unpyc, nástupce decompyle co podporuje Python 2.5 a 2.6 Každopádně tohle platí i pro Javu, Flash, .Net a další jazyky co používají bytecode, nejen pro Python. A přitom se podívej jak jsou proprietární Java aplikace rozšířené

[xm]

Doporučuju podívat se třeba právě na nějaký z početného množství Java decompilerů. Výsledky jsou překvapivě velmi blízké původnímu zdrojovému kódu, podobně jako u decompyle/unpyc.

[Ilfirin]

To že na tom ostatní také nejsou nejlépe situaci moc nezlepšuje. Ale dobrá tedy (právě decompyle s korektními proměnnými, docstringy a formátováním mě docela vyděsilo). Ovšem myslím, že v tomhle směru by bylo třeba s tím něco udělat.

[Ladicek]

g python obfuscator

Nevím teda, jak fungují obfuskátory Pythonu, v Javě jde bezpečně měnit názvy balíků, tříd, metod i proměnných, což úplně stačí, a AFAIK se dělají i bezpečné úpravy bajtkódu (typicky změna pořadí instrukcí beze změny chování), které dekompilátor zmatou.

[Ilfirin]

Děkuji velice, o tomhle jsem neměl ani tucha.

[xm]

Jediné "řešení" je obfuskace kódu. Což je ovšem strašná prasárna, něco takového opravdu neuznávám a nepodporuji. Já v tom že jde bytekód relativně lehce dekompilovat žádný problém nevidím. Vlastně jsem i rád že tomu tak je, nejsem zastáncem closed source aplikací

Pokud je tvůj program tak "hodnotný", že se obáváš aby z něj konkurence něco nezkopírovala, stejně ti nepomůže ani svěcená voda - není problém disasemblovat i strojový kód, rozluštit obfuskovaný kód, atp. Sice je to náročnější, ale pokud je tvůj program opravdu tak "hodnotný", že se něčím takovým vubec chceš zabývat (pokud nejsi tedy jen chronický control-freak), tak to bude za to stát i tvé konkurenci a buď si jistý že je to moc nezbrzdí :-P

[xkucf03]

Jo, jenže fakt, že aplikace jde dekompilovat, je něco jiného, než kdyby to byl opensource. Navíc autor může použít obfuskaci.

[xm]

Já osobně bych také preferoval GPL řešení, nicméně jeho vývoj musí být otevřený, to je nesmírně důležité. A to vývoj PyQt nebyl, děl se prakticky za zavřenými dveřmi (až na veřejný mailing-list) a k automatickému generování bindingů firma Riverbank používala vlastní proprietární program. Takže byť výsledné řešení bylo GPL, o otevřenosti (z hlediska vývoje) se mluvit moc nedalo. Forknutelné PyQt prakticky také nebylo (díky uzavřenosti toho nástroje na generování bindingů).

A faktem také je, že tohle prostě po přechodu Qt na LGPL přijít muselo. GPL binding nad LGPL knihovnou je IMHO dlouhodobě neudržitelný, dříve či později vznikne LGPL alternativa.

[xm]

Jen aby nedošlo k mýlce, tím proprietárním generátorem bindingů samozřejmě nemám na mysli SIP, ale to co používali interně (jestli se nepletu nad ním postavené).

[Andrtalec]

Pekné malé zadosťučineníčko:
"Due to practical reasons, the initial development efforts have been focused on Linux, but the team hopes people to join in porting the code to other platforms and to further develop the bindings and tools."

[Michal Ludvig]

Jestlipak to konecne bude fungovat primo na Framebufferu bez xorg? Qt samotne to umi, ale PyQt pokud vim ne.