overview
1. Classification of open source licenses
There are two types of open source licenses: permissive and copyright.
1. Permissive: This type of license often only requires the licensee to retain the copyright information of the original work, and imposes fewer restrictions on users. Derivative software can become proprietary software, such as Apache, MIT, and BSD series licenses. This type of license is very popular because it allows closed-source derivative software and is very friendly to commercialization.
2. Copyright type (copyleft): also known as reciprocal type and strong protection type. It requires that the modification and expansion of the software must be open sourced according to the license obtained for the software. It aims to promote the cooperation of developers and protect the free sharing of source code, such as the GPL series license. For mandatory open source licenses, use with caution, because there have been many cases of prosecution for violating open source licenses. Further, it can be divided into strong copy right and weak copy right, the former includes AGPL, SSPL, GPL license, etc.; the latter includes LGPL series license, MPL license, etc. Strong copyright requirements require that the modification and expansion of the software must be open sourced in accordance with the license obtained from the software, and must not violate the restrictive terms of the original work. Weak copy right requires that the modification and redistribution of the software must be open source in accordance with the license of the software, but large works that incorporate these software codes can become private works.
2. Interpretation and compliant use of GPL, AGPL, LGPL and MPL licenses
Background note: For software developers, whether they are individuals or commercial organizations, in order to share their excellent works and expand their influence, they more or less want to make their software works public in the form of open source. But whether we are open-sourcing our own software or using open-source software, for commercial and legal considerations, we should all be clear: When we use open-source software or open-source our own works, what rights do we retain? What power have we given up?
The mainstream open source license agreements are as follows: GPL, LGPL, MPL, BSD, MIT, Apache License. From the dimensions of link dependence, source code modification, copyright statement, and whether source code software can be used for product advertisements, the looseness of the above mainstream open source protocols can be sorted out as shown in the following figure:
This article mainly introduces GPL, LGPL, AGPL, MPL and BSD, MIT, Apache
1. GPL license
1. Concept:
GPL, the GNU General Public License Agreement, is the abbreviation of GNU General Public License. It is a free software license published by the Free Software Foundation (FSF).
2. Version evolution history:
GPLv1: Released on February 25, 1989.
GPLv2: Released in June 1991.
GPLv3: Released on June 29, 2007.
3. Protocol features:
One of the biggest features of the GPL agreement is its contagiousness, that is, the GPL has mandatory inheritance requirements for the license, which is also the biggest difference in philosophy between the GPL and other licenses.
4. Rights and obligations:
The GPL stipulates that when using software that complies with the GPL agreement, the user's rights and obligations are as follows:
that power:
access to source code;
the right to modify the source code;
The right to freely process derivative works.
obligation:
If you use software released under the GPL agreement, you must also abide by the GPL agreement. This is why the GPL is called contagious.
The source code must be open; users are allowed to freely obtain (copy), modify, and publish products, that is, they have the freedom to obtain source code, modify source code, and distribute software.
5. Description of GPL freedom rights:
The terms and conditions of the GPL must be made available to anyone who accepts a copy of a work to which the GPL applies ("licensee").
Any licensee subject to the terms and conditions is entitled to modify the work, and to copy and redistribute the work or any derivative versions.
Software under the GPL can be used for all purposes, including commercial purposes, even as a tool for creating proprietary software, such as when using a GPL-licensed compiler, users or companies distributing GPL-licensed works such as software may charge for copies or provide them for free.
6. Analysis description:
The authorized person here can be understood as the author or organization that uses the work that complies with the GPL agreement software.
The third point distinguishes the GPL from software licenses that prohibit commercial redistribution, and from shareware licenses. The FSF believes that free software should not restrict commercial use and distribution (including redistribution). The GPL clearly stipulates that GPL works may be sold at any price.
Licensing depends only on the libraries and software components used, not on the underlying platform. For example, software running as an application under a GPL-licensed operating system such as Linux does not need to be licensed under the GPL or distributed with source code availability.
7. Official website:
https://www.gnu.org/licenses/gpl-3.0.html
2. LGPL license
1. Concept:
LGPL, the GNU Lesser General Public License, is the abbreviation of GNU Lesser General Public License. It is a free software license published by the Free Software Foundation (FSF).
2. Version evolution history:
The first version (2.0): Released in 1991, the first letter L is defined as Library, and the number of version 2.0 is adopted for consistency with GPLv2.
The second edition (2.1): Released in 1999, the first letter L is defined as Lesser, to show FSF's attitude that not all libraries should adopt this license.
Version 3 (3.0): Published in 2007, it manifests itself as a set of licenses applied in addition to version 3 of the GPL.
3. Protocol features:
LGPL is different from GPL. GPL requires that any software that uses/modifies/derived the GPL class library must adopt the GPL agreement. Unlike the LGPL, the LGPL allows commercial software to use the LGPL class library by citing (link) without requiring open source commercial software code. This enables the open source code using the LGPL agreement to be referenced, published and sold by commercial software as a class library.
4. Development and analysis of LGPL:
From the meaning of L in the first edition, which means Library and its version number are directly consistent with GPL (the first edition is 2.0), we can see that this agreement is a supplementary agreement to GPL, an open source agreement mainly designed for the use of open source libraries, because FSF has gradually realized that the mandatory contagion of the GPL agreement is too harsh in some scenarios, which will hinder the wider dissemination and use of open source products. When the second version of the GPL was released in 1991, the first version of the LGPL was released.
The meaning of LGPL can be understood as: it allows companies and software developers to integrate LGPL-licensed software into their own software in the form of dependent library links (even if the software is private software is allowed), and will not be restricted by licenses that are similar to the GPL infection characteristics. However, if the derivative code generated by modifying the code of the LGPL agreement, all the modified code, the additional code involving the modified part and the derived code must adopt the LGPL agreement.
Although the project using LGPL still has "Copyleft" restrictions, these restrictions will not affect the software that is only linked to this project. Therefore, the open source code of the LGPL protocol is very suitable for being referenced by commercial software as a third-party library, but it is not suitable for commercial software that wants to use the LGPL protocol code as the basis for secondary development through modification and derivatives. In order to achieve a compromise between GPL and other permissive licenses, LGPL is often used in some GNU program libraries, and can also be used in independent applications. The more famous examples are Mozilla and http://OpenOffice.Org .
3. AGPL License
AGPL (GNU Affero General Public License, Affero General Public License) license is a strong copyright license. This license can be said to be a "check for gaps" of the GPL. It inherits all the terms of the GPL and adds one more item on this basis: If the software under its license interacts with users through the network, then the source code must be provided to the user, and all modifications must also be provided to the user. AGPL and GPL agreements are compatible.
The original Affero GPL was released in 2002 based on GPLv2, and its publisher was not the Free Software Foundation, but a start-up software company called Affero. Later, the Free Software Foundation released its own version of AGPLv3 based on GPLv3 in 2007, and kept Affero in the name to pay tribute to this history. Currently, AGPLv3 is the most widely used version.
The obligations of the GPL are only triggered when the code is distributed. This is because "use" is not the focus of copyright, and copyright has been concerned with "copying" since its inception. From the English copyright of copyright, we can see that copyright has always been a right involving copying. There are no major problems in traditional industries, but under cloud services, cloud service providers no longer provide (distribute) copies of software to users. Therefore, cloud service providers can freely use GPL code without paying any form of cost, and all of this is legal. In response to the application service provider (ASP) loophole, the AGPL stipulates that the interaction through the remote network is also considered as "distribution", and the source code needs to be provided.
4. MPL License
1. Concept:
MPL, the Mozilla Public License, is the abbreviation of Mozilla Public License, developed and maintained by the Mozilla Foundation.
2. Version evolution history:
The first edition, version 1.0, was released in 1998.
The second edition, version 1.1, has major changes to clarify the terms of the patent section and to allow coexistence between multiple licenses.
The third edition, version 2.0, was released on January 3, 2012. This version makes the license agreement clearer and easier to apply, and is also compatible with the GPL and Apache licenses.
Starting from version 1.1, multiple licenses are allowed to coexist in projects that follow the MPL license. This feature is designed to encourage cooperation with developers who prefer to use the GPL license. The structure of the 1.1 version, its legal compliance, and its clear attitude towards patent rights have deeply influenced the later popular license agreement, which is a bit like the third version of the GPL. Many projects derive their own licenses from this, such as Sun Microsystems' General Development and Distribution License.
3. Protocol features:
The MPL allows source code under its license to be mixed with other licensed files, including private licenses, but code files under the MPL license must remain MPL licensed and remain open source.
It can be understood as: MPL-compliant projects allow users to re-develop and publish MPL works, but MPL parts and modified parts need to follow the MPL agreement and explain the modified parts, but private modules are allowed in derivative projects.
Such clauses make MPL neither allow derivative works to be completely private like MIT and BSD, nor require all derivative works including new components to maintain GPL like GPL.
In a word, the MPL agreement encourages commercial and open source communities to participate in helping to develop core software by allowing private modules to exist in derived projects while ensuring the open source of core files.
4. Development and application:
The MPL is both a free software license recognized by the Free Software Foundation (FSF) and an open source software license recognized by the Open Source Initiative (OSF).
The agreement combines the characteristics of the BSD license and the GNU General Public License agreement, and seeks to balance the concerns of developers of proprietary software and open source software.
The MPL is used for licensing Mozilla Firefox, Mozilla Thunderbird, and other Mozilla software, and is also used by other products such as Adobe's Flex product line license, and LibreOffice 4.0 (which also uses LGPLv3).
5. BSD License
1. Concept:
The BSD license agreement, short for Berkeley Software Distribution license, is an open source software license issued and maintained by the University of California, Berkeley. The BSD license is one of the most widely used licenses for free software.
2. Two concepts:
BSD: The BSD that people often say refers to Berkeley Software Distribution, that is, the Berkeley software suite. It is a packaged operating system and related software suite developed by the University of California, Berkeley based on the Unix operating system of AT&T Bell Labs.
BSD license agreement: The BSD suite is released under a certain open source license, which is named after this license and is called the BSD license.
3. Features of BSD protocol:
The BSD open source protocol is a protocol that gives users a lot of freedom. They can freely use and modify the source code, and can also republish the modified code as open source or proprietary software.
4. Version evolution history:
Old BSD: 1998 release of the first edition.
New BSD: A revision was released in 1999.
The first draft of the BSD agreement contained an additional clause requiring that all works derived from software licensed under the BSD license must include a paragraph explaining the source of the source code. This clause is listed in clause 3 of the original BSD license.
The GNU Project refers to this as "Uncomfortable BSD Interpretation Clause", and the GNU Project sees two problems:
First, people who modify the source code want to add their name to the acknowledgments, and if a project has a lot of people involved, or if the package contains many separate projects, the acknowledgments lineup will become very large.
Second, this conflicts with the GNU General Public License agreement. The GPL does not allow additional restrictions, so the software can only choose between GNU and BSD. Since these two licenses are commonly used in free software, if the author wants to combine GPL and BSD, conflicts will arise.
At the request of Stallman, the founder of the Free Software Foundation and the GNU Project, on July 22, 1999, William Hoskins, director of the Berkeley Office of Technology Licensing, removed Clause 3 of the BSD license. From then on, free software authors can easily use software under the BSD license to integrate with works under the GPL.
The original license is sometimes called "BSD-old" or "4-clause BSD" (four-clause BSD), and the current BSD license is sometimes called "BSD-new" (new BSD), "revised BSD" (revised BSD), or "3-clause BSD" (three-clause BSD).
5. Protocol analysis:
When publishing code using the BSD protocol or secondary development of your own products based on the BSD protocol code, the following three conditions must be met:
If the redistributed product contains source code, the source code must carry the BSD agreement in the original code.
If the redistribution is only a binary class library/software, you need to include the BSD agreement in the original code in the class library/software documentation and copyright statement.
The name of the author/institution of the open source code and the name of the original product cannot be used for marketing.
The BSD agreement encourages project code sharing, but the author's copyright needs to be respected. The BSD agreement is a very friendly agreement for commercial integration because it allows users to modify and redistribute the code, and also allows the development and sale of commercial software on the BSD code.
Many companies prefer the BSD protocol when choosing open source products, because they can completely control these third-party codes, and can modify or re-develop them when necessary. Software under the BSD agreement allows commercial use and even redistribution under an exclusive license.
6. MIT agreement
1. Concept:
MIT License Agreement: The MIT License, the name of the license agreement comes from the Massachusetts Institute of Technology (MIT), also known as "X License Agreement" (X License) or "X11 License Agreement" (X11 License).
2. Version evolution history:
1988, published by the Massachusetts Institute of Technology (MIT).
3. Protocol features:
The MIT License is one of many widely used software license terms. Compared with other common software license agreements (such as GPL, LGPL, BSD), MIT is a relatively loose software license agreement, which gives software licensees greater rights and fewer restrictions.
4. Protocol analysis:
Licensee's Rights: The Licensee has the right to use, reproduce, modify, merge, publish, distribute, sublicense and/or sell the Software and copies of the Software, and grant equivalent rights to the Licensee, subject to the following obligations.
Licensee Obligations: The above copyright notice and this license notice must be included in the software and all copies of the software.
5. Other important features:
This license agreement is not a copyleft free software license agreement, allowing the use of free and open source software or non-free software (proprietary software).
The content of MIT can be changed according to the needs of software code copyright owners, which is the essential difference between MIT and BSD.
The MIT License may coexist with other licenses. The MIT terms are also the terms of the free software license agreement recognized by the Free Software Foundation (FSF), and are compatible with the GPL.
Many groups adopt the MIT license, such as the well-known SSH connection software PuTTY and X Window System, Expat, Mono development platform library, Ruby on Rails, Lua, etc. also adopt the MIT license agreement.
7. Apache License Agreement
1. Concept:
The Apache License, or Apache License, is a free software license issued by the Apache Software Foundation (ASF).
Originally written for the Apache web server, the Apache License is widely used both within and outside the Apache community; all projects under the Apache Foundation use the Apache License; many non-Apache Foundation projects also use the Apache License.
Official website: http://www.apache.org/licenses/
2. Version evolution history:
Apache License 1.0, released in 1995.
http://www.apache.org/licenses/LICENSE-1.0
Apache License 1.1, released in 2000.
http://www.apache.org/licenses/LICENSE-1.1
Apache License 2.0, released in 2004.
http://www.apache.org/licenses/LICENSE-2.0
3. Agreement requirements:
The Apache license, the specific requirements are as follows:
The same license applies to all unmodified portions, and in each license file, any original copyrights, patents, trademarks, and attribution notices in redistributed code must be preserved (derivative works need not include any portion);
In each license file that is changed, a notice must be added stating that the file was changed.
It is not mandatory for derivatives and modifications to be released under the same license.
4. Protocol Analysis Description:
If the notice text file is published as part of the original work, the derivative work must contain a readable copy of the notice text file, either as documentation or displayed in the software.
The contents of the statement file do not modify the license, as they are for information only, and further attribution statements may be added to the license text, provided that such statements cannot be construed as modifying the license. Modifications may have appropriate copyright notices, and different license terms may be provided for modifications.
8. CC0 protocol
The Creative Commons Zero v1.0 Universal (Creative Commons CC0 1.0 Universal) agreement is a public domain contribution license issued by the Creative Commons (Creative Commons) organization, which states that the contribution of the work to the public domain, to the extent permitted by law, waives all his rights to the work based on copyright laws worldwide, including all related rights and neighboring rights.
Brief description of the terms
Under the CC0 license, you can:
commercial use
redistribute
Revise
private use
Among other things, the software:
Provide Limitation of Liability
Restricting the use of patents
Restricted Trademark Use
no guarantee
how to use
We recommend that you follow the guidelines of the CC0 ( creativecommons.org ) website, please note that this is not a registration process and Creative Commons will not store or save any information you enter. This tool guides you through the process of generating HTML with embedded metadata to mark your work as available under CC0. Your work will not be associated with or made available under CC0 unless you mark it for CC0 publication.
Creative Commons Licenses*
Creative Commons Licenses is a general term for a series of licenses issued by Creative Commons (Creative Commons), and we customarily refer to this series of licenses as CC licenses.
There are several editions and several variants of CC licenses. The 3.0 version is an early version, which is characterized by an unlocalized version (Unlocalized) as the starting point, and different versions have been formulated for the local laws of various countries and regions around the world (such as CC BY 3.0 China Mainland and CC BY 3.0 United States); in version 4.0, Creative Commons uses a unified legal document to replace multiple different localized legal documents of the previous version. Here, we mainly introduce the CC 4.0 version license.
Generally speaking, the CC 4.0 version license has the following six variants:
CC BY 4.0 International (Attribution 4.0 International, Attribution 4.0 International)
CC BY-SA 4.0 International (Attribution-ShareAlike 4.0 International, Attribution-ShareAlike 4.0 International)
CC BY-ND 4.0 International (Attribution-NoDerivatives 4.0 International, Attribution-No Derivatives 4.0 International)
CC BY-NC 4.0 International (Attribution-NonCommercial 4.0 International, Attribution-NonCommercial 4.0 International)
CC BY-NC-SA 4.0 International (Attribution-NonCommercial-ShareAlike 4.0 International, Attribution-NonCommercial-ShareAlike 4.0 International)
CC BY-NC-ND 4.0 International (Attribution-NonCommercial-NoDerivatives 4.0 International, Attribution-NonCommercial-NoDerivatives 4.0 International)
It can be seen that the CC license is generally an exchange of four main responsibilities, which are attribution, sharing in the same way, prohibition of derivation and non-commercial use.
They respectively mean:
Attribution: You must give appropriate attribution, provide a link to this license agreement, and indicate whether modifications (of the original work) have been made. You may use any reasonable means of attribution, but shall not in any way imply that the licensor endorses you or your use.
Share Alike: If you remix, transform, or create based on this work, you must distribute your contribution under the same license as the original license.
No derivative works: If you remix, transform, or create based on the work, you may not distribute the modified work.
Non-commercial use: You may not use this work for commercial purposes.
You can protect the related rights of your work by choosing to use one of these six licenses.
how to use
Again, we recommend that you follow the guidelines on the Choose a License ( creativecommons.org ) website to choose and use the CC license that suits you.
at last
This article is licensed under CC BY-SA 4.0.
Parts of this article are referenced from the official website of the Creative Commons organization, and they are redistributed and modified under the CC BY 4.0 license.
Summary: Comparison and summary of licenses:
For an open source agreement, if the regulations are too loose, the author will lose many rights to the open source software, and if the regulations are too strict, it is not conducive to the use and dissemination of open source software. Use a picture to summarize the loose permissions of several mainstream open source licenses introduced above:
The diagram below shows an overview of the compatibility of terms between common open source software licenses.
Note: apache2.0 is not compatible with GPL v2, but due to the unavoidable composition logic, apache2.0 can point to GPL v2
When we choose to use open source software, or prepare to open source our own software, we must understand our purpose and choose the appropriate license. I hope that while we stand on the shoulders of giants, we will not forget to use the weapon of law to protect ourselves.