Last modified by chrisby on 2025/01/11 10:03

From version 2.72
edited by chrisby
on 2025/01/08 11:03
Change comment: There is no comment for this version
To version 2.71
edited by chrisby
on 2025/01/08 11:01
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -35,13 +35,13 @@
35 35  
36 36  **Permissive Licenses**
37 37  
38 -There are permissive open source licenses that have little legal complexity. Simply put, the legal position is "do whatever you want with the code". Permissive code is particularly attractive to vendors because it avoids legal complications and they can easily reuse it in their own proprietary products. Both of these aspects are designed to encourage vendors to use the code. The idea is that, in return, vendors have an interest in ensuring that the code they reuse has the features they need and is well maintained. This increases the chances that they will contribute back to the project.
38 +There are permissive open source licenses that have little legal complexity. Simply put, the legal position is "do what you want with the code". Permissive code is attractive to vendors because it avoids legal complications, and they can easily reuse it in their own proprietary products. Both of these aspects are designed to encourage vendors to use the code. The idea is that, in return, vendors have an interest in ensuring that the code they reuse has the features they need and is well maintained. This increases the chances that they will contribute back to the project.
39 39  
40 40  **FSF Position**
41 41  
42 42  The FSF sees several problems with permissive licenses:
43 43  
44 -* Permissive code allows vendors to include it in their proprietary products. Software that is partially open source does not necessarily make it more secure. For example, in a product that consis 99% open source, the remaining 1% proprietary part may contain all the malicious code. This means that the partially open source product poses the same dangers as a 100% proprietary product. 100% open source code running on your own machine is a necessary condition to achieve freedom and security.
44 +* Permissive code allows vendors to include it in their proprietary products. Software that is partially open source does not necessarily make it more secure. For example, in a product that is 99% open source, the remaining 1% proprietary part may contain all the malicious code. This means that the partially open source product poses the same dangers as a 100% proprietary product. 100% open source code running on your own machine is a necessary condition to achieve freedom and security.
45 45  * Another problem is that vendors can reuse permissive code without any obligation to share improvements. The vendor writes new proprietary or closed source code based on the open source code and keeps those improvements for himself. This means that the work of the open source community can be used for the vendor's financial benefit without anything being given back. Worse, the proprietary product may outcompete the original open source project, reducing its impact and harming the open source ecosystem. This is called "proprietary capture" or "open core hijacking".
46 46  * There is also the problem of fragmentation. Multiple vendors may each create their own proprietary product based on the same permissive code. Instead of collaborating and contributing back to the common core project, they are inefficiently duplicating their efforts.
47 47