许可协议BSD GPL MPL LGPL APL.doc

许可协议BSD GPL MPL LGPL APL GPL 1 GPL许可证研究和扩展 1.1 下面是我看过GPL许可证后的几点看法 1.2 关于软件的修改权我认为下面的说法是比较全面的 1.3 和GPL许可条款相比 1.4 这个GPL条款是关于原始作者权利部分 1.5 我的关于作者权利的想法 1.6 关于GPL兼容许可的问题 1.7 引伸 ?? 1.7.1 关于各种开放源代码许可讨论 ?? 1.7.2 关于开放源代码的商业模式 2 SD和GPL的比较 2.1 商业化开发和社区开发的比较 3 开放源代码软件授权盘点 4 建议尽量使用APL授权，不使用GPL授权 5 GPL问答 6 各种开源软件授权方式的选择 6.1 各种开源软件授权方式的介绍 6.2 开源软件的好处 7 关于GPL的一些话 7.1 各种软件授权的优缺点及适用范围和变种（增订版） 8 对GPL的最新认识 9 商业软件公司对开源软件应该采取的措施 10 GPL条款的一些漏洞 GPL许可证研究和扩展 GPL许可证是自由软件的应用最广泛的软件许可证。但是我最近看过GPL许可证内容后，却发现GPL许可证的条款有很多不明确的地方，因为它的发 布时间已经太久了，现在自由软件和开放源代码软件的发展规模已经比GPL许可证发布的时候大了很多，出现了大量的新问题。在GPL中都没有体现。GPL是 不是该出新版本了？（这样说可能有夸张的嫌疑，但这只是我的一个提议。） 下面是我看过GPL许可证后的几点看法 这是GPL公共许可证的第二条，关于软件的修改权的条款： 2. 您可以修改程式的一个或几个副本或程式的任何部分，以此形成基於这些程式的衍生作品。只要您同时满足下面的所有条件，您就可以按前面第一款的要求复制和发 布这一经过修改的程式或作品。 您必须在修改过的档案中附有明显的说明：您修改了此一档案及任何修改的日期。 您必须让您发布或出版的作品，包括本程式的全部或一部分，或内含本程式的全部或部分所衍生的作品，允许第三方在此许可证条款下使用，并且不得因为此项授权 行为而收费。 如果修改的程式在执行时以交谈方式读取命令，您必须使它在开始进入一般的交谈使用方式时列印或显示声明：包括适当的版权声明和没有担保的声明(或者您提供 担保的声明)；使用者可以按此许可证条款重新发布程式的声明；并告诉使用者如何看到这一许可证的副本。 (例外的情况：如果原始程式以交谈方式工作，但它通常并不列印这样的声明，那麽您基於此程式的作品也就不用列印声明)。 　这些要求适用於整个修改过的作品。如果能够确定作品的一部分并非本程式的衍生产品，且可以合理地单独考虑并将它与原作品分开的话，则当您将它作为独立的 作品发布时，它不受此许可证和其条款的约束。但是当您将这部分与基於本程式的作品一同发布时，则整个套件将受到本许可证条款约束，因为本许可证对於其他许 可证持有人的授权扩大到整个产品，也就是套件的每个部分，不管它是谁写的。 　因此，本条款的意图不在於剥夺您对完全由您自身完成作品的权利，而是履行权利来控制基於本程式的集体作品或衍生作品的发布。 　此外，将与本程式无关的作品和本程式 (或本程式的衍生作品) 一起放在贮存媒体或发布媒体的同一卷上，并不导致将其他作品置於此许可证的约束□围之内。 关于软件的修改权我认为下面的说法是比较全面的 你可以以下面的四种方式修改自由软件作品： 第一种方式：如果只是对原始程序进行局部修改，那么应该使修改以补丁文件的形式进行修改，以使修改和原始程序完全脱离。并且，有修改的说明文档，包括每项 修改的说明和修改者的联系方法和修改时间。这样，首先当用户使用你的修改版软件出现问题时，可以明确地知道问题应该找原始程序作者还是修改者解决，以免原 始程序作者为修改内容负责。另外，当原始程序升级时，也方便使用者同时使用修改内容和升级程序。并且，也方便修改者把修改代码和修改文档反馈给原始程序作 者，以便融入原始程序中使修改内容被更多的人使用。建议尽量反馈给原始程序作者，但不是强迫的。 第二种方式：并不修改原始程序代码，但增加程序文件，使原始程序的功能得到增强和扩展。如增加更多的库函数，增加更多的软件功能模块。如果增加程序要和原 始程序同时发行，那么，GPL许可应该应用于软件整体，这就是GPL许可中说明的同时发布的相关程序，只要其中有GPL许可程序，那么GPL许可扩大到全 体相关程序。如果以这种形式修改，那么那么第一种方式的修改方法是适用的。 第三种方式：在自己创作的软件中引用GPL程序的代码，如果创作的软件也是GPL许可覆盖的软件那么，这种引用是许可的，但要在版权说明中说明参考了那些 程序的代码，并尽可能在程序源代码中注释出那些是引用的代码及引用代码的作