文章转载自 大象笔记
今天在 Python-CN 邮件组里看到讨论 PyQt 和 Nokia PySide 的问题。
PyQt 是商业及 GPL 的版权， 而 PySide 是 LGPL.
也就是如果使用 PyQt 做商业应用的话就需要付费， 而使用 Nokia 的 PySide 则不需要。
题外话:
自从 Nokia 收购了 Qt， 一直大力推广 Qt。前天发布的最新的 PySide 已经支持 MS Windows,
而且是 LGPL 的。
相信 PySide 未来会比 PyQt 更强大易用。按照 Nokia 的说法是会更加 Pythonic。
PySide is an open source sofware project providing Python bindings for the Qt framework. Qt is a cross-platform application and UI framework, allowing the developers to write applications once and deploy them across many operating systems without rewriting the source code, while Python is a modern, dynamic programming language with a vivid developer community.
Combining the power of Qt and Python, PySide provides the wealth of Qt framework for developers writing software in Python and presents a first-class rapid application development platform purported to be available on all major operating systems.
// 以下为在网上搜索的结果
LGPL概念
LGPL 是 GNU Lesser General Public License (GNU 宽通用公共许可证)的缩写形式,旧称 GNULibrary General Public License (GNU 库通用公共许可证),在宽松程度上与 BSD, Apache,XFree86 许可证相似。
GPL(General Public License)和LGPL( Lesser General Public License)是GNU的两种License。越来越多的自由软件(Free Software)使用GPL作为其授权声明，如果对GPL一点都不了解，有可能在使用自由软件时违反了GPL的授权。如果是个人或不正规的公司倒也无所谓，但如果是有规模的公司，恐怕会有被起诉的风险。
在使用Log4cpp时我想到了授权的事情，于是有了兴趣对GPL做一下了解。这是必要的，因为公司也维护了一个验证过的自由软件库，里面包含的自由软件除了功能上是可靠的，另外就是一定可以被私有使用的，否则后果很严重。
Log4cpp最初的版本使用GPL作为授权声明的，在0.2.1版本以后改用更为宽松的 LGPL。LGPL最初是Library GPL的缩写，后来改称作Lesser GPL，即为更宽松的GPL。当一个自由软件使用GPL声明时，该软件的使用者有权重新发布、修改该软件，并得到该软件的源代码；但只要使用者在其程序中使用了该自由软件，或者是使用修改后的软件，那么使用者的程序也必须公布其源代码，同时允许别人发布、修改。也就是说，使用GPL声明下的的自由软件开发出来的新软件也一定是自由软件。
LGPL是GPL的变种，也是GNU为了得到更多的甚至是商用软件开发商的支持而提出的。与 GPL的最大不同是，可以私有使用LGPL授权的自由软件，开发出来的新软件可以是私有的而不需要是自由软件。所以任何公司在使用自由软件之前应该保证在 LGPL或其它GPL变种的授权下。
编辑本段
Richard Stallman关于GPL和LGPL的论述
为什么你不应该使用LGPL发布你的下一个库
GNU计划在使用库时有两个首要的许可证.一个是GNU LGPL(库GPL);另一个是普通的GNU GPL.选择不同的许可有很大的不同:选择LGPL允许在私有程序中使用该库;选择普通的GPL则只允许在自由软件中使用它.
关于哪一种许可证对指定的库是最好的这一问题实际上是一个策略问题,它取决于实际情况.当前,大多数的GNU库被采用LGPL,这意味着我们只使用着其中的一个策略,而忽略了另一个. 所以现在我们在寻求更多以普通的GPL许可证形式发布的库.
私有软件开发者有金钱上的优势;自由软件开发者需要相互之间利用各自的优势.对一个库采用普通的GPL对自由软件开发者的优势要大于对私有软件开发者: 他们可以使用的库对于私有软件开发者是不可利用的.
使用普通的GPL并不是对于所有的库都有好处.在某些情况下更有理由来使用LGPL.最常见的情况就是当一个自由库的特性可以很容易地被私有软件以其他可替代库来实现.在这种情况下,库不能给与自由软件任何特别的优势,因而最好还是为LGPL发布该库.
这也就是为什么我们为GNU C 库选择LGPL.总之,有很多的其他C库；我们使用GPL发布该库,将迫使私有软件开发者不得不使用其它的库--对他们来说这不成问题,而我们则有了麻烦.
然而,当一个库所提供的功能是非常独特的时候,如GNU Readline, 情况就大不一样了. Readline库可实现输入编辑和记录交互式程序操作,这在别处通常是不可多得. 在GPL下发布它并限制它只能在自由程序中使用, 这我们的社团是一个重要的促进.至少今天某个应用程序之所以是自由软件，只是因为它必需要用到Readline.
如果我们收集一些强大的、私有软件中没有相类似东西的、采用GPL的库,它们将提供一系列有用的模块用于新的自由软件的构造. 这对于将来的自由软件开发将是一个显著的优势, 一些项目将为了使用这些库而考虑使软件自由化. 大学的项目是易于被影响的；而且今天，随着某些公司开始考虑使软件自由化, 甚至一些商业项目也会由此受到影响.
私有软件开发者试图否认自由竞争的重要性, 他们会拼命说服作者不要将库使用GPL来发布. 例如,他们会呼吁利己主义,信誓旦旦地说如果我们让他们在私有软件产品中使用代码，将有“更多的用户”用到该库. 流行是一种诱惑,它使一个库开发者倾向于相信这种观点：社会首先需要的是促进一种库的流行;.
但是我们不应该听从这种诱惑,因为如果我们联合起来,我们可以做得更好.我们这些自由软件开发者应该相互支持. 通过发布只能为自由软件使用的库,我们可以互相帮助，使彼此的自由软件包优于其它的私有替代品. 整个自由软件运动将会有更多的机会,因为自由软件作为一个整体将会在竞争中表现更佳.
因为"LGPL(Library GPL)"的称呼传达了关于这一问题的错误观点,我们计划将称呼改为"次级GPL(Lesser GPL)".事实上要更换名称要花一定的时间,但你不必再等--你可以现在就发布应用GPL许可证的库.