nginx,开源协议

竭诚为您提供优质文档/双击可除nginx,开源协议篇一：开源协议一．每个协议分别找出一个使用该协议的开源软件。

1.gpl，全称gnugeneralpubliclicense。

它的主要内容为：只要在一个软件中使用(“使用”指类库引用或者修改后的代码)gpl协议的产品，则该软件产品必须也采用gpl协议，既必须也是开源和免费。

这个协议就不太适合商用软件，或者准备使用gpl开源组件的商用项目。

基于这个协议的项目，极大的提高了开源软件的数量。

采用这个协议的开源软件有：linux、mysql。

2.lgpl，全称gnulessergeneralpubliclicense次通用公共许可协议。

lgpl允许商业软件通过引用类库的方式使用lgpl组件（不直接使用源代码），这样可以不需要开源商业软件的代码。

但是如果要修改原始组件的代码，则涉及修改部分的代码和基于原来代码衍生的代码都必须采用lgpl协议。

lgpl不适合以lgpl协议为基础的代码进行二次开发的商业软件，但是商用软件可以采用编译后的类库引用就不需要公开源代码了。

采用这个协议的开源软件有：jboss、Fckeditor、hibernate。

3.bsd，全称berkeleysoftwaredistribution。

这个协议允许使用者修改和重新发布代码，也允许使用或在bsd代码基础上开发商业软件发布和销售，因此是适用于商业软件的。

使用时还必须做到满足三个条件：1）如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的bsd协议。

2）如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的bsd协议。

3）不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

适用bsd协议的开源软件有：nginx、cruisecontrol、Redis。

4mit，源自麻省理工学院（massachusettsinstituteoftechnology,mit），又称x11协议。

mit与bsd类似，但是比bsd协议更加宽松，是目前最少限制的协议。

这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。

适用商业软件。

使用mit 的软件项目有：jquery、node.js。

5.apachelicencevesion2.0，这个协议除了为用户提供版权许可之外，还有专利许可。

与bsd协议权限类似，允许代码修改，再发布，适用商业软件使用apachelicencevesion2.0协议的开源软件有：hadoop、apachehttpserver、springFramework、mongodb。

6.creativecommons知识共享协议creativecommons(cc)许可协议并不能说是真正的开源协议，它们大多是被使用于设计类的工程上。

cc协议种类繁多，每一种都授权特定的权利。

一个cc许可协议具有四个基本部分，这几个部分可以单独起作用，也可以组合起来。

下面是这几部分的简介：署名作品上必须附有作品的归属。

如此之后，作品可以被修改，分发，复制和其它用途。

相同方式共享作品可以被修改、分发或其它操作，但所有的衍生品都要置于cc许可协议下。

非商业用途作品可以被修改、分发等等，但不能用于商业目的。

但语言上对什么是商业的说明十分含糊不清(没有提供精确的定义)，所以你可以在你的工程里对其进行说明。

例如，有些人简单的解释非商业为不能出售这个作品。

而另外一些人认为你甚至不能在有广告的网站上使用它们。

还有些人认为商业仅仅指你用它获取利益。

禁止衍生作品这意味着你可以复制和分发它们，但你不能以任何方式修改它们，或基于它们进行二次创作使用该协议的开源软件有mission二．如果自行开发一个软件，允许别人在你的基础上继续衍生，但不能被商用，我会选择gpl协议。

如果能被商用，我会选择用mit协议。

这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。

适用商业软件。

篇二：使用高性能web服务器nginx实现开源负载均衡internet的快速增长使多媒体网络服务器，特别是web 服务器，面对的访问者数量快速增加，网络服务器需要具备提供大量并发访问服务的能力。

对于提供大负载web服务的服务器来讲，cpu、i/o处理能力很快会成为瓶颈。

简单的提高硬件性能并不能真正解决这个问题，因为单台服务器的性能总是有限的，尤其是网络请求具有突发性，当某些重大事件发生时，网络访问就会急剧上升，从而造成网络瓶颈，必须采用多台服务器提供网络服务，并将网络请求分配给这些服务器分担，才能提供处理大量并发服务的能力，因此服务器的负载均衡技术就成为建立一个高负载web站点的关键性技术。

（一）nginx及负载均衡介绍1.高性能web服务器ngnixnginx(“enginex”)是俄罗斯人igorsysoev(塞索耶夫)编写的一款高性能的http和反向代理服务器，也是一个imap/pop3/smtp代理服务器。

nginx已经在俄罗斯最大的门户网站──Ramblermedia（*;location/{proxy_passhttp://servername;proxy_set_headerhost$host;proxy_set_headerx-Forwarded-For$remote_addr;}access_logoff;}其中：proxy_passhttp://servername用于指定反向代理的服务器池；proxy_set_headerhost$host当后端web服务器上也配置有多个虚拟主机时，需要用该header来区分反向代理哪个主机名；proxy_set_headerx-Forwarded-For$remote_addr;如果后端web服务器上的程序需要获取用户ip，就从该header头获取。

3.nginx负载均衡的双机热备nginx处理所有流量受限于机器i/o和配置；本身的bug 也还是难以避免的；nginx没有现成的双机热备方案，所以跑在单机上还是风险较大，单机上的事情全都很难说。

因此，可以通过keepalived来实现nginx负载均衡的双机热备。

正常情况下，两台nginx负载均衡服务器全部处于活动状态，对外提供服务。

通过两台服务器之间的互相检测机制，当主服务器上的检测程序发现自身的nginx无法访问时，停止绑定虚拟ip，改由备用服务器绑定虚拟ip，同时由主服务器给网关发送arping包，保证了网关上ip、mac地址对应关系能够马上更改，能够做到强行接管虚拟ip。

4.在nginx负载均衡服务器上设置缓存，加快服务器响应速度nginx从0.7.48版本开始，支持了类似squid的缓存功能，缓存把uRl及相关组合当作key，用md5编码哈希后保存。

对于修改实时性要求不高的图片、Flash、css样式文件、javascript文件，可以在nginx反向代理(负载均衡)服务器上设置缓存，不用每次请求都转发到后端web服务器，加快了响应速度。

同时也可以减少nginx与后端web服务器的连接数，提高了nginx处理性能。

篇三：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等协议。

大家可以详查相关资料。

下面详细说说我的一下看法和注意事项提示。

gpl1gpl许可证研究和扩展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许可证发布的时候大了很多，出现了大量的新问题。