dgtlmoon / dgtlmoon/changedetection.io

Conflict between "Commercial License" file and Apache 2.0 License

Open
#2,806 3 comments 0 reactions 1 assignee Claimed by @dgtlmoon View on GitHub
triage
Dominant language
Python
Stars
34.1k
Forks
2k
Avg merge
23h 38m
Merged PRs (30d)
67

Description

Hi,

The issue began with the commit https://github.com/dgtlmoon/changedetection.io/commit/445bb0dde3852fff8f33ab467092c3da3b8b9b62, 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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.