Wiki source code of 3. Free Software and Open Source Software
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | There are two major philosophical movements that offer an alternative to strictly protected, also called "proprietary" software: the Free Software movement, primarily represented by the **Free Software Foundation, or FSF** for short, and the Open Source movement, primarily represented by the **Open Source Initiative, or OSI** for short. Note that the "free" in free software stands for "freedom" in a broad sense, not just "free of charge", but we will come back to that soon. | ||
2 | |||
3 | ### Common Principles | ||
4 | |||
5 | Both the FSF and the OSI have their own requirements that a software license must meet, but the results are very similar. For simplicity, we can assume that the set of free software licenses approved by the FSF and the set of open source licenses approved by the OSI are approximately equivalent. I will refer to them collectively as "open source licenses" because the term is more common than "free software licenses". | ||
6 | |||
7 | On the other hand, the FSF requirements for open source licenses are leaner and easier to understand than the OSI requirements. Therefore, the FSF requirements are discussed here. The FSF defines that open source licenses must guarantee four essential freedoms: | ||
8 | |||
9 | **1. Freedom to run the program as you wish, for any purpose.** | ||
10 | |||
11 | **2. Freedom to study how the program works and change it to make it do what you wish.*** | ||
12 | |||
13 | * This means that you can read and modify the source code. | ||
14 | |||
15 | **3. Freedom to redistribute copies.** | ||
16 | |||
17 | * This means that you can share executables with anyone, such as giving it to a friend or making it publicly available on the Internet. | ||
18 | |||
19 | **4. Freedom to distribute copies of your modified versions to others.*** | ||
20 | |||
21 | * This is a combination of freedoms 2 and 3. You can modify the source code, build the executable, and share it with anyone. | ||
22 | |||
23 | *Although not explicitly stated, freedom 2 and 4 imply that the source code must be available. Any software license that does not fully grant each of these four freedoms, even with minor violations, is not considered open source. There is a clear distinction between open source licenses and all other licenses that do not meet these requirements, which are called "proprietary licenses". These proprietary licenses can range widely in terms of strictness, and some can even be quite close to open source. But proprietary licenses always violate at least one of the four freedoms. | ||
24 | |||
25 | This means that access to the source code does not necessarily mean that the software is open source. This is a common misconception. To be open source, the code must be available, and there must be a license that grants all four freedoms. | ||
26 | |||
27 | The open source definition shifts power to the user: | ||
28 | |||
29 | * Blackboxing is no longer possible because anyone can view the source code and check for malicious parts. If users find any, they can simply remove the malicious code and build a safe version of the software. | ||
30 | * Also users are no longer trapped in vendor lock-in because they can "fork" the project at any time. This means they can clone the source code and continue development on the project independently. The idea is that if there is a conflict with a vendor of an open source product, either the community or another vendor can clone the code, take over and provide better service. In this way, the project has long-term sustainability and fair user conditions. | ||
31 | |||
32 | ### Differences between FSF and OSI | ||
33 | |||
34 | Both, the FSF and the OSI see the problems with proprietary code and want to promote open source. But they have different approaches to achieving that goal. | ||
35 | |||
36 | **Permissive Licenses** | ||
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. | ||
39 | |||
40 | **FSF Position** | ||
41 | |||
42 | The FSF sees several problems with permissive licenses: | ||
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 is 99% open source code, the remaining 1% proprietary portion may contain all the malicious code. This means that the partially open source product poses the same dangers as a 100% proprietary product. Only 100% open source code running on your own machine is a necessary condition for achieving freedom and security. | ||
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, because the proprietary product has improvements, it may outcompete the original open source project, reducing its impact and harming the open source ecosystem. Vendors can trick users into joining their proprietary software, and once the original project is technically left behind and users are dependent on the proprietary software, the vendors have the power to commercialize their efforts under their terms through sharply increasing prices, etc. A common term for this process is the "free-rider" problem. | ||
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 | |||
48 | **Copyleft Licenses** | ||
49 | |||
50 | To address the problems with proprietary software, the FSF primarily promotes copyleft licenses, which require that any derivative works of the software be licensed under the same terms as the original code. The term "derivative work" is legally somewhat vague, but a common understanding is that it means a new work based on the original copyleft code that incorporates it at the source level. This ensures that when contributions are made to a copyleft project, or when copyleft code is directly reused in another project, the resulting work must be released under the same copyleft license. This prevents vendors from incorporating copyleft code into proprietary products, and ensures that any derivative works remain open source. In addition, copyleft licenses require that the source code be made available to users so that they can modify, build, and control the software themselves. | ||
51 | |||
52 | **License Preferences** | ||
53 | |||
54 | The OSI aims to maximize the contributions and impact of open source by being open to all open source licenses. Permissive licenses have become very popular in recent years, especially in commercial contexts, but the OSI is open to choosing copyleft licenses if developers want to ensure that derivative works remain open and free. The FSF, on the other hand, tolerates all open source licenses, but has a strong preference for copyleft licenses, believing that all software should be protected in this way. | ||
55 | |||
56 | **User Behavior** | ||
57 | |||
58 | Open source supporters tend to be more accepting of proprietary software and external hardware where it makes sense. In contrast, free software supporters typically avoid proprietary software and seek to maintain full control over their hardware and data. While free software supporters prioritize self-hosting and control, they may use third-party services for public data, provided that the software used respects their principles. | ||
59 | |||
60 | ### Common Questions | ||
61 | |||
62 | **Do permissive or copyleft licenses provide the most freedom?** | ||
63 | |||
64 | * The answer depends on your definition of freedom. Permissive licenses emphasize freedom of choice, allowing you to do whatever you want with the code, including reusing it in proprietary products. Copyleft licenses emphasize user freedom in a more political sense by ensuring that derivative works remain free and open, and by protecting users from proprietary restrictions that could violate the four essential software freedoms. Thus, permissive and copyleft licenses provide freedom, but they focus on different aspects of it. | ||
65 | |||
66 | **Does a permissive or copyleft project lead to more contributions?** | ||
67 | |||
68 | * Permissive licenses might attract more users, especially vendors, and lead to more voluntary contributions. Copyleft licenses, on the other hand, force improvements to be open sourced and shared with the community. Which effect is greater depends on the situation. | ||
69 | |||
70 | **Why should people with no technical expertise care about open source? Speaking of people who cannot even read the source code.** | ||
71 | |||
72 | * Even if you do not have the expertise to examine or modify the source code yourself, open source software allows you to hire specialists to adapt the software to your needs. The main benefits are the protection of personal data or intellectual property and reduced dependency on a single vendor. Therefore, from a purely profit-driven perspective, choosing open source may be the more economical option. |