APL GPL等协议.docx
《APL GPL等协议.docx》由会员分享，可在线阅读，更多相关《APL GPL等协议.docx（21页珍藏版）》请在冰豆网上搜索。
APLGPL等协议
许可协议BSDGPLMPLLGPLAPL、MIT
开源许可协议很多，这里说说他们的区别，以及使用相关代码需要考虑的协议约束。
、
开源软件的授权许可都是基于开源许可协议的，常见的开源许可协议有GPL、LGPL、APL、BSD、MIT、MozillaPublicLicense、CreativeCommons、EclipsePublicLicense1.0等。
它们之前有很多相同的地方，也有很多不同的地方，本文将分析一下这些协议之间的区别。
GPL（GNUGeneralPublicLicense），使用源软件的类库引用（源代码）、改变（修改了源代码）的新软件，也必须采用GPL进行授权。
就是说，只要使用了GPL开源软件的源代码或拿它的源代码进行了修改而编写的新的软件，也必须加入到GPL的阵营。
很明显，不能拿GPL授权的开源东东来做商业软件。
这个协议有个好处，就是极大增加了使用GPL的软件的数量。
采用GPL授权的软件有：
Linux、MySQL等。
LGPL（LesserGPL），相比GPL的严格，LGPL要温和很多。
可以通过引用类库的方式（不是直接使用源代码）拿LGPL授权的东东来重新开发商业软件。
如果是要修改源代码，是相应的修改和衍生出来的代码都要使用LGPL开放源代码。
采用LGPL的软件有：
JBoss、Hibernate、FCKeditor等。
APL（apacheLicencevesion2.0），适用于商业软件，允许修改代码后再发布（不用开放源代码）。
采用APL的软件有Hadoop、ApacheHttpServer等。
BSD（BerkeleySoftwareDistribution），这个协议的要求很宽松，允许他人修改和重新发布代码，可以在此基础上开发出商业软件进行销售。
所以，此协议适用于商业软件。
采用BSD协议的软件最著名的有nginx。
MIT（MassachusettsInstituteofTechnology），又称X11协议。
MIT与BSD类似，但是比BSD协议更加宽松，算是目前限制最少的协议了。
这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。
适用商业软件。
采用MIT的软件有：
jquery、Node.js
此外，还有MozillaPublicLicense、CreativeCommons、EclipsePublicLicense1.0等协议。
大家可以详查相关资料。
下面详细说说我的一下看法和注意事项提示。
GPL
1GPL许可证研究和扩展
1.1下面是我看过GPL许可证后的几点看法
1.2关于软件的修改权我认为下面的说法是比较全面的
1.3和GPL许可条款相比
1.4这个GPL条款是关于原始作者权利部分
1.5我的关于作者权利的想法
1.6关于GPL兼容许可的问题
1.7引伸
1.7.1关于各种开放源代码许可讨论
1.7.2关于开放源代码的商业模式
2SD和GPL的比较
2.1商业化开发和社区开发的比较
3开放源代码软件授权盘点
4建议尽量使用APL授权，不使用GPL授权
5GPL问答
6各种开源软件授权方式的选择
6.1各种开源软件授权方式的介绍
6.2开源软件的好处
7关于GPL的一些话
7.1各种软件授权的优缺点及适用范围和变种（增订版）
8对GPL的最新认识
9商业软件公司对开源软件应该采取的措施
10GPL条款的一些漏洞
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许可，然后通过发行、咨询、增加用户定制功能来收费。
另一种是将开放源代码和有版权的软件捆绑发行，这样，赚取版权费用。
一种是通过开放全部或部分源代码，收集补丁程序，并满足用户知情权的要求。
作为商业软件的补充。
通过发行多许可证的方式，从其他许可证赚钱。
通过开放源代码和免费使用赚取垄断标准的地位。
SD和GPL的比较
最概括性的一句话就是“BSD保证了开发者的自由，GPL保证了使用者的自由”。
GPL保证了使用者对程序及其今后的升版的修改和免费使用的自由，BSD不能保证基于BSD开发的程序今后的所有改进版都能够允许修改和免费使用。
BSD保证了开发者能够任意处置程序代码，包括封闭代码和商品化。
也就是说GPL是基于用户的角度设计的授权，BSD是基于开发者的角度设计的授权。
商业化开发和社区开发的比较
商业化开发
一、能够保证充足的人力和资金来推进一个软件项目的开发，保证软件的用户友好、稳定、高性能。
能够满足用户从基本到高级的各个方面的要求。
二、也能够使开发人员能够在开发中获益，获得金钱和股票等。
三、但商业化开发也有很多被批评的地方。
商品化软件如果不能满足用户的要求或存在问题，只能等待软件公司恩赐式的补丁和升级，使软件公司能够从用户口袋里源源不断的掏钱。
并且使软件越来越庞大，迫使用户不断的升级硬件。
在这个过程中，用户完全没有自由。
并且如果软件公司倒闭或放弃了这个软件，那么用户只能改换门庭，原来的投资和学习全部白白浪费。
而社区式的开发
一、保证了用户能够自助式的改进软件的功能，不必等待其它人的恩赐，并且社区式的软件很可能开发更活跃，能够更快速的推出补丁和升级，能够探索对软件多方面的扩展。
二、但社区开发是以个人兴趣和业余时间决定的，它一般不可能提供象商业软件那样的豪华级的功能，一般只提供基本功能。
用户友好性和功能的高级性和商品软件不能相比。
三、并且，也常常不能迅速启动一个庞大的项目，因为庞大的项目常常需要大量的人力和资金，需要严密的组织，和必要的统一的决定。
而社区中的开发是比较随意的，并且经常会为开发的方向争论，谁也不会为自己不同意的项目出力。
因此，在社区开发中，大的项目以模仿已有商品化软件为目标，这样，不容易产生争执，也不需要大量的沟通和开发方向的判断。
四、社区软件的开发进度也是不能保证的，软件开发的快慢要看志愿者的人数，并且在起步阶段常常因为人员问题影响进度，而商业软件没有这个问题，当然，象linux那样成规模的软件，开发人员投入的人力可能会比单个的软件公司更多。
五、社区化的开发吸引开发人员的原因就是他的自愿性，它可以触发软件开发者被压抑的创造性。
从上面的比较来看，商业化开发和社区开发是相互补充的，不同要求的人可以各取所需。
因此，两者都需要大家的扶持和拥护，两者并没有不可调和的矛盾。
两者都是软件的使用者所需要的。
BSD正是看到了商业化开发和社区开发都是有利于全社会的，因此，它选择了同时向两者开放。
不但商业软件从BSD软件中吸取了营养，社区软件也从BSD软件中吸取了营养。
可以归入BSD类软件的包括：
perl,php,apache,freeBSD,xwindows,python,zope等。
GPL软件linux,KDE,gnome（basedefromxwindows）都从BSD软件中吸取了很多营养。
象收到大家喜爱的商品软件macX,nextstep,IE,beOS也都是基于BSD软件的。
正是BSD这种完全无歧视的政策，可以使任何软件开发收益。
这是由于BSD软件的存在，使任何软件的起步都能够从一个比较高的起点出发。
像科学发现就很类似BSD，正是因为科学发现的无私性，才使科学能够不断进步，而不用什么都重新开始。
要保持软件开发的学术气氛，BSD是最好的选择。
不但是软件，文章、图片、音乐等都可以仿照BSD授权，这样知识经济的发展才会有一个更扎实的基础。
但为什么BSD软件没有像GPL软件那么获得开源社区的欢迎呢？
是因为BSD软件不禁止商业软件的开发，商业软件可以大批的从BSD软件那里拉走用户，而开源社区的发展最大的动力就是用户，大部分的开源软件的开发者都是从用户中来的。
从这个角度讲，BSD授权不利于开源软件的发展。
但，另一方面，GPL断绝了程序代码使商业软件开发收益的途径，也使人们无私奉献出的代码不能被更大社会范围收益。
因此，在不牵涉到个人利益的情况下，希望大家尽量贡献BSD资源。
如果牵涉个人利益，可以选择GPL或商业授权。
（个人利益包括物质利益和个人理想）另外，MPL是一个兼有开源社区特点和商业开发特点的软件授权，大家也可以考虑。
MPL软件包括mozilla,openoffice。
GPL的比较不严格的授权LGPL也是一个很好的选择。
开放源代码软件授权盘点
新增内容四：
从对商业的友好上来说，公共域代码和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属于接近公共域授权得形式，就是使用全部免费，修改不要求公开，允许保留自己得知识产权。
这样得授权应用范围最广。
它可
升级会员 