发信人: tomz()
整理人: qiaoqian(2001-12-20 05:00:20), 站内信件
|
GPL许可证研究和扩展
GPL许可证是自由软件的应用最广泛的软件许可证。但是我最近看过GPL许可证内容后，却发现GPL许可证的条款有很多不明确的地方，因为它的发布时间已经太久了，现在自由软件和开放源代码软件的发展规模已经比GPL许可证发布的时候大了很多，出现了大量的新问题。在GPL中都没有体现。GPL是不是该出新版本了？（这样说可能有夸张的嫌疑，但这只是我的一个提议。）
下面是我看过GPL许可证后的几点看法：
这是GPL公共许可证的第二条，关于软件的修改权的条款：
2. 您可以修改程式的一个或几个副本或程式的任何部分，以此形成基於这些程式的衍生作品。只要您同时满足下面的所有条件，您就可以按前面第一款的要求复制和发布这一经过修改的程式或作品。
您必须在修改过的档案中附有明显的说明：您修改了此一档案及任何修改的日期。
您必须让您发布或出版的作品，包括本程式的全部或一部分，或内含本程式的全部或部分所衍生的作品，允许第三方在此许可证条款下使用，并且不得因为此项授权行为而收费。
如果修改的程式在执行时以交谈方式读取命令，您必须使它在开始进入一般的交谈使用方式时列印或显示声明：包括适当的版权声明和没有担保的声明(或者您提供担保的声明)；使用者可以按此许可证条款重新发布程式的声明；并告诉使用者如何看到这一许可证的副本。 (例外的情况：如果原始程式以交谈方式工作，但它通常并不列印这样的声明，那麽您基於此程式的作品也就不用列印声明)。
这些要求适用於整个修改过的作品。如果能够确定作品的一部分并非本程式的衍生产品，且可以合理地单独考虑并将它与原作品分开的话，则当您将它作为独立的作品发布时，它不受此许可证和其条款的约束。但是当您将这部分与基於本程式的作品一同发布时，则整个套件将受到本许可证条款约束，因为本许可证对於其他许可证持有人的授权扩大到整个产品，也就是套件的每个部分，不管它是谁写的。
因此，本条款的意图不在於剥夺您对完全由您自身完成作品的权利，而是履行权利来控制基於本程式的集体作品或衍生作品的发布。
此外，将与本程式无关的作品和本程式 (或本程式的衍生作品) 一起放在贮存媒体或发布媒体的同一卷上，并不导致将其他作品置於此许可证的约束□围之内。
关于软件的修改权我认为下面的说法是比较全面的：
你可以以下面的四种方式修改自由软件作品：
第一种方式：如果只是对原始程序进行局部修改，那么应该使修改以补丁文件的形式进行修改，以使修改和原始程序完全脱离。并且，有修改的说明文档，包括每项修改的说明和修改者的联系方法和修改时间。这样，首先当用户使用你的修改版软件出现问题时，可以明确地知道问题应该找原始程序作者还是修改者解决，以免原始程序作者为修改内容负责。另外，当原始程序升级时，也方便使用者同时使用修改内容和升级程序。并且，也方便修改者把修改代码和修改文档反馈给原始程序作者，以便融入原始程序中使修改内容被更多的人使用。建议尽量反馈给原始程序作者，但不是强迫的。
第二种方式：并不修改原始程序代码，但增加程序文件，使原始程序的功能得到增强和扩展。如增加更多的库函数，增加更多的软件功能模块。如果增加程序要和原始程序同时发行，那么，GPL许可应该应用于软件整体，这就是GPL许可中说明的同时发布的相关程序，只要其中有GPL许可程序，那么GPL许可扩大到全体相关程序。如果以这种形式修改，那么那么第一种方式的修改方法是适用的。
第三种方式：在自己创作的软件中引用GPL程序的代码，如果创作的软件也是GPL许可覆盖的软件那么，这种引用是许可的，但要在版权说明中说明参考了那些程序的代码，并尽可能在程序源代码中注释出那些是引用的代码及引用代码的作者和联系方法。这种引用可以不用征得被引用代码作者得同意。
第四种方式：在原始程序的基础上进行修改并重新发布，那么修改内容可以不必和原始程序脱开，但也要有说明文档说明修改内容，原始程序的作者和联系方法，及修改的日期和作者。并且如果能够对原始程序有贡献，那么尽量通知原始程序作者，以便原始程序的作者也享受修改带来的好处。在这种情况下，修改者应该对用户发现的问题负全部责任，而不要麻烦原始程序作者解决。以这种方式修改的结果就是建立了一个原始程序的分支，以实现更自由的修改，但对于享受原始程序的升级的好处则带来了困难。这是修改者的很大的权利，即建立分支的权利。这样的选择适于不满意原程序发展方向和进度或满足特定需要的情况。由于这种方式引入了竞争，这要求补丁程序能够共享，任何人都有权获得和原始程序作者同样多的补丁程序的反馈的拷贝，这样才能避免补丁程序的浪费。可能被抛弃的补丁正是某些用户需要的。提倡开放的补丁的发布方式，更有利于软件的进步。
和GPL许可条款相比：
我说的修改条款更详细规定了在不同的情况下，修改者应该采取的方式和必须承担的义务。比GPL的条款要详细很多，可以更明确地指导修改者的工作。比如第一种方式，修改应该以补丁的方式修改，这种方式已经是现在开放源代码的惯例，对使用者和原始程序的升级都带来了极大的方便。应该属于强制执行的条款。又比如，第三种方式的做法给了被引用代码作者更大的尊重，也明确了修改者究竟带来了多大的创新。第四种方式，也减少了原始程序作者的额外烦恼，并且带来了相互竞争的软件发展模式，避免软件发展的独裁，多样化正是开放源代码的特色，另外，如果带来了开发接口不一致的情况，建立一个标准组织是一个更好的方法。竞争才能带来更强大软件，就像html格式一样，给用户带来最大利益。另外，命令行的版权提示的强制要求没有道理。
这个GPL条款是关于原始作者权利部分：
10. 如果您愿意将程式的一部分结合到其他自由程式中，而它们的发布条件不同，请写信给作者，要求准予使用。如果是自由软体基金会加以版权保护的软体，请写信给自由软体基金会，我们有时会作为例外的情况处理。我们的决定受两个主要目标的指导，这两个主要目标是：我们的自由软体的衍生作品继续保持自由状态，以及从整体上促进软体的共享和重复利用。
我的关于作者权利的想法：
GPL给了原始程序作者使用多个许可证的权利，这样可以保证作者的最大权利，但如果加上“不允许原始程序作者撤销或改变GPL许可”的语句，则这个表述更严密。
另外，作者是否有权利将其他人的修改代码应用于其他许可是一个问题，因为这样带来了GPL程序代码泄漏的问题，如果修改者又引用了其他的GPL代码则带来了更大的泄漏。我的建议是作为严格的GPL许可，应该禁止这种权利，这样才能维护GPL社区的整体利益。但这个权利可以被其他形式的许可采用。是不是现在有人用这种方法进行GPL代码的泄漏？
关于GPL兼容许可的问题：
我看在www.gnu.org的主页上有关于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世界的联系。
引伸：
关于各种开放源代码许可讨论：
在人们编制软件的时候可以选择各种许可形式。如果要有最大量的使用用户而完全没有私利考虑的话，那么可以选择公共域软件的形式。如果要保证最大的源代码共享的话，GPL许可是最佳选择。GPL许可的含义就是在捐献代码的同时可以获得其他人的捐献的意思。GPL保证了在代码面前人人平等。如果有更多的考虑的话，可以建立自己的软件许可。一般都是集中在修改权方面的条款。比如“所有的修改都要寄一份给原作者”、“所有的修改都要和原始程序脱离”、“不允许有非原始作者允许的修改公开发行”这些都是为了原始程序的作者有最大的利益。这些许可方式虽然属于开放源代码的范畴，但只保证了软件个性化和学习的目的，却对修改权做了最大的限制，失去了源代码共享的好处。这种许可满足了原作者的利益，但是它不配开放源代码的光环，完全不能和自由软件相提并论。如APL、MPL、QPL等，因为许可证条款太复杂，我没能真正理解，但现在我暂时认为完全不能和GPL相提并论。只是满足了用户免费和知情权的要求。（如果从知情权的角度来说，现在的封闭软件都是对用户利益的侵犯，但由于和保守商业秘密矛盾，也没有办法。）
关于开放源代码的商业模式：
最普遍的是开放源代码后，满足GPL许可，然后通过发行、咨询、增加用户定制功能来收费。
另一种是将开放源代码和有版权的软件捆绑发行，这样，赚取版权费用。
一种是通过开放全部或部分源代码，收集补丁程序，并满足用户知情权的要求。作为商业软件的补充。
通过发行多许可证的方式，从其他许可证赚钱。
通过开放源代码和免费使用赚取垄断标准的地位。 |
|