It is not uncommon for open source licenses to change. When licenses change, users often need to re-evaluate compliance risks. Take Redis as an example. Redis is a popular key-value store whose open source license has undergone changes from BSD to SSPL and then to AGPL, which has caused widespread discussion and controversy in the open source field. Everyone regards the change of Redis from SSPL license to AGPL license as a victory for the “open source spirit”, but there is a lack of discussion on the legal issues related to Redis’s behavior.
Does Redis have the right to change its license?
The Redis software code includes contributions from both the Redis company itself and other developers in the open source community. Redis owns the copyright to its contributions, so Redis has the right to decide how to license them; For other developers’ contributions, according to the Contributor License Agreement (CLA) of Redis, developers also license their copyrights and patents to Redis. Therefore, Redis also has the right to combine these developers’ contributions with its own contributions for external licensing and have the right to decide how to license.
That is to say, although the code source of Redis software is relatively complicated, legally speaking, Redis has the right to change the license. Even if Redis chooses to commercially close the source of the software, it is Redis’ freedom, which is understandable.
Is Redis’s license change a breach of contract?
The Redis software was originally released under the BSD license, which is a permissive open source license and is not viral. This means that whether Redis itself or any other company or individual modifies and redistributes the software under the BSD license, as long as it does not violate the licensing conditions of the BSD license, they are free to choose new licensing conditions. Even commercial proprietary licensing is allowed. This is also why BSD is considered business-friendly.
In the process of Redis changing the BSD license to the SSPL license, even if the new version is developed entirely based on the software version under the BSD license, the release of the new software version under the SSPL license does not violate any licensing conditions of the original BSD license and therefore will not constitute a breach of contract. Similarly, the change of Redis 8 to AGPL license does not constitute a breach of contract.
Is it true that a license not recognized by OSI is not binding?
Whether it is an open source license or a general commercial license, it is essentially a contract between the copyright owner and the user. As long as the contract does not fall under the circumstances of invalidity, revocation, or ineffectiveness stipulated by law, then the contract is binding.
The nature of OSI is a non-profit organization, not a judicial tribunal. Its recognition of whether the open source license meets its standards is more of a professional recommendation and is not legally mandatory. That is to say, although SSPL is not recognized as an open source license by OSI, this does not affect the binding force of the SSPL license on copyright owners and users.
Summary
Although many people stand in the perspective of open-source spirit to accuse Redis of improper use of SSPL license, legally speaking, Redis’s change of license is a legal act. Users who use software versions under different licenses must be bound by the corresponding licenses.
How can companies reduce the risks of open source license changes?
Many companies stay in a static management state when using open source software, thinking that as long as they meet the conditions of the current open source license when downloading the open source software, then they can rest assured. In the subsequent version update process, it is often easy to ignore the new licensing conditions brought about by the changes in the open source license. Therefore, it is easy to cause infringement due to non-compliance with the new licensing conditions when using the new software version.
For the risks brought to enterprises by similar behaviors such as Redis license changes, the three major capabilities of “full life cycle monitoring”, “controllable update risks” and “community intelligence linkage” should be implemented through tool chain and manual collaboration to transform risks from “passive remediation” to “proactive prevention”.
Build a continuous monitoring system of “dynamic scanning + intelligence linkage”
Enterprises can force all introduced open source components (including direct and indirect dependencies) to generate full SBOMs that comply with the CycloneDX or SPDX standards, clearly recording component names, versions, license types, download sources and dependency levels, such as clearly marking Redis 6 for BSD licenses and Elasticsearch 7 for Apache 2.0 licenses. At the same time, SBOM generation tools are embedded in code repositories such as GitLab/GitHub and build tools such as Maven/Gradle to ensure that SBOM is automatically generated and updated when code is submitted or packaged, avoiding omissions of manual maintenance.
Enterprises should also store the license information (such as BSD, MIT) for components upon their initial introduction into the “license baseline” library. Every time a component is updated or the code is built, scanning tools can be used to automatically compare the differences between the current license and the baseline library. Once high-risk changes are found (such as BSD converted to AGPL, Apache 2.0 converted to SSPL), alarms can be pushed to the technical person in charge immediately.
At the same time, for open source projects that companies rely heavily on, such as Redis, Kubernetes, and Elasticsearch, we actively connect to open source supply chain intelligence platforms to obtain license change signals in the first place, leaving sufficient time for companies to prepare for response.
Create a version update control process of “evaluation-verification-rollback”
Enterprises can avoid the high risk of license changes in version updates through the version update control process to control the scope of influence. Before updating, the technical team needs to evaluate compatibility based on SBOM and scan results, determine whether the new license (such as AGPL) conflicts with the company’s closed-source code and affects commercial services, use vulnerability scanning tools to verify whether high-risk vulnerabilities in old versions (such as Redis 6) can be repaired, and verify the API compatibility, performance and data migration difficulty of alternative components such as KeyDB through alternative technology assessment and form a report.
In the update, a “gray release ” strategy is used to verify compliance in the test environment first, then pilot it on a small scale in non-core scenarios, reserving rollback channels. If compliance issues such as AGPL are triggered, the old version can be switched back within 10 minutes.
If the old version is used for a long time, a maintenance team needs to be formed to track vulnerabilities and fix high-risk issues every week, make necessary-only modifications to the old version to avoid new risks, evaluate performance bottlenecks and compatibility every quarter, determine whether to start alternative migration, and prevent technical rigidity.
Implement the proactive prevention strategy of “community participation + internal reservation”
The license change come with signs, and companies can also turn “passive response” into “active layout” by participating in the community and stockpiling alternatives.
For the top 5 open source projects (such as Redis and Kubernetes) that enterprises rely on, we will form a technical team to deeply participate in the community, submit PRs to fix bugs, join working groups and participate in GitHub Issues discussions, focusing on issues related to license changes. When the community mentions adjusting the license, we will proactively put forward transitional suggestions such as “6 months’ notice” or strive for an exemption allowing “retaining the old license for internal non-commercial use” to reduce the impact of changes.
At the same time, an internal open source alternative library can be built according to “license type + technical compatibility”, reserve permissive licenses (such as KeyDB under the BSD/MIT protocols replacing Redis under the AGPL protocol), Weak Copyleft and commercial license alternatives are reserved in a hierarchical manner. The API consistency tests, performance stress tests and data migration tests of each alternative are completed in advance, and the results are stored in the knowledge base for quick call.
