Skip to Content
Last modified by chrisby on 2025/01/11 10:03
From version 2.113
edited by chrisby
on 2025/01/08 13:35
Change comment: There is no comment for this version
To version 2.111
edited by chrisby
on 2025/01/08 13:29
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -51,17 +51,12 @@
51 51  
52 52  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 if the AGPL code is essential for the software to work, then the software is considered a derivative work. For example:
53 53  
54 -* If a software needs AGPL source code directly, it is a derivative work. this means that using an AGPL licensed library or putting AGPL code directly into the project makes it a proprietary product.
55 -* Another example is when software uses an external AGPL service over the network.
56 - * If the AGPL service is not essential and is an optional addition to the software, then it is not considered a derivative work.
57 - * If the AGPL service is an essential or even mandatory part of the software, then it is considered a derivative work. For example, a vendor might come up with the idea to use AGPL code in his proprietary software, but out-source it into a shareable service accessible over a network, so that his proprietary software does not directly need the AGPL code, but does not work without it. The proprietary software is tightly coupled to the AGPL code. This is still considered a derivative work, so this attempt to bypass the AGPL is prevented by the license.
54 +If a software needs AGPL source code directly, it is a derivative work. this means that using an AGPL licensed library or putting AGPL code directly into the project makes it a proprietary product.
55 +Another example is when software uses an external AGPL service over the network.
56 +If the AGPL service is not essential and is an optional addition to the software, then it is not considered a derivative work.
57 +If the AGPL service is an essential or even mandatory part of the software, then it is considered a derivative work. For example, a vendor might come up with the idea to use AGPL code in his proprietary software, but out-source it into a shareable service accessible over a network, so that his proprietary software does not directly need the AGPL code, but does not work without it. The proprietary software is tightly coupled to the AGPL code. This is still considered a derivative work, so this attempt to bypass the AGPL is prevented by the license.
58 +This copyleft license ensures that when contributions are made to a copyleft project, or when copylefted code is reused directly 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.
58 58  
59 -This copyleft license ensures that when contributions are made to a copyleft project, or when copylefted code is reused directly 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 on rso that they can modify, build, and control the software themselves.
60 -
61 -he FSF primarily advocates copyleft licenses like the AGPL, which ensure that any derivative works of AGPL-licensed software remain under the same license. Although “derivative work” is a legally ambiguous term, a common view is that any software relying on AGPL code to function is a derivative work. For example, if a project directly includes AGPL source code or depends on an AGPL library, it must also adopt the AGPL—preventing it from being proprietary.
62 -
63 -A similar principle applies if software relies on an external AGPL service over a network. If that service is optional, the software is typically not considered a derivative work. However, if the service is essential and the software cannot function without it—even if it’s hosted elsewhere—the software is still considered a derivative work. These copyleft requirements ensure that modifications and enhancements remain open and that users can access, modify, and build upon the source code.
64 -
65 65  **License Preferences**
66 66  
67 67  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.