GPL（GNU General Public License）
No matter how you use me, you have to be open source and free like me, please be careful if you want to sell money, buddy is just like that!
The main content of the GPL agreement is that as long as the product of the GPL agreement is used in a software ("use" refers to the class library reference, modified code or derivative code), the software product must also adopt the GPL agreement, which must be open source and free . This is called "contagion". The product under the GPL agreement can be used as a separate product without any problems, and can also enjoy the advantages of free.
Since GPL strictly requires that software products using GPL class libraries must use the GPL protocol, for open source code using the GPL protocol, commercial software or departments that require confidentiality of the code are not suitable for integration/adopting as the basis for class libraries and secondary development .
LGPL（GNU Lesser General Public License）
You can use me, but if you change me, please make the open source you change free of charge, buddy has a bottom line!
LGPL is an open source license of the GPL designed primarily for class library use. It is different from the GPL requirement that any software that uses/modifies/derives the GPL class library must use the GPL license. The LGPL allows commercial software to use the LGPL class library through the class library reference (link) method without the need for open source commercial software code. This enables open source code using the LGPL license to be referenced and distributed and sold by commercial software as a class library.
However, if the code or derivative of the LGPL agreement is modified, all the modified code, additional code and derivative code involving the modified part must adopt the LGPL agreement. Therefore, the open source code of the LGPL protocol is very suitable for being referenced by commercial software as a third-party class library, but it is not suitable for commercial software that hopes to use the LGPL protocol code as the basis for secondary development through modification and derivation.
Apache Licence 2.0（Apache License, Version 2.0、Apache License, Version 1.1、Apache License, Version 1.0）
Feel free to use it, but please bring the same contract as mine when you post it. By the way, if you change it, I have to indicate it, buddy is a kind and righteous person!
Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和BSD类似：
- 需要给代码的用户一份Apache Licence
- 如果你修改了代码，需要再被修改的文件中说明。
- 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
- 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。
- Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
BSD开源协议（original BSD license、FreeBSD license、Original BSD license）
随便用吧，但请注意，你要是发布了有源码请把我的协议复制到你的代码中，如果没有那么把协议复制到你的申明中，另外友情提示，别拿我的名号做广告噢，哥们喜欢低调！
BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
但”为所欲为”的前提当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：
如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD 代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。