开源≠免费,开源协议License详解
凡是做过软件开发的,都会接触到开源软件或开源组件,它们都会基于某种协议来提供源码和授权,那么这些开源协议到底有哪些约束呢?在介绍之前,必须告诉⼤家,针对开源协议,必须打消“开源 = 免费”这个念头,因为“天下没有免费的午餐”这条真理在这⾥也是适⽤的……本⽂摘录的各种开源协议介绍如下:
Apache Licence 2.0
Apache Licence是著名的⾮盈利开源组织Apache采⽤的协议。该协议和BSD类似,同样⿎励代码共享和尊重原作者的著作权,同样允许代码修改,再发布(作为开源或商业软件)。需要满⾜的条件也和BSD类似:
1. 需要给代码的⽤户⼀份Apache Licence
2. 如果你修改了代码,需要在被修改的⽂件中说明。
3. 在延伸的代码中(修改和有源代码衍⽣的代码中)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说
明。
4. 如果再发布的产品中包含⼀个Notice⽂件,则在Notice⽂件中需要带有Apache Licence。你可以在Notice中增加⾃⼰的许可,但不可
以表现为对Apache Licence构成更改。
Apache Licence也是对商业应⽤友好的许可。使⽤者也可以在需要的时候修改代码来满⾜需要并作为开源或商业产品发布/销售。
GPL
在⾃由软件所使⽤的各种许可证之中,最为⼈们注意的也许是通⽤性公开许可证(General Public License,简称GPL)。
GPL同其它的⾃由软件许可证⼀样,许可社会公众享有:运⾏、复制软件的⾃由,发⾏传播软件的⾃由,获得软件源码的⾃由,改进软件并将⾃⼰作出的改进版本向社会发⾏传播的⾃由。
开放源代码意味着什么GPL 还规定:只要这种修改⽂本在整体上或者其某个部分来源于遵循GPL的程序,该修改⽂本的整体就必须按照GPL流通,不仅该修改⽂本的源码必须向社会公开,⽽且对于这种修改⽂本的流通不准许附加修改者⾃⼰作出的限制。因此,⼀项遵循GPL流通的程序不能同⾮⾃由的软件合并。GPL所表达的这种流通规则称为copyleft,表⽰与copyright(版权)的概念“相左”。
GPL协议最主要的⼏个原则:
1、确保软件⾃始⾄终都以开放源代码形式发布,保护开发成果不被窃取⽤作商业发售。任何⼀套软件,只要其中使⽤了受 GPL 协议保护的第三⽅软件的源程序,并向⾮开发⼈员发布时,软件本⾝也就⾃动成为受 GPL 保护并且约束的实体。也就是说,此时它必须开放源代码。
2、 GPL ⼤致就是⼀个左侧版权(Copyleft,或译为“反版权”、“版权属左”、“版权所⽆”、“版责”等)的体现。你可以去掉所有原作的版权信息,只要你保持开源,并且随源代码、⼆进制版附上 GPL 的许可证就⾏,让后⼈可以很明确地得知此软件的授权信息。GPL 精髓就是,只要使软件在完整开源的情况下,尽可能使使⽤者得到⾃由发挥的空间,使软件得到更快更好的发展。
3、⽆论软件以何种形式发布,都必须同时附上源代码。例如在 Web 上提供下载,就必须在⼆进制版本(如果有的话)下载的同⼀个页⾯,清楚地提供源代码下载的链接。如果以光盘形式发布,就必须同时附上源⽂件的光盘。
4、开发或维护遵循 GPL 协议开发的软件的公司或个⼈,可以对使⽤者收取⼀定的服务费⽤。但还是⼀句⽼话——必须⽆偿提供软件的完整源代码,不得将源代码与服务做捆绑或任何变相捆绑销售。
BSD
BSD开源协议是⼀个给于使⽤者很⼤⾃由的协议。可以⾃由的使⽤,修改源代码,也可以将修改后的代码作为开源或者专有软件再发布。当你发布使⽤了BSD协议的代码,或者以BSD协议代码为基础做⼆次开发⾃⼰的产品时,需要满⾜三个条件:
如果再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议。
如果再发布的只是⼆进制类库/软件,则需要在类库/软件的⽂档和版权声明中包含原来代码中的BSD协议。
不可以⽤开源代码的作者/机构名字和原来产品的名字做市场推⼴。
BSD 代码⿎励代码共享,但需要尊重代码作者的著作权。BSD由于允许使⽤者修改和重新发布代码,也允许使⽤或在BSD代码上开发商业软件发布和销售,因此是对商业集成很友好的协议。很多的公司企业在选⽤开源产品的时候都⾸选BSD协议,因为可以完全控制这些第三⽅的代码,在必要的时候可以修改或者⼆次开发。
MIT
MIT许可证之名源⾃⿇省理⼯学院(Massachusetts Institute of Technology, MIT),⼜称「X条款」(X License)或「X11条款」(X11 License)
MIT内容与三条款BSD许可证(3-clause BSD license)内容颇为近似,但是赋予软体被授权⼈更⼤的权利与更少的限制。
被授权⼈有权利使⽤、复制、修改、合并、出版发⾏、散布、再授权及贩售软体及软体的副本。
被授权⼈可根据程式的需要修改授权条款为适当的内容。
在软件和软件的所有副本中都必须包含版权声明和许可声明。
此授权条款并⾮属copyleft的⾃由软体授权条款,允许在⾃由/开放源码软体或⾮⾃由软体(proprietary software)所使⽤。
此亦为MIT与BSD(The BSD license, 3-clause BSD license)本质上不同处。
MIT条款可与其他授权条款并存。另外,MIT条款也是⾃由软体基⾦会(FSF)所认可的⾃由软体授权条款,与GPL相容。
MPL
MPL 是The Mozilla Public License的简写,是1998年初Netscape的 Mozilla⼩组为其开源软件项⽬设计
的软件许可证。MPL许可证出现的最重要原因就是,Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利⽤源代码获得的利益。同著名的GPL许可证和BSD许可证相⽐,MPL在许多权利与义务的约定⽅⾯与它们相同(因为都是符合OSIA 认定的开源软件许可证)。但是,相⽐⽽⾔MPL 还有以下⼏个显著的不同之处:
◆ MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的⽅式再许可出来,以保证其他⼈可以在MPL的条款下共享源代码。但是,在MPL 许可证中对“发布”的定义是“以源代码⽅式发布的⽂件”,这就意味着MPL允许⼀个企业在⾃⼰已有的源代码库上加⼀个接⼝,除了接⼝程序的源代码以MPL 许可证的形式对外许可外,源代码库中的源代码就可以不⽤MPL许可证的⽅式强制对外许可。这些,就为借鉴别⼈的源代码⽤做⾃⼰商业软件开发的⾏为留了⼀个豁⼝。
◆ MPL许可证第三条第7款中允许被许可⼈将经过MPL许可证获得的源代码同⾃⼰其他类型的代码混合得到⾃⼰的软件程序。
◆对软件专利的态度,MPL许可证不像GPL许可证那样明确表⽰反对软件专利,但是却明确要求源代码的提供者不能提供已经受专利保护的源代码(除⾮他本⼈是专利权⼈,并书⾯向公众免费许可这些源代码),也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。
◆对源代码的定义
⽽在MPL(1.1版本)许可证中,对源代码的定义是:“源代码指的是对作品进⾏修改最优先择取的形式,它包括:所有模块的所有源程序,加上有关的接⼝的定义,加上控制可执⾏作品的安装和编译的‘原本’(原⽂为‘Script’),或者不是与初始源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。”
◆ MPL许可证第3条有专门的⼀款是关于对源代码修改进⾏描述的规定,就是要求所有再发布者都得有⼀个专门的⽂件就对源代码程序修改的时间和修改的⽅式有描述。
LGPL
LGPL 是GPL的⼀个为主要为类库使⽤设计的开源协议。和GPL要求任何使⽤/修改/衍⽣之GPL类库的的软件必须采⽤GPL协议不同。LGPL 允许商业软件通过类库引⽤(link)⽅式使⽤LGPL类库⽽不需要开源商业软件的代码。这使得采⽤LGPL协议的开源代码可以被商业软件作为类库引⽤并发布和销售。
但是如果修改LGPL协议的代码或者衍⽣,则所有修改的代码,涉及修改部分的额外代码和衍⽣的代码都必须采⽤LGPL协议。因此LGPL协议的开源代码很适合作为第三⽅类库被商业软件引⽤,但不适合希望以LGPL协议代码为基础,通过修改和衍⽣的⽅式做⼆次开发的商业软件采⽤。
GPL/LGPL都保障原作者的知识产权,避免有⼈利⽤开源代码复制并开发类似的产品
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论