风君子博客大家好，今天小编来为大家解答担保公司网站源码分享这个问题，担保网推荐平台很多人还不知道，现在让我们一起来看看吧！
作者|卫剑钒
来源|微月人话（ID:man-mind）
我们知道，朋友之间或者有一定信任的人之间发生经济往来时（比如借贷或租房之类），虽然也会写借据或合同，但大多比较简单，一页纸就完事了，因为通常不会出事，写多了见外。但如果是机构行为，就会严谨和正式很多，洋洋洒洒好几页，各种通常不会发生的情况都会考虑进去，因为说不准会遇到什么人呢！
MIT许可证就是那种一页纸的协议，一共就三段话，非常宽松，看样子基本上不会去打官司。
Apache许可证也很宽松，但行文上就严谨很多，篇幅也变长很多（大约是MIT的10倍！），设计者在撰写时，显然考虑了种种复杂情况，并随时准备对簿公堂（虽然极少发生）。
不过许可证稍微一长，大家就没有耐心看了。更不要说还是法律语言写成的。
Apache2.0许可证是ASF（ApacheSoftwareFoundation，Apache软件基金会）在2004年发布的，以帮助ASF实现其目标：“通过开源软件开发协作，提供可靠且长久不衰的软件产品”。ASF出品的软件一般都采用Apache2.0许可证。当然，非ASF的项目也可以使用，Apache许可证设计出来是供所有人使用的。
有人专门做过分析1，Github上使用率最高的许可证，前5名是MIT、Apache2.0、GPL2.0、GPL3.0和bsd-3-clause。本公众号已经在前面专门介绍过MIT。
本文的目的，是从浅入深弄懂Apache许可证，并完全忠于原文。
文章较长，我将以“步进式”方式解读，最精华的放在最前面，以便于你在不能读完的情况下，也能get到精华。
不过，越往后看，会有越多的料。强烈建议读完。
如果对全文翻译不感兴趣，可以迅速拉过第五节。
注：本文不区分“Apache2.0许可证”、“Apache许可证”、“Apache协议”，视作完全等同。
Apache一句话要旨
Apache许可证全文读下来，需要一点功夫。
如果你只想记一句话，那就是“要留我的名，改哪了你得说！”
Apache协议精要
从最精简的角度讲，Apache协议想说的是这些：
你可以随便用！不会因版权和专利找你麻烦的！
不能用我的商标！
你分发本作品或衍生作品时，可以不再提供源码！
你在分发时，必须做到：
1、带上本许可证！
2、保留本软件的所有版权、专利等说明！
3、你改过的文件，你得说改了哪！
4、NOTICE文件中的信息得保留！
5、在遵循本许可证的条件下，你可以再许可！
本作品就这样了，我不会负任何责任的！你想负责你可以负，但别拉上我！
能稍微详细一点吗？
下面是一个人话精简版（对应Apache许可证的第1到9节）。
1、本软件又叫本“作品”，可以是源码，也可以是编译或转换后的其他形式。“衍生作品”是在本作品的基础上修改后的有原创性的工作成果。本作品的“贡献者”包括许可人和其他提交了贡献的人，以下统称“我”。
2.我授予你权利：你可以免费复制、使用、修改、再许可、分发本作品及衍生作品（可以不用公开源码）。
3.如果本软件涉及我的专利（或潜在专利），我在此授予你专利许可，你可以永久性地免费使用此专利，用于制作、使用、出售、转让本作品。如果你哪天居然告本作品侵权，你的专利许可在你告我那天被收回。
4.你在复制和分发本作品或衍生作品时，要满足以下条件。
*带一份本许可证；
*如果你修改了什么，要在改动的文件中有明显的修改声明。
*如果你以源码形式分发，你必须保留本作品的版权、专利、商标和归属声明。
*如果本作品带了“NOTICE”文件，你就得带上NOTICE文件中包含的归属声明。即便你的发布是不带源码的，你也得带上此文件，并在作品某处予以展示。
*你可以对自己的修改添加版权说明。对于你的修改或者整个衍生作品，你可以使用不同的许可，但你对本作品的使用、复制和分发等，必须符合本许可证规定。
5.你提交贡献就表明你默认遵守本许可的条款和条件。当然，你可以和我签订另外的专门的条款。
6.你不许使用我的商品名、商标、服务标志或产品名。
7.本作品是“按原样”（ASIS）提供的，没有任何保证啊，你懂的。
8.我可不负任何责任。除非我书面同意，或者法律有这样的要求（例如对故意和重大过失行为负责）。
9.你可以向别人提供保证，你可以向别人收费，但那都是你的事，别给我惹麻烦。
注意以上的“我”，既包含了许可人，也包含了每位贡献者。
上面提到的归属声明，英文是attributionnotices，attribution在这里的含义是“归功于”，或者说是一种credit，表明一个作品归功于谁。除了归功于自己之外，归属声明主要强调的是归功自己用到的其他作品（即第三方作品）。
比如chrome浏览器使用了非常多的其他开源作品，在其“关于”中，可以看到：
打开“开源软件”后，就能看到长长的credit列表。
Asim质疑go-chassis事件
2018年1月，发生了这么一件事，go-micro项目的作者Asim质疑go-chassis项目不合理地使用了其代码2。
这两个项目都是使用Apache许可证的。
当时，go-chassis项目在其README中是这么写的：
意思是说“本项目受go-micro启发，但并不是基于它的改善，我们做了更多”。
项目在third-party目录下放了go-micro的5个源代码文件，也带了go-micro的LICENSE文件（内含版权信息），但没有很明显地予以归功（比如在NOTICE文件中）。
1月27日，go-micro的作者Asim，在go-chassis的仓库下发贴（issue151以标题“adjustlicense¬ice”出现，提议在LICENSE、NOTICE和README中，删掉go-micro。该PR得到了项目维护人tianxiaoliang的approve。
asim在issue151的对话中写道：
大意是说，“你的作品是基于go-micro的，即便你修改和清除了go-micro的代码，你也是基于我而来的，你不能删掉我的版权和许可。我仍然可以指出你的哪部分代码像我的。”
不过这次抗议并没有得到回应。
2018年9月17日，README中删除了“本项目基于go-micro”这句。
2019年10月22日，NOTICE中的归功被删掉，licenses/LICENSE-go-micro文件被删掉。
至此，go-chassis和go-micro不再有关系了。
asim也没有再说什么。
我又去看看了go-micro，发现asim虽然维权意识很强，但在版权声明上做的还不够，go-micro项目没有NOTICE文件（这个还好，这不是必须的，尤其是没有第三方可以归功的时候）；在所有的源文件中，都没有版权和许可信息，只是在LICENSE文件中Apache许可证的附录部分，声明了一下版权（这种做法也不常见，通常是不动Apache许可证整个内容的）：
另外一点让我感觉意外的是，go-chassis虽然说已经和go-micro无关了，但删的并不干净，在其代码中还是能找到go-micro的字样！
下面是在go-chassis中搜索go-micro的结果（2020年5月10日）：
我只能认为，这可能是个疏忽。
我该怎么归功？
从Apache许可证和一些纠纷看，大家是很重视“留名”的。
毕竟，做开源的人，如果连“名”都图不上，那可就差点意思了。
如何留下作者和贡献者的名？
常见的做法是源代码里面留名。源码的首部应该放上版权信息和许可信息。但我在github上翻了翻，发现很多项目并没有做到这点，有的完全没有版权和许可信息，有的则是只写许可不写版权。
究其原因，估计作者一是太懒，二是没有这个意识。
做得比较好的项目，不仅在源码中有声明，还会专门在根目录下放上诸如AUTHORS、CONTRIBUTORS、OWNERS、CREDITS这类文件，对作者和贡献者予以明确的归功。（这些不是必须的，但是推荐的。）
关于版权那行，有一种写法是很讲究的6，值得欣赏和学习:
Copyright<year><primaryauthors>andcontributors
比如下面这个例子：
这并不是必须的，因为即便不这么写，贡献者也是自动拥有其版权的。只不过这样写，显得格外尊重贡献者。
如何留下作品的名？
如果你使用（或依赖）了第三方作品，要在NOTICE和LICENSE中说明。
NOTICE文件是专门干这事的。
对于ASF的项目，一般都会有NOTICE文件，但非ASF项目，用的就不太多，即便是使用Apache许可证的。
下面是Kafka项目的NOTICE文件，属于比较标准的ASF项目写法。除了致敬所用到的ASF作品外，Kafka特意对jersey做了归功（以下为NOTICE全文）。
在下面这个非ASF项目Hangfire7中，其NOTICE文件也很规范，文字表述非常详尽，值得学习（以下为文件首部）。
关于LICENSE文件，除了放本项目的许可证，还应放上所用其他项目的许可证。下面以ApacheKylin项目为例看一下，Kylin使用了一些其他作品（它称为子部件，subcomponent），这些作品使用的许可证在LICENSE文件中作了说明：
注意上面的截图，是从207行开始的，上面的200多行，就是Apache许可证全文，然后是他所用到子部件的许可证。
如果用到的作品比较多，也可以专门建一个licenses目录做这件事，go-chassis就是这样做的。
为了很好地对贡献者和第三方作品致敬，有的项目还会在网站上予以展示：
比如selenium项目8就密密麻麻地列出了贡献者的名字和头像，看上去颇为壮观。
以下仅仅为部分节选，有兴趣的话可以去其网站观摩一下。
总之，尽可能尊重贡献者和你用到的作品，充分地给予他们荣誉。这是开源人应有的礼仪。
关于“再许可”的迷思
为了更好理解Apache许可证，现在看一个我虚构出来的测试案例。
Alice有一个作品A，用Apache许可证发布，里面只有一个foo.c，文件的内容可概括为：
版权年份Alice
Apache许可信息
源码
作品还带了一个LICENSE和NOTICE。LICENSE里面就是Apache许可证全文。NOTICE里声明了Alice对A的版权所有（也即对自己归功）。
现在Bob复制了作品A，把foo.c略微修改了一下，改为：
版权年份Alice
“各位注意：我修改了许可信息，从Apache改为了MIT”
MIT许可信息
源码（未做实质性改动）
Bob原样保留NOTICE，在LICENSE中放了两个许可证：MIT许可证、Apache许可证。
Bob将这个作品命名为B，然后开始分发B。
这样，Bob从实质上把A从Apache许可证转成了MIT许可证。这意味着用B的人无需遵守Apache协议了，我们知道，MIT协议比Apache更宽松，现在，用B的人连修改哪了都不用说了。
Alice发现这个情况，说，“你这算什么啊，还有你这种骚操作？”
Bob说，“我怎么了，我违反哪一条了？”
从行为上看，B保留了A的版权信息，保留了许可证信息，声明了修改，保留了归属信息。这一切都遵循了Apach许可证的条款和条件。
Alice翻遍许可证，犀利地指出：
“根据第4节第5条，你只能对你修改的部分修改许可。”
Bob说：“那条还说了，我可以对整个衍生作品修改许可！”
Alice又翻了翻许可证，再次犀利地指出：
“根据第1节对衍生作品的定义，你这不是衍生作品！因为你没有原创性！”
Bob：“……”
Bob翻了翻许可证，说：“好吧，我这不是衍生作品，但我确实有权利修改这个文件，而且我对我修改的部分做了声明，我还保留了你的版权和归属，我的所有操作都没有违反Apache许可证要求。”
Alice：“……”
你怎么看呢。
也许ASF是允许这种情况的，具体要看ASF如何解释Apache许可证了。
为了遏制这种情况，A应该将自己的版权、仓库地址、License都放在NOTICE文件中。
这样，即便一个人拿到B，他也会知道B其实就是A，A的原License是什么，源代码在哪里。这个人可能会更倾向于直接使用A，毕竟A更正宗。
本文版权属于卫sir，采用CC-BY许可。（转载请保留此行）
https://www.kaggle.com/mrisdal/safely-analyzing-github-projects-popular-licenses
https://mp.weixin.qq.com/s/ipvkZYp_z8173-Q0SPCmDQ
JeffreyRobertKaufman:https://opensource.com/article/18/2/how-make-sense-apache-2-patent-license
薛亮：如何理解Apache2.0许可证中的专利许可条款？https://linux.cn/article-9402-1.html
http://www.apache.org/foundation/license-faq.html#PatentScope
https://opensource.stackexchange.com/questions/5508/what-does-and-contributors-in-the-copyright-byline-imply
https://www.hangfire.io/licensing/third-party.html
https://www.selenium.dev/documentation/en/front_matter/copyright_and_attributions/
?一文浓缩60年，程序员不可不知的开源秘史！
?CSDN总部落户长沙，共建中国开发者产业中心城市！
?AI修复100年前晚清影像喜提热搜，有穿越内味儿了！
?CycleGan人脸转为漫画脸，牛掰的知识又增加了！|附代码
?触发死锁怎么办？MySQL的死锁系列：锁的类型以及加锁原理了解一下！
?带血的战士|吴忌寒传
END，本文到此结束，如果可以帮助到大家，还望关注本站哦！