许可协议

atomoptics

浏览: 92193 次
性别:
来自: 武汉

最近访客更多访客>>

u012363178

影子yingzi

freedombless

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

Qt PHP Linux FreeBSD MySQL

QT老家的说明</a> Guide to Qtopia licensing: Are you creating a Qtopia-based mobile device? The Qtopia commercial OEM license permits OEMs, ODMs, and system integrators build and sell Qtopia devices. The commercial OEM license includes provisions for runtime licensing. For more information, contact <a href="mailto:sales@trolltech.com">sales@trolltech.com</a>. Interested in putting Qtopia on a reference board/platform? The Qtopia reference board license provides hardware manufacturers with the tools needed to get Qtopia running on a reference board. For more information, contact <a href="mailto:sales@trolltech.com">sales@trolltech.com</a>. Developing commercial applications for Qtopia-based devices? The Commercial development SDK license enables developers to build commercial Qtopia applications for sale or free distribution. Commercial development SDK license holders are not required to pay runtime license fees. Developing applications to be licensed under the GPL? The Qtopia GPL SDK development license is <a href="http://www.trolltech.com/download/qtopia/index.html">free to download</a> and use, provided applications are developed and released under the terms of the GNU GPL. Restrictions You may not distribute the Qtopia Libraries or applications in any form without runtime licenses. You may not use the Qtopia GPL SDK Development License to build non-GPL software. All GPL Qtopia applications are governed by all of the terms of the GPL. <a href="http://www.trolltech.com/products/qt/opensource.html">qt的</a>： Qt Open Source Edition Licensing The Qt Open Source Editions contain the same code as our Commercial Editions, but are governed by licensing terms that are entirely different. The Qt Open Source Edition is available under two open-source licenses: the GPL (GNU Public License), and the QPL (Q Public License). Both these licenses are suitable for the development of Open Source Software for Linux, Unix, and Mac OS X. The Qt Open Source Editions may be freely copied and distributed, put on FTP sites and CD-ROMs, etc., under the same open-source licenses that they are supplied with. This is completely different from the Qt Commercial Editions which cannot be distributed at all. Please note the following: We provide the Qt Open Source Editions with no warranty and no support Based on the "Quid Pro Quo" principle, if you wish to derive a commercial advantage by not releasing your application under an open source license, you must purchase an appropriate number of commercial licenses from Trolltech. By purchasing commercial licenses, you are no longer obliged to publish your source code. If you wish to use a Qt Open Source Edition, you must contribute all your source code to the open source community in accordance with the GPL or the QPL's license terms. If you are unsure about Trolltech's licensing, we recommend that you contact sales@trolltech.com. 大致就是你开源，我就开源，你收费，我就收费，和<a href="http://www.minigui.org/">minigui</a>差不多。 1. 如果您 100% 遵循 GPL，无需获得商业授权 如果您使用 MiniGUI 的应用程序以 GPL 发布，则无需获得我们的商业授权。我们非常欢迎任何人在遵循 GPL 条款的基础上复制、修改和发布 MiniGUI。在这种情况下，您无需获得飞漫软件的任何形式的（包括口头或书面）使用授权，因为 GPL 条款本身就足够确保您的权益。但需要注意的是，飞漫软件不对这种形式下的使用提供任何形式的担保或技术支持。 2. 如果您从不复制、修改和发布 MiniGUI，无需获得商业授权 只要您从不复制、修改和发布 MiniGUI，则您可以在您的应用程序中使用 MiniGUI，而无需获得商业授权。举个例子，您在完成一篇学位论文，并因此在您的程序中使用了 MiniGUI，您的程序仅仅用来说明您论文中试验的可行性或者结果，而且您没有修改 MiniGUI，并且该程序不以任何方式被复制和发布，则您无需获得商业授权。飞漫软件也不对这种形式下的使用提供任何担保。 但需要特别指出： <ul> <li> 修改。我们欢迎您对 MiniGUI 进行任意的修改。如果你发布该修改版本，则您对 MiniGUI 所做的任何修改、所有的接口代码以及直接和间接地与接口相关联的代码将遵循 GPL 许可证。 </li> <li> 复制。我们允许您复制 MiniGUI 二进制代码和/或源代码，但一旦这么做了，所有的副本应遵循 GPL 许可证。 </li> </ul> 3. 其他情况均需获得商业授权 如果您使用 MiniGUI 的应用程序并不以 GPL 条款发布，却打算在内部或外部发布使用 MiniGUI 的应用程序或者函数库，则您必须首先获得飞漫软件的商业授权。 特别是： <ul> <li> 您的非 GPL 应用程序连接了 MiniGUI，不管静态还是动态连接，您需要为每一个 MiniGUI 函数库副本购买商业授权。 </li> <li> 如果您在自己的单位使用 MiniGUI 函数库，但又不希望将其置于 GPL 许可证之下，则需要购买商业授权。 </li> <li> 当然，更多的人购买 MiniGUI 的商业授权，其目的非常简单，他们希望获得来自飞漫软件的技术支持和软件质量担保。 </li> </ul> <hr /> 另外wiki百科上有编关于许可协议比较的文章：<a href="http://zh.wikibooks.org/wiki/%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8">http://zh.wikibooks.org/wi...</a> 各种许可协议探讨 Wikipedia，自由的百科全书  <table border="0"> <tbody> <tr> <td align="center"> 目录 [<a href="toggleToc()">显示隐藏</a>] </td> </tr> <tr> <td> <div> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#.E4.B8.8B.E9.9D.A2.E6.98.AF.E6.88.91.E7.9C.8B.E8.BF.87GPL.E8.AE.B8.E5.8F.AF.E8.AF.81.E5.90.8E.E7.9A.84.E5.87.A0.E7.82.B9.E7.9C.8B.E6.B3.95"> 1 GPL许可证研究和扩展 1.1 下面是我看过GPL许可证后的几点看法</a> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#.E5.85.B3.E4.BA.8E.E8.BD.AF.E4.BB.B6.E7.9A.84.E4.BF.AE.E6.94.B9.E6.9D.83.E6.88.91.E8.AE.A4.E4.B8.BA.E4.B8.8B.E9.9D.A2.E7.9A.84.E8.AF.B4.E6.B3.95.E6.98.AF.E6.AF.94.E8.BE.83.E5.85.A8.E9.9D.A2.E7.9A.84">1.2 关于软件的修改权我认为下面的说法是比较全面的</a> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#.E8.BF.99.E4.B8.AAGPL.E6.9D.A1.E6.AC.BE.E6.98.AF.E5.85.B3.E4.BA.8E.E5.8E.9F.E5.A7.8B.E4.BD.9C.E8.80.85.E6.9D.83.E5.88.A9.E9.83.A8.E5.88.86">1.3 这个GPL条款是关于原始作者权利部分</a> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#.E6.88.91.E7.9A.84.E5.85.B3.E4.BA.8E.E4.BD.9C.E8.80.85.E6.9D.83.E5.88.A9.E7.9A.84.E6.83.B3.E6.B3.95">1.4 我的关于作者权利的想法</a> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#.E5.85.B3.E4.BA.8EGPL.E5.85.BC.E5.AE.B9.E8.AE.B8.E5.8F.AF.E7.9A.84.E9.97.AE.E9.A2.98">1.5 关于GPL兼容许可的问题</a> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#.E5.BC.95.E4.BC.B8">1.6 引伸</a> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#.E5.85.B3.E4.BA.8E.E5.90.84.E7.A7.8D.E5.BC.80.E6.94.BE.E6.BA.90.E4.BB.A3.E7.A0.81.E8.AE.B8.E5.8F.AF.E8.AE.A8.E8.AE.BA">1.6.1 关于各种开放源代码许可讨论</a> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#.E5.85.B3.E4.BA.8E.E5.BC.80.E6.94.BE.E6.BA.90.E4.BB.A3.E7.A0.81.E7.9A.84.E5.95.86.E4.B8.9A.E6.A8.A1.E5.BC.8F">1.6.2 关于开放源代码的商业模式</a> </div> <div> <div> <div> <div> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#.E5.95.86.E4.B8.9A.E5.8C.96.E5.BC.80.E5.8F.91.E5.92.8C.E7.A4.BE.E5.8C.BA.E5.BC.80.E5.8F.91.E7.9A.84.E6.AF.94.E8.BE.83">2 BSD和GPL的比较 2.1 商业化开发和社区开发的比较</a> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#GPL.E9.97.AE.E7.AD.94">3 开放源代码软件授权盘点 4 建议尽量使用APL授权，不使用GPL授权 </a> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#GPL.E9.97.AE.E7.AD.94">5 GPL问答</a> </div> </div> </div> </div> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#.E5.90.84.E7.A7.8D.E5.BC.80.E6.BA.90.E8.BD.AF.E4.BB.B6.E6.8E.88.E6.9D.83.E6.96.B9.E5.BC.8F.E7.9A.84.E4.BB.8B.E7.BB.8D">6 各种开源软件授权方式的选择 6.1 各种开源软件授权方式的介绍</a> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#.E5.BC.80.E6.BA.90.E8.BD.AF.E4.BB.B6.E7.9A.84.E5.A5.BD.E5.A4.84">6.2 开源软件的好处</a> <div> <div> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#.E5.90.84.E7.A7.8D.E8.BD.AF.E4.BB.B6.E6.8E.88.E6.9D.83.E7.9A.84.E4.BC.98.E7.BC.BA.E7.82.B9.E5.8F.8A.E9.80.82.E7.94.A8.E8.8C.83.E5.9B.B4.E5.92.8C.E5.8F.98.E7.A7.8D.EF.BC.88.E5.A2.9E.E8.AE.A2.E7.89.88.EF.BC.89">7 关于GPL的一些话 7.1 各种软件授权的优缺点及适用范围和变种（增订版）</a> </div> </div> <div> <div> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#.E5.AF.B9GPL.E7.9A.84.E6.9C.80.E6.96.B0.E8.AE.A4.E8.AF.86">8 对GPL的最新认识</a> </div> </div> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#.E5.95.86.E4.B8.9A.E8.BD.AF.E4.BB.B6.E5.85.AC.E5.8F.B8.E5.AF.B9.E5.BC.80.E6.BA.90.E8.BD.AF.E4.BB.B6.E5.BA.94.E8.AF.A5.E9.87.87.E5.8F.96.E7.9A.84.E6.8E.AA.E6.96.BD">9 商业软件公司对开源软件应该采取的措施</a> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#GPL.E6.9D.A1.E6.AC.BE.E7.9A.84.E4.B8.80.E4.BA.9B.E6.BC.8F.E6.B4.9E">10 GPL条款的一些漏洞</a> <a href="http://zh.wikibooks.org/wiki/%C3%A5%C2%90%C2%84%C3%A7%C2%A7%C2%8D%C3%A8%C2%AE%C2%B8%C3%A5%C2%8F%C2%AF%C3%A5%C2%8D%C2%8F%C3%A8%C2%AE%C2%AE%C3%A6%C2%8E%C2%A2%C3%A8%C2%AE%C2%A8#.E8.B4.A1.E7.8C.AE">11 贡献</a> </td> </tr> </tbody> </table> <a name="GPL.E8.AE.B8.E5.8F.AF.E8.AF.81.E7.A0.94.E7.A9.B6.E5.92.8C.E6.89.A9.E5.B1.95"> </a> GPL许可证研究和扩展 GPL许可证是自由软件的应用最广泛的软件许可证。但是我最近看过GPL许可证内容后，却发现GPL许可证的条款有很多不明确的地方，因为它的发布时间已 经太久了，现在自由软件和开放源代码软件的发展规模已经比GPL许可证发布的时候大了很多，出现了大量的新问题。在GPL中都没有体现。GPL是不是该出 新版本了？（这样说可能有夸张的嫌疑，但这只是我的一个提议。） <div> [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=2" title="各种许可协议探讨">编辑</a><a name=".E4.B8.8B.E9.9D.A2.E6.98.AF.E6.88.91.E7.9C.8B.E8.BF.87GPL.E8.AE.B8.E5.8F.AF.E8.AF.81.E5.90.8E.E7.9A.84.E5.87.A0.E7.82.B9.E7.9C.8B.E6.B3.95"> </a> </div> 下面是我看过GPL许可证后的几点看法 这是GPL公共许可证的第二条，关于软件的修改权的条款： 2. 您可以修改程序的一个或几个副本或程序的任何部分，以此形成基于这些程序的衍生作品。只要您同时满足下面的所有条件，您就可以按前面第一款的要求复制和发 布这一经过修改的程序或作品。 您必须在修改过的档案中附有明显的说明：您修改了此一档案及任何修改的日期。 您必须让您发布或出版的作品，包括本程序的全部或一部分，或内含本程序的全部或部分所衍生的作品，允许第三方在此许可证条款下使用，并且不得因为此项授权 行为而收费。 如果修改的程序在执行时以交谈方式读取命令，您必须使它在开始进入一般的交谈使用方式时打印或显示声明：包括适当的版权声明和没有担保的声明(或者您提供 担保的声明)；使用者可以按此许可证条款重新发布程序的声明；并告诉使用者如何看到这一许可证的副本。 (例外的情况：如果原始程序以交谈方式工作，但它通常并不打印这样的声明，那么您基于此程序的作品也就不用打印声明)。 　这些要求适用于整个修改过的作品。如果能够确定作品的一部分并非本程序的衍生产品，且可以合理地单独考虑并将它与原作品分开的话，则当您将它作为独立的 作品发布时，它不受此许可证和其条款的约束。但是当您将这部分与基于本程序的作品一同发布时，则整个套件将受到本许可证条款约束，因为本许可证对于其他许 可证持有人的授权扩大到整个产品，也就是套件的每个部分，不管它是谁写的。 　因此，本条款的意图不在于剥夺您对完全由您自身完成作品的权利，而是履行权利来控制基于本程序的集体作品或衍生作品的发布。 　此外，将与本程序无关的作品和本程序 (或本程序的衍生作品) 一起放在贮存媒体或发布媒体的同一卷上，并不导致将其他作品置于此许可证的约束范围之内。 [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=3" title="各种许可协议探讨">编辑</a>] <a name=".E5.85.B3.E4.BA.8E.E8.BD.AF.E4.BB.B6.E7.9A.84.E4.BF.AE.E6.94.B9.E6.9D.83.E6.88.91.E8.AE.A4.E4.B8.BA.E4.B8.8B.E9.9D.A2.E7.9A.84.E8.AF.B4.E6.B3.95.E6.98.AF.E6.AF.94.E8.BE.83.E5.85.A8.E9.9D.A2.E7.9A.84"></a> 关于软件的修改权我认为下面的说法是比较全面的 你可以以下面的四种方式修改自由软件作品： 第一种方式：如果只是对原始程序进行局部修改，那么应该使修改以补丁文件的形式进行修改，以使修改和原始程序完全脱离。并且，有修改的说明文档，包括每项修改的说明和修改者的联系方法和修改时间。这样，首先当用户使用你的修改版软件出现问题时，可以明确地知道问题应该找原始程序作者还是修改者解决，以免原始程序作者为修改内容负责。另外，当原始程序升级时，也方便使用者同时使用修改内容和升级程序。并且，也方便修改者把修改代码和修改文档反馈给原始程序作者，以便融入原始程序中使修改内容被更多的人使用。建议尽量反馈给原始程序作者，但不是强迫的。 第二种方式：并不修改原始程序代码，但增加程序文件，使原始程序的功能得到增强和扩展。如增加更多的库函数，增加更多的软件功能模块。如果增加程序要和原始程序同时发行，那么，GPL许可应该应用于软件整体，这就是GPL许可中说明的同时发布的相关程序，只要其中有GPL许可程序，那么GPL许可扩大到全体相关程序。如果以这种形式修改，那么那么第一种方式的修改方法是适用的。 第三种方式：在自己创作的软件中引用GPL程序的代码，如果创作的软件也是GPL许可复盖的软件那么，这种引用是许可的，但要在版权说明中说明参考了那些程序的代码，并尽可能在程序源代码中注释出那些是引用的代码及引用代码的作者和联系方法。这种引用可以不用征得被引用代码作者得同意。 第四种方式：在原始程序的基础上进行修改并重新发布，那么修改内容可以不必和原始程序脱开，但也要有说明文档说明修改内容，原始程序的作者和联系方法，及修改的日期和作者。并且如果能够对原始程序有贡献，那么尽量通知原始程序作者，以便原始程序的作者也享受修改带来的好处。在这种情况下，修改者应该对用户发现的问题负全部责任，而不要麻烦原始程序作者解决。以这种方式修改的结果就是建立了一个原始程序的分支，以实现更自由的修改，但对于享受原始程序的升级的好处则带来了困难。这是修改者的很大的权利，即建立分支的权利。这样的选择适于不满意原程序发展方向和进度或满足特定需要的情况。由于这种方式引入了竞争，这要求补丁程序能够共享，任何人都有权获得和原始程序作者同样多的补丁程序的反馈的拷贝，这样才能避免补丁程序的浪费。可能被抛弃的补丁正是某些用户需要的。提倡开放的补丁的发布方式，更有利于软件的进步。 ====和GPL许可条款相比==== 我说的修改条款更详细规定了在不同的情况下，修改者应该采取的方式和必须承担的义务。比GPL的条款要详细很多，可以更明确地指导修改者的工作。比如第一 种方式，修改应该以补丁的方式修改，这种方式已经是现在开放源代码的惯例，对使用者和原始程序的升级都带来了极大的方便。应该属于强制执行的条款。又比 如，第三种方式的做法给了被引用代码作者更大的尊重，也明确了修改者究竟带来了多大的创新。第四种方式，也减少了原始程序作者的额外烦恼，并且带来了相互 竞争的软件发展模式，避免软件发展的独裁，多样化正是开放源代码的特色，另外，如果带来了开发接口不一致的情况，建立一个标准组织是一个更好的方法。竞争 才能带来更强大软件，就像html格式一样，给用户带来最大利益。另外，命令行的版权提示的强制要求没有道理。 [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=4" title="各种许可协议探讨">编辑</a>]<a name=".E8.BF.99.E4.B8.AAGPL.E6.9D.A1.E6.AC.BE.E6.98.AF.E5.85.B3.E4.BA.8E.E5.8E.9F.E5.A7.8B.E4.BD.9C.E8.80.85.E6.9D.83.E5.88.A9.E9.83.A8.E5.88.86"> </a> 这个GPL条款是关于原始作者权利部分 10. 如果您愿意将程序的一部分结合到其他自由程序中，而它们的发布条件不同，请写信给作者，要求准予使用。如果是自由软体基金会加以版权保护的软体，请写信给 自由软体基金会，我们有时会作为例外的情况处理。我们的决定受两个主要目标的指导，这两个主要目标是：我们的自由软体的衍生作品继续保持自由状态，以及从 整体上促进软体的共享和重复利用。 [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=5" title="各种许可协议探讨">编辑</a> <a name=".E6.88.91.E7.9A.84.E5.85.B3.E4.BA.8E.E4.BD.9C.E8.80.85.E6.9D.83.E5.88.A9.E7.9A.84.E6.83.B3.E6.B3.95"></a>我的关于作者权利的想法 GPL给了原始程序作者使用多个许可证的权利，这样可以保证作者的最大权利，但如果加上“不允许原始程序作者撤销或改变GPL许可”的语句，则这个表述更 严密。 另外，作者是否有权利将其他人的修改代码应用于其他许可是一个问题，因为这样带来了GPL程序代码泄漏的问题，如果修改者又引用了其他的GPL代码则带来 了更大的泄漏。我的建议是作为严格的GPL许可，应该禁止这种权利，这样才能维护GPL社区的整体利益。但这个权利可以被其他形式的许可采用。是不是现在 有人用这种方法进行GPL代码的泄漏？ [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=6" title="各种许可协议探讨">编辑</a>]<a name=".E5.85.B3.E4.BA.8EGPL.E5.85.BC.E5.AE.B9.E8.AE.B8.E5.8F.AF.E7.9A.84.E9.97.AE.E9.A2.98"> </a> 关于GPL兼容许可的问题 我看在<a href="http://www.gnu.org">www.gnu.org</a>的主页上有关于GPL兼容许可的论述。事实上应该没有GPL兼容许可的说法。GPL应该自由软件的唯一许可。更多或更少的限制条件的许可应该都没有权利引用GPL代码。LGPL除外，因为它只是提出了一个链接权的问题。 现在，只有公共域软件这种没有版权的软件，才能作为GPL软件的组成部分。因为，可以稍做修改变为GPL许可软件。 任何其他许可除非由于LGPL这样特殊的应用领域，都不应该作为GPL组成部分。都应该发展GPL软件去代替。如果是比GPL许可限制更少的许可，则可能泄漏GPL代码。如果比GPL许可限制更多的许可，则会现在自由软件的自由。 至于其他许可是不是可以和GPL同时发行，则是发行商的问题，和GPL社区无关。不用以此判断是否是GPL兼容软件。 但是，GPL软件也没必要完全白手起家，象gcc就是先在unix上实现的。GPL软件可以建立在任何软件的基础上，因此Qt上建立KDE根本不应该成为争论的问题。只是在其他许可上建立GPL软件要经过慎重考虑，因为，这样毕竟限制了一些修改代码的自由。如果，软件建立在其他许可上，那么就会出现更多的GPL孤岛，切断了GPL世界的联系。 [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=7" title="各种许可协议探讨">编辑</a>] 引伸 [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=8" title="各种许可协议探讨">编辑</a>] 关于各种开放源代码许可讨论 在人们编制软件的时候可以选择各种许可形式。如果要有最大量的使用用户而完全没有私利考虑的话，那么可以选择公共域软件的形式。如果要保证最大的源代码共 享的话，GPL许可是最佳选择。GPL许可的含义就是在捐献代码的同时可以获得其他人的捐献的意思。GPL保证了在代码面前人人平等。如果有更多的考虑的 话，可以建立自己的软件许可。一般都是集中在修改权方面的条款。比如“所有的修改都要寄一份给原作者”、“所有的修改都要和原始程序脱离”、“不允许有非 原始作者允许的修改公开发行”这些都是为了原始程序的作者有最大的利益。这些许可方式虽然属于开放源代码的范畴，但只保证了软件个性化和学习的目的，却对 修改权做了最大的限制，失去了源代码共享的好处。这种许可满足了原作者的利益，但是它不配开放源代码的光环，完全不能和自由软件相提并论。如APL、 MPL、QPL等，因为许可证条款太复杂，我没能真正理解，但现在我暂时认为完全不能和GPL相提并论。只是满足了用户免费和知情权的要求。（如果从知情 权的角度来说，现在的封闭软件都是对用户利益的侵犯，但由于和保守商业秘密矛盾，也没有办法。） [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=9" title="各种许可协议探讨">编辑</a>] 关于开放源代码的商业模式 最普遍的是开放源代码后，满足GPL许可，然后通过发行、咨询、增加用户定制功能来收费。 另一种是将开放源代码和有版权的软件捆绑发行，这样，赚取版权费用。 一种是通过开放全部或部分源代码，收集补丁程序，并满足用户知情权的要求。作为商业软件的补充。通过发行多许可证的方式，从其他许可证赚钱。 通过开放源代码和免费使用赚取垄断标准的地位。 [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=10" title="各种许可协议探讨">编辑</a>] BSD和GPL的比较 最概括性的一句话就是“BSD保证了开发者的自由，GPL保证了使用者的自由”。GPL保证了使用者对程序及其今后的升版的修改和免费使用的自由，BSD 不能保证基于BSD开发的程序今后的所有改进版都能够允许修改和免费使用。BSD保证了开发者能够任意处置程序代码，包括封闭代码和商品化。也就是说 GPL是基于用户的角度设计的授权，BSD是基于开发者的角度设计的授权。 [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=11" title="各种许可协议探讨">编辑</a>] 商业化开发和社区开发的比较 商业化开发 一、能够保证充足的人力和资金来推进一个软件项目的开发，保证软件的用户友好、稳定、高性能。能够满足用户从基本到高级的各个方面的要求。 二、也能够使开发人员能够在开发中获益，获得金钱和股票等。 三、但商业化开发也有很多被批评的地方。商品化软件如果不能满足用户的要求或存在问题，只能等待软件公司恩赐式的补丁和升级，使软件公司能够从用户口袋里 源源不断的掏钱。并且使软件越来越庞大，迫使用户不断的升级硬件。在这个过程中，用户完全没有自由。并且如果软件公司倒闭或放弃了这个软件，那么用户只能 改换门庭，原来的投资和学习全部白白浪费。 而社区式的开发 一、保证了用户能够自助式的改进软件的功能，不必等待其它人的恩赐，并且社区式的软件很可能开发更活跃，能够更快速的推出补丁和升级，能够探索对软件多方 面的扩展。 二、但社区开发是以个人兴趣和业馀时间决定的，它一般不可能提供象商业软件那样的豪华级的功能，一般只提供基本功能。用户友好性和功能的高级性和商品软件 不能相比。 三、并且，也常常不能迅速启动一个庞大的项目，因为庞大的项目常常需要大量的人力和资金，需要严密的组织，和必要的统一的决定。而社区中的开发是比较随意 的，并且经常会为开发的方向争论，谁也不会为自己不同意的项目出力。因此，在社区开发中，大的项目以模仿已有商品化软件为目标，这样，不容易产生争执，也 不需要大量的沟通和开发方向的判断。 四、社区软件的开发进度也是不能保证的，软件开发的快慢要看志愿者的人数，并且在起步阶段常常因为人员问题影响进度，而商业软件没有这个问题，当然，象 linux那样成规模的软件，开发人员投入的人力可能会比单个的软件公司更多。 五、社区化的开发吸引开发人员的原因就是他的自愿性，它可以触发软件开发者被压抑的创造性。 从上面的比较来看，商业化开发和社区开发是相互补充的，不同要求的人可以各取所需。因此，两者都需要大家的扶持和拥护，两者并没有不可调和的矛盾。两者都是软件的使用者所需要的。 BSD正是看到了商业化开发和社区开发都是有利于全社会的，因此，它选择了同时向两者开放。不但商业软件从BSD软件中吸取了营养，社区软件也从BSD软 件中吸取了营养。可以归入BSD类软件的包括：perl,php,apache,freeBSD,xwindows,python,zope等。GPL软 件linux,KDE,gnome(basede from xwindows)都从BSD软件中吸取了很多营养。象收到大家喜爱的商品软件macX,nextstep,IE,beOS也都是基于BSD软件的。正是 BSD这种完全无歧视的政策，可以使任何软件开发收益。这是由于BSD软件的存在，使任何软件的起步都能够从一个比较高的起点出发。像科学发现就很类似 BSD，正是因为科学发现的无私性，才使科学能够不断进步，而不用什么都重新开始。要保持软件开发的学术气氛，BSD是最好的选择。不但是软件，文章、图 片、音乐等都可以仿照BSD授权，这样知识经济的发展才会有一个更扎实的基础。 但为什么BSD软件没有像GPL软件那么获得开源社区的欢迎呢？是因为BSD软件不禁止商业软件的开发，商业软件可以大批的从BSD软件那里拉走用户，而 开源社区的发展最大的动力就是用户，大部分的开源软件的开发者都是从用户中来的。从这个角度讲，BSD授权不利于开源软件的发展。 但，另一方面，GPL断绝了程序代码使商业软件开发收益的途径，也使人们无私奉献出的代码不能被更大社会范围收益。 因此，在不牵涉到个人利益的情况下，希望大家尽量贡献BSD资源。如果牵涉个人利益，可以选择GPL或商业授权。（个人利益包括物质利益和个人理想）另外，MPL是一个兼有开源社区特点和商业开发特点的软件授权，大家也可以考虑。MPL软件包括mozilla,open office。GPL的比较不严格的授权LGPL也是一个很好的选择。 [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=12" title="各种许可协议探讨">编辑</a>] 开放源代码软件授权盘点 新增内容四： 从对商业的友好上来说，公共域代码和MPL都比GPL好，公共域代码不用任何人同意，可以直接用于商业。MPL经过作者的同意授权就可以用于商业。而GPL要众多的原作者和修改者都同意才能用于商业，这几乎是不可能的。 从代码交流的角度来说，公共域代码最好，GPL次之，MPL最差。 从强制公开代码的角度来说，GPL最好，MPL次之，公共域代码最差。 在这篇文章里，我使用了“公共域”授权的名词，公共域指完全放弃版权，没有任何要求，而我指的公共域代码范围更广，实际上，perl、freebsd、python等都是保留版权的，但他们限制非常小，和GPL相比，不强制要求补丁公开源代码，这样就更有商业价值。 我的出发点是考虑商业价值，承认商业软件的合理性和有益性。商业和开放源代码两者不是矛盾，而应该互补才对用户更有利。 新增内容三： 从版权转换来说，公共域代码可以随意转化成其他版权的代码。MPL代码只要作者愿意，就可以转化为其他版权的代码。GPL要转化为其他版权，就要征求所有修改者的同意才能转化为其他版权，这种可能性非常小，除非这个软件在开发的时候只接受bug报告，不接受补丁。 要取得完全的版本控制。对公共域代码来说，因为有部分是商业代码，只要把必要的商业代码用公共域代码重写，就可以取得统一的代码版权控制。对MPL代码来 说，如果原作者不同意把代码全部贡献给公共域，那么，可行的方法是把原作者的代码用公共域代码重写，因为修改的代码是属于公共域的，这部分工作就可以不 作。对GPL代码，就是征求每个代码贡献者的同意，如果不同意，重写相应的代码。GPL软件的作者要取得软件的控制，就要在开发中注意，只接受bug报 告，不接受补丁。 开源软件的开发形式包括，最大限度的接受补丁的全开放式，如linux。不接受补丁的封闭式，如freebsd。linux那样的独裁式，和KDE、GNOME的项目负责式，zope的完全的软件工程序。 新增内容二： 我认为，在通用的领域有大量的公共域软件，而在需要大资金投入，而应用范围小、使用时间短的领域需要商业软件来填补空白。而GPL阻止了这种结构的实现 （只有LGPL协议是不够的）。因此，我提倡使用公共域的软件授权。MPL阻止了相互之间的代码引用，不提倡，只有作者要严格控制授权的时候使用。MPL 之间以及MPL和GPL之间的代码是互斥的。如果从承认商业软件存在合理的基础上，可以认识到公共域授权是最合理的。它能造成开放源代码和商业代码的相互 补充。 新增内容一： 要保证开放源代码完全不被用于商业，并且不保留原作者的权利，那么就要使用GPL协议。同时使用GPL协议的代码可以相互引用。并可以使用公共域代码。也可以被公共域代码使用。如果被公共域代码使用，则公共域代码被升格为GPL代码。 如果要保证所有代码的版权保留在原作者的手中，那么采用MPL协议。MPL协议可以保证所有代码都保留在开放源代码领域，也有GPL同样的遗传性。MPL 可以被公共域使用，不能被其它MPL代码和GPL代码使用。如果公共域代码使用了MPL的代码，也就把自己隔绝于GPL代码。MPL保证了代码版权的完全 集中。方便代码版权的改变。 如果保证代码可以用于商业，并且保证开放源代码，可以采用公共域协议。公共域代码保证可以被所有协议的代码使用，也可以使用MPL代码，不能使用GPL代码。 从开放型来说，公共域代码最开放，GPL其次，最后是MPL。 从保证自己的代码不被剽窃来说，GPL和MPL比较好。 MPL保证了原作者的权利，保证了版权的一致性。同时，它完全符合开放源代码的要求。 新增内容： 公共域授权、GPL授权、MPL授权得比较： GPL协议可以使使用GPL程序得人获得好处，但不能使开发程序得人获得好处。在GPL协议中，原始开发者和后来得修改者地位是平等得，每个人都有权保留 自己得版权，每个人都没有无偿拥有其他人代码得权利，不管是原始作者还是修改者。说GPL是一种病毒也是有道理得，因为GPL程序由于是多个人共同得贡 献，GPL几乎没有机会成为商业程序。 公共域程序则使开发者有两种选择，一是可以贡献自己得代码，为公共域程序做贡献。第二个选择是可以 把新增得代码作为商业程序发布，这样对开放源代码有研究得人也可以从开放源代码中获益。在公共域授权中，每个原始作者和修改者得权利也是平等得。 MPL授权可以最大限度保护开放源代码原始作者得权利，他可以随时把大家修改得程序作为自己得版权程序发布来牟利。对以固定人为骨干得程序可以选择这种授 权来保护自己得最大利益。我认为这种授权方式体现了对原作者得最大尊重，毕竟绝大多数开放源代码程序是以原作者为主力开发得。谋求原始开发者得利益，也就 是鼓励大家都来开发开放源代码程序。同时，也保证了程序得一直免费使用和免费修改，因为可以把他看作是强制公共域得授权，只要所有得修改和使用都是公共域 得，那么，就一直是许可得。但，这种协议引起了极端计较得人得不满，我想太计较得人是不多得，因此，他对号召修改者来参加没有什么大得影响。 GPL协议阻止了公共域程序和MPL程序使用GPL程序得代码。他造成了开放源代码不能互通。公共域程序可以使用MPL得代码，因为MPL得授权只是要求 修改要符合公共域原则。因此，我认为公共域协议和MPL协议是比较合理得协议，而GPL协议弊大于利，它造成了开源程序得鸿沟，同时打击了大家学习开源程 序得热情。GPL协议体现了对商业程序得敌视。没有看到商业程序对大家得好处，有些偏激。我们不能抬高某个授权形式，贬低某个授权形式，每种授权都有他存 在得价值。实际上商业程序对我们得益处是最大得，同时，很多程序只能采用商业程序得形式才有发展得动力。同时，共享程序得成就也给了编程高手很高得成就 感，体现了编程高手得价值，为什么编程高手就不能比其他人过更好得生活？ 原内容： 下面所说得都是我得粗略得理解，很可能和原来得软件许可不一致。如果解释错误，作者不付任何责任。 xlib、freebsd、python、perl、apache、php属于接近公共域授权得形式，就是使用全部免费，修改不要求公开，允许保留自己得 知识产权。这样得授权应用范围最广。它可以被GNU软件使用，也可以被各种授权得软件使用，包括商业软件。这种授权不介意自己的利益，只追求最广泛得应 用。这种授权得软件无权使用其他授权软件得代码。但可以被其他授权得软件使用。 linux、gnome、kde、gcc属于GPL或LGPL软件，使用免费，但修改要求开放源代码。其中GPL比较严格，不允许非GPL得软件链接GPL软件得库函数。如果GPL应用于库函数和语言，那么基于这些库函数和语言得软件都要开放源代码。LGPL允许链接。 netscape得开放源代码版本mozilla和darwin应用MPL许可，这种许可维护了商业软件得利益，它要求基于这种软件得修改无偿贡献版权给 该软件。这样，围绕该软件得所有代码得版权都集中在发起开发人得手中。但MPL是允许修改，无偿使用得。MPL软件对链接没有要求。 mysql软件使用得授权比MPL更进一步，它允许无偿使用和修改，甚至商业用途。但如果基于mysql开发新产品并出售，那么就要向mysql付费。（这里说得是mysql得商业版得授权，同时mysql遵守GPL协议。（这是一个网友更正得我得错误，谢谢） 有的开放源代码软件要求如果用于商业用途就要付费。 有些开源软件要求全部付费，但允许修改。 微软得开放源代码，只允许看源代码，不允许修改。 对于非开源得软件，不允许反向工程，不允许看源代码。其中有免费软件、共享软件、商业软件。 [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=13" title="各种许可协议探讨">编</a><a name=".E5.BB.BA.E8.AE.AE.E5.B0.BD.E9.87.8F.E4.BD.BF.E7.94.A8APL.E6.8E.88.E6.9D.83.EF.BC.8C.E4.B8.8D.E4.BD.BF.E7.94.A8GPL.E6.8E.88.E6.9D.83"> </a> 建议尽量使用APL授权，不使用GPL授权 注：下面否定GPL的话取消，应该是“BSD适合开发者，GPL适合使用者” APL＝apache license 新增内容 我的原意是提倡大家发布软件尽量使用类似perl、bsd、python、apache的类公共域版权授权，尽量少使用GPL授权。宁愿用MPL授权也别用GPL授权。现在的GPL是谁也掌控不了的授权。 希望linux迷们不要武断的反对我的论点，希望能好好考虑一下我的论据。希望这是一次有益的学术讨论，而不是疯狂的政治斗争。 我不是商业软件的开发者，只是编程的爱好者，如果我开发软件的话，肯定采用开源的形式。我是赞同开源的，但我不是很赞同GPL。（是不是很像微软的论点？但我声明不是。）我通过仔细考虑，认为GPL授权有很多不足，不是理想的开源软件授权。 开放源代码是有利于软件发展的非常好的办法，可以节省软件开发人员的大量时间，使软件开发不用再重复别人做过的工作。 但GPL不是一个好的授权，我认为它反而违背了开放源代码的初衷。造成了开放源代码的相互隔阂， 我怕开源软件的爱好者只是被GNU的舆论所鼓动，而没有考虑到GPL授权的不足。我想perl的开发者就是比较早的觉醒者，他看到了GPL的不足。才提出了自己的授权方法。还有apache、php等大量的开源软件并没有采用GPL，他们肯定有自己的道理。 GPL是在商业软件潮流中提出的，只是看到了商业软件的弊端，而提出的。现在开源运动已经成为软件开发的主流之一。在开源软件的蓬勃发展中，大家意识到了 很多GPL没有考虑的因素。GPL可能比较古老了，不适应现在软件发展的潮流了。现在反思GPL，应该是一个比较急迫的事情。 商业软件和开放源代码软件是相互补充的，而不是敌人。 如果没有商业软件，我想肯定现在我们不会享受到这么丰富的软件资源。如果从开始到现在，只有GPL，软件肯定不会有这么迅速的发展。 毕竟世界上大部分的程序员是在开发商业程序，开放源代码的程序员占少数，他们的精力是有限的，他们不可能很好的满足用户对软件无穷无尽的功能需求。 而商业软件在开放源代码基础上的开发，可以满足用户的需求，只要能额外付费，而在开源软件基础上开发的商业软件应该会比独立开发的软件便宜，对用户有利。 同时，由于商业软件的基础是开源软件，肯定会大力扶持开源软件的开发，这样也同样保证了开源软件开发的动力和各种条件。 很多开源软件的开发人员也同样是商业软件的开发人员，在商业开发中不能使用开源代码会浪费开源程序员的经验和知识。同样，也违背了开源软件共享代码的初衷。 GPL是通过强迫的方法来保证商业软件来开源，而开发开源程序的人都是自愿的，那为什么不能把自愿的原则贯彻始终呢？如果原意开源就开源，如果要满足用户的更高层的需要，也可以选择商业的形式来保证软件开发的动力。 如果有不同意见希望能有条理的说出来，只是一句话，没法讨论。 原内容： 建议收集GPL危害使用者和程序员利益的案例 案例一、如果要在使用linux的一个函数是不可能的。这样程序员就要重新编写一个。 案例二、ruby现在是GPL的，因此ruby不能被.net支持，不能被activestate支持。 [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=14" title="各种许可协议探讨">编辑</a>] GPL问答 象perl的artistic license和GPL双重协议，GPL允许代码的相互引用，而artistic license要求修改都是无版权代码，而GPL要求修改都是GPL代码，并且允许GPL代码在不同的GPL软件之间自由引用。如果perl是双重协议， 那么根据GPL代码的引用要求，perl就不可以享受GPL代码相互引用的好处了。并且如果有些perl修改如果声明是GPL的，那么perl也不能引 用。这样perl不但不能享受GPL的好处，并且还有可能因为不能采用GPL修改，而使两个软件许可的代码不一致。这样perl只能造成代码混乱。唯一的 好处是GPL软件可以自由引用perl代码，也可以形成perl的很多分支。这种结果是perl无偿贡献给GPL代码，而没有任何好处，只能造成形成分支 的坏处。 qt的GPL和QPL双重协议，也有同样的问题。 答案：如果存在双重协议，那么只能靠自觉来遵从非GPL协议，否则，其他协议不能采用GPL的代码。 问题二： KDE本身采用GPL协议，为什么引用了Ghost的代码还用Ghost的原作者许可？为什么stallman会提出异议？KDE虽然开发工具是非GPL的，但它本身是GPL，这样有问题吗？ 原来的GNU软件都是在商品unix的基础上开发的，为什么GNU会指责KDE？想不通。 同样，用java编写的程序也可以GPL，没什么不可以吧？ 问题三： GPL和LGPL的关系， LGPL肯定是GPL兼容的。GPL可以使用LGPL的代码没问题。 但LGPL是否可以使用GPL的代码呢？如果可以，完全可以把GPL代码改装为LGPL发布，那么GPL是不是就没有意义了呢？ 如果linux是GPL，而glibc是LGPL，那么glibc凭什么链接linux的代码？是否违反了GPL的协议呢？ 据说在redhat中，有50％是GPL的，有20％是LGPL的，那么，他们之间是如何相互引用的呢？一定存在大量的问题。 我认为解决这个问题的方法就是禁止GPL之间的相互使用，保证GPL程序之间的独立性，并且强制GPL程序必须被整体使用。这样就达到了商业软件的不可拆 分的目的。同时就可以完全放开GPL的链接权。当然也可以规定那些函数是可以链接的，那些是不可以链接的，这样就把链接问题和代码问题分开了。但这种操作 对于GPL软件的没有完全的版权所有人的情况是冲突的。GPL很难操作。 问题四： GPL和版权法的冲突。 版权法规定，修改人拥有修改后的版权。而GPL让修改人放弃版权。版权法是否赋予版权人完全的对作品的修改、引用的权利呢？ GPL的版权声明是否收到所有国家的支持呢？各个国家的支持是否不同呢？GPL是依据的美国的法律。当GPL在其他国家使用时的情况又应该如何呢？在GPL的声明上说，这需要软件作者特别声明，不允许在这些国家使用。 GPL至今没有诉讼，这样不能保证GPL的严谨性。 有人说，版权法赋予了最初版权人的全部特权，可以随时修改版权发布条例，这样，使GPL不是永久保持的。 现在的版权法不是很适应软件的特殊性，软件是介于着作和产品之间的一种东西。应该有针对软件的特殊的法律规定。 [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=15" title="各种许可协议探讨">编辑</a>] 各种开源软件授权方式的选择 [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=16" title="各种许可协议探讨">编辑</a>] 各种开源软件授权方式的介绍 首先介绍开源软件的共同的特点：源代码开放、免费修改、免费重新发布。 以BSD为代表的接近于公共域软件的授权。包括XWindow、freeBSD、apache、perl、python、ruby、zope等。其中 apache的授权叫APL，是一种比较典型的授权声明，下面对于近似公共域的授权以APL表示。这种授权的特点就是虽然保留版权，但不但免费修改、免费 重新发布，而且允许商业使用，允许商业修改后不公布修改的软件代码。是对商业软件友好的授权方式。 以GPL为代表的自由软件，包括linux、gcc、KDE、gnome等。允许免费修改、免费重发布，但要求修改代码必须也遵守GPL。这种授权方式大 大限制了从开源中牟利的手段，因此是对商业不友好的授权，对商业不友好的后果是不能使开源代码产生更广泛的效果、不能调动商业软件开发力量。但也要看到 GPL对打破垄断的价值，打破垄断对所有的商业软件也是有利的。在GPL下面还有一种对商业更友好的方式就是LGPL，允许商业代码链接LGPL代码，这 样商业软件在利用LGPL软件的同时能够很大程度上保留商业利益。gnome是LGPL的（不确定），KDE是GPL的。因此在KDE上面实现商业软件比 较困难，因此说KDE是开放不充分的。 以MPL为代表的商业公司的开源策略。包括mozilla、openoffice等。允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者， 这样发起者和组织者具有更优越的地位。MPL一般也是同时遵守LGPL的。这是因为GPL比较严格，不会产生另一个商业的竞争者。MPL也是对商业友好 的。并且用一些优惠来鼓励商业软件开源。 [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=17" title="各种许可协议探讨">编辑</a>] 开源软件的好处 不要对商业敌视。 GPL的反垄断性。 各种授权的优缺点。 提醒大家关注APL。 开源软件赚钱的途径。 [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=18" title="各种许可协议探讨">编辑</a>] 关于GPL的一些话 如果开源软件的开发要借助社区的力量，那么最好是用GPL授权，因为这样可以防止商业软件抢走用户而导致的开源软件的使用者和开发者都不足。 如果开源软件的开发部需要借助社区的力量，而是封闭开发，使用BSD授权是最恰当的授权。因为既然不需要借助社区的力量，用户的多少和后加入开发的人的多 少都没有关系，并且同样可以达到开源软件给用户修改和重新发布的自由。并且： 一、如果允许修改者商业化，则更加调动了修改者的积极性，可以弥补开源软件不注重豪华功能的缺陷，使小部分用户的特殊需要也能够得到满足，和开源软件形成 互补关系。如activepython就是对python的很好的补充。 二、开源软件的使用范围也更广，对社会的贡献也更大。比如现在python被引入到.net支持的语言范围内，而如果python是GPL，则这种情况是 不可能发生的。 三、比如nextstep，beOS,macX的出现说明BSD使商业软件的起步更高，促进了商业软件的发展，对用户来说获益更大。（我认为开源和商业并 不矛盾，而是相互补充，用户都需要）。 四、不但对用户有好处，也对软件发展的基石--开发人员有好处。使开源软件的开发者在促进开源的同时还可以使自己的事业得益于开源代码，避免了学习投入的 浪费，也使开发的重复工作量最小。（使软件开发在更庞大的基础上继续前进会节省大量的社会资源，会使软件的开发成果更快发展，会出现更多精彩的软件，而每 个公司都从基础做起是对社会的更大浪费，这个问题需要政府和更多的公益事业人员意识到，软件这种不同于其他产品的可继承性的特点需要大家注意，如果立法能 够把商业软件的着作权保护期缩短，并且强制开源，和专利的情况接近，那么对社会进步的好处会更大，除了对公司垄断获得超额利润有影响外，对正常获利也没有 影响） 当然，选择GPL或BSD授权还和人的价值观有关系，但以开发类型来选择授权方式是比较合理的。如果采用封闭开发，使用BSD也可以达到GPL的效果，而采用社区开发，BSD会对开发团队的成长不利。如果在没有商业化价值的领域，GPL完全没有必要。 MPL授权是商业软件想要借助社区的力量的产物。 LGPL对有商业化的友好性和GPL相比是大大提高了，在很多情况下对商业化都没有阻碍，可以说达到了50%的商业化的要求，但有时商业化需要对源代码的 彻底修改，因此不能说LGPL百分之百满足商业化要求，LGPL是一个折衷的授权，如果社区开发的软件希望能在更大的范围内被使用，可以采用LGPL。 在这个论坛中，关心“GPL和BSD哪个授权更好的问题”的人多。讨论商业软件还是GPL软件好的人也很多。但我认为这种讨论是毫无意义的，在现实社会 中，每种软件都有它存在的理由，都有各自不同的用处，并且因为它们性质的不同，会产生相互补充的效果。抬高一个授权，把其馀授权都灭掉的想法根本是错误 的。大家更应该讨论的是不同的授权如何选择的问题。希望我的文章能使大家都授权选择的问题有更周全的考虑。(哈，讨论了这么长时间，才发现竟然不是一个论 题） “BSD满足了开发者的自由，GPL满足了使用者的自由”这句话对两种授权的出发点做了简单明确的回答。“对于开源项目来说，BSD是封闭开发的选择，GPL是社区开发的选择”（对于小的开源项目，封闭开发反而更有效率）是我理解的两种授权不同的适用范围。 [<a href="http://zh.wikibooks.org/w/index.php?title=%E5%90%84%E7%A7%8D%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE%E6%8E%A2%E8%AE%A8&action=edit&section=19" title="各种许可协议探讨">编辑</a>] 各种软件授权的优缺点及适用范围和变种（增订版） APL的优点：能够同时和GPL和商业授权相兼容，使APL的软件代码得到最大限度的利用。 APL的适用范围：如果软件要求有更广泛的使用范围，为了成为行业标准，或在使用中只有做修改才能应用，为了不失去商业客户，只能选择APL。 APL的缺点：没有竞争力，用户容易被在APL基础上开发的GPL和商业软件抢走用户。失去用户的结果就是失去社区开发者，因此，APL软件不适合社区开发。 APL的变种：BSD license、ZPL、artist license和APL的条款类似。而变种公共域软件则没有任何要求，包括保留作者名称的要求，标出修改内容的要求和改变软件名程的要求。 APL和公共域类软件有apache、perl、python、ruby、zope、xwindows、tex、freeBSD GPL的优点：开放源代码，能够保证开发成果不被商业的竞争对手掠夺，能保证用户的忠诚和稳定的社区开发者来源。 GPL的缺点：不能商业使用，限制了代码的应用范围，因此，不能获得商业开发对用户的好处。如果软件的用户范围小或软件某些功能的用户范围小、开发量大， 就不能保证社区开发者的数量，也就不能获得持续的开发。GPL虽然可以应邀开发某些功能，但不如商业软件经济，因为商业软件可以向多个用户收费。 GPL的适用范围：GPL软件生存的前提是用户数量要大，特殊的开发要求要少，适合通用软件。 GPL的变种：MPL要求所有的修改都将版权无偿归软件的创始人所有，而创始人能决定代码的商业使用或改变授权形式。MPL软件无偿使用。 GPL软件还有一种重要的变种，就是对个人使用免费，对商业使用付费。其中很多是以GPL的方式出现的，因为GPL不允许链接，象各种库就被禁止商业使用 了，这些库如果没有采用LGPL授权，那么它们就自然禁止免费商业使用。比如cygwin、berkleyDB、KDE。还有一些开源软件明确说明禁止商 业使用。 GPL软件有gcc、linux、glibc、gnome、open office等。 非LGPL软件，对商业使用付费的软件有cygwin、berkleyDB、KDE、ghostscript的高版本。 MPL软件有mozilla、sun的java编译器、vim 商业授权的优点：能够使开发者获益，因此保证了开发人员的稳定。能开发针对少数用户需求的软件。 商业授权的缺点：不开源，用户没有修改的自由，限制了软件的使用效果和使用范围。 商业授权的变种：微软式的开源，软件不能无偿使用，带开源。所有的修改的版权无偿归微软。（不过微软未全部做到，软件的部分开源，而不能编译，和开源还有段距离） 商业软件的适用范围：用户要求高，用户数量少，用户没有修改的要求，有修改能力的用户数量少，或刚推出的需要大量开发工作的新型软件，初始费用高，而初始用户数量少。规模巨大的成系列的软件，需要严密组织的庞大机构才能开发。 其它一些想法：是否能有一种商业软件的变种，如果只有一个购买者时价格最高，随着购买者的增多，价格下降，并且返还初始购买者高于当前售价的部分，当降到 一定程度的时候，软件改为免费并开源。这种软件开发方式可以在APL授权的软件基础上展开，并以APL为出路。这种授权方式，如果改为当价格降到一定程度 后就不再下降，则

分享到：