Conflict between "Commercial License" file and Apache 2.0 License
Opened this issue · 3 comments
Hi,
The issue began with the commit 445bb0d, which introduced the COMMERCIAL LICENSE file, imposing restrictions on the commercial use of the software. However, this file conflicts with the terms of the Apache 2.0 License currently applied to the project.
Apache 2.0 License Does Not Allow Commercial Restrictions:
The Apache 2.0 License is a permissive open-source/free software license that explicitly grants users the right to use the software for any purpose, including commercial use, without additional restrictions. By design, Apache 2.0 allows for modification, distribution, and use in proprietary or commercial applications.
As of now, the software distributed under this license still retains its full commercial-use freedom. Any attempt to impose commercial-use restrictions via a separate file, like COMMERCIAL LICENSE, does not change the terms of the Apache 2.0 License. These restrictions are legally invalid and do not override the freedoms granted by the Apache 2.0 License.
Therefore, attempting to impose such restrictions is legally meaningless. Once the software is licensed under Apache 2.0, it cannot be restricted by a separate file or policy.
Freedom of Software:
Restricting commercial use directly contradicts the principles of free and open-source software (FOSS). If the intention is to limit commercial use, the software is no longer "open" or "free" in the context of the open-source definition. Instead, it becomes software with source code available, but with commercial-use restrictions — which is fundamentally different from software licensed under a permissive open-source license.
If the goal is to impose such restrictions, the project should not be labeled as "open source" or "free software." It should instead be clearly stated that the project is source-available, with commercial-use limitations, and should be re-licensed under a different type of license.
Re-licensing Considerations:
To re-license the software under a new license (such as a non-open source/proprietary license), the permission of all contributors would generally be required. This is because the code contributed under the Apache 2.0 License remains under that license unless explicitly re-licensed with the agreement of the contributors.
If contributors have signed a Contributor License Agreement (CLA) that grants the project maintainers the right to re-license their contributions, then the re-licensing process could proceed without individual permission from each contributor. If no CLA has been signed, explicit consent would be needed from each contributor to change the license.
Hmmm super interesting, thanks for the heads up
yeah hmmm the idea is to keep 100% opensource and offer the same as a paid solution, but the problem to solve is many other companies selling the software as a SaaS without contributing back.. some of these even threatened me like "We are going to promote your software as ours so that we look like more official than yours" suggestions?
If your goal is to keep the project 100% free and open-source software (FOSS) while discouraging companies from exploiting your software as SaaS without contributing back, you might want to consider re-licensing under the GNU Affero General Public License (AGPL).
The AGPL is designed for scenarios like yours. It is a free software, copyleft license with a key provision in Section 13, which ensures that if someone uses your software over a network (e.g., SaaS), they are required to make the source code of the program, including their modifications, available to users of the software.
The GNU website explains it this way:
"This is a free software, copyleft license. Its terms effectively consist of the terms of GPLv3, with an additional paragraph in section 13 to allow users who interact with the licensed software over a network to receive the source for that program. We recommend that developers consider using the GNU AGPL for any software which will commonly be run over a network."
Using the AGPL would ensure that companies offering your software as SaaS are required to share their changes or enhancements to the software with the community, leveling the playing field and maintaining the ethos of free and open-source software.