Shifts in open source licensing and the emergence of forks such as Valkey from Redis present several challenges for companies, especially those heavily reliant on these technologies for their operations. To navigate the changes effectively, companies must approach these situations with a strategy that considers operational, legal, and ecosystem impacts.
Fragmentation and Compatibility Concerns
When a popular open source project like Redis forks, it leads to fragmentation in the technology ecosystem. Companies using these tools face tough decisions about which version to support—stick with the original, which might have more restrictive licensing, or switch to a new fork, which might not yet have proven stability or feature parity. This division can lead to compatibility issues between systems that depend on different versions of the same tool, complicating integration efforts and maintenance.
These examples illustrate how companies across various industries have navigated the complexities introduced by open-source licensing—whether through strategic shifts, compliance with legal requirements, or in response to community pressure. Each case underscores the importance of understanding and adapting to open-source licenses to maintain software integrity, legal compliance, and community trust.
Redis – the popular in-memory data store, shifted its licensing from the open-source BSD license to a dual licensing model under the Redis Source Available License (RSALv2) and the Server Side Public License (SSPLv1). This change aimed to prevent large cloud service providers from offering Redis services without entering into a commercial agreement or contributing back to the community.
MongoDB – moved from the AGPL to the SSPL to address challenges with cloud-based services offering MongoDB as a service without contributing back to the community. This shift aimed to ensure that companies using MongoDB to provide services would also share any modifications and enhancements under the same terms.
Elasticsearch (Elastic) – Changed from Apache 2.0 to SSPL and Elastic License to control commercial usage by cloud providers.
Linksys (Cisco Systems) was forced to release the source code for its routers under the GPL due to its use of Linux.
Samsung – Released source code for parts of its Galaxy device firmware to comply with GPL.
Sony – Open-sourced its Recovery software for Xperia devices following community pressure.
HTC – Released source code for Android device kernels under GPL obligations.
Netgear – Regularly releases router firmware source code to comply with GPL.
Xiaomi – Published kernel source code for various smartphones due to GPL compliance.
Skype (before Microsoft acquisition) – Released Skype protocol source code due to allegations of GPL license usage.
Tesla – Open-sourced car software to comply with open-source licenses used in their vehicles.
Microsoft – Open-sourced .NET Core as part of a strategic shift towards more open development ecosystems.
Ghostscript – Transitioned to AGPL to prevent proprietary use without contribution.
Tivo – The concept of “Tivoization” led to changes in GPL version 3 to prevent restrictions on user modifications.
RethinkDB – After the company’s shutdown, the database was open-sourced under Apache 2.0, driven by community and former employees.
Qt – Has shifted licenses multiple times, navigating between GPL, LGPL, and commercial licenses.
Samsung – Several instances of GPL compliance for its television and other device firmware.
Support and Reliability
A new fork might need a more robust community and commercial support from which established projects can benefit. For businesses, this translates into concerns over reliability—whether the fork can sustain long-term development and handle security patches effectively. While forks backed by major players like the Linux Foundation promise a certain level of credibility and support, there’s always an element of risk in the early stages of any new project.
Operational and Financial Overhead
Switching to a fork can be costly. It often involves immediate technical adjustments and testing. This often involves significant updates to the codebase to ensure compatibility. For instance, dependencies that the original software relied on might not be supported by the fork, or the fork might introduce new features and changes incompatible with existing customizations. This can lead to extensive testing cycles to debug and verify that the new software performs as expected without disrupting ongoing operations.
Adopting a fork requires updating training materials and sessions for developers and IT staff to familiarize them with the nuances of the new system. This is crucial as differences in functionality, APIs, and operational commands between the original software and the fork can lead to productivity gains if the team is adequately trained. Furthermore, new documentation must be created and disseminated to ensure that all team members are on the same page, which entails additional time and costs.
If the fork diverges significantly from the original project’s roadmap, it can complicate maintenance and support. If the fork does not have a robust community or commercial support, the organization might find itself responsible for patching bugs and handling security vulnerabilities independently. This increases the workload for internal teams and may require hiring external experts or consultants to ensure the system remains secure and functional.
Legal and Compliance Risks
New licenses can introduce new compliance challenges. Companies must understand and navigate the legal implications of the license under which the fork is released. Failing to comply with these can expose a company to legal disputes or violations, which might carry fines or damage the company’s reputation.
Navigating these licensing changes requires a proactive approach to keep abreast of any updates in open-source licensing terms that could impact their operations.
Strategic Uncertainty
A fork can introduce strategic uncertainty for companies invested in the ecosystem of a particular open source tool. Decisions need to be made about investing in a new, potentially untested fork versus staying with a more restrictive but established software version. These decisions can have long-term impacts on the company’s technology strategy and its alignment with business goals.
In addition to internal education and community engagement, companies should implement robust compliance solutions. Threatrix can automate the tracking and management of licenses across software projects, helping to identify potential compliance issues before they escalate into legal problems. This is invaluable for companies that depend on multiple open-source projects, each potentially under different licenses, which may change over time.
Effective compliance also means investing in legal expertise—either in-house or external. This investment ensures that the company can receive timely and accurate advice on interpreting complex licensing agreements, particularly those with ambiguous or untested clauses. Legal advisors can offer strategic guidance on negotiating license terms and managing relationships with open-source contributors and other stakeholders.
Split in the Developer Community
A vibrant developer community is critical to open-source software’s ongoing improvement and security. This division can dilute the talent pool, as the efforts and expertise once concentrated on enhancing a single project are now spread across multiple initiatives. Resources such as developer time, funding, and community attention become fragmented, which can reduce the efficiency and effectiveness with which improvements and updates are applied to each project. This can leave software more vulnerable to bugs and security gaps, impacting all users, especially businesses that rely on the software for critical operations.
While forking can be a mechanism for addressing disagreements or directional shifts within an open-source project, it carries substantial risks. Those considering initiating or supporting a fork must weigh these potential impacts carefully, particularly regarding community health, innovation pace, security measures, maintenance efforts, and the project’s long-term sustainability. Understanding these dynamics is essential for businesses to make informed decisions about which projects to support and rely on for their critical operations.
Threatrix can significantly aid businesses in navigating the complexities associated with managing forks. Threatrix provides comprehensive open source licensing monitoring and analysis capabilities to assess the health and security of original projects and their forks. By integrating Threatrix companies can gain valuable insights into the stability and progress of open-source software, allowing them to proactively address security risks and ensure compliance with relevant licenses. This approach helps maintain the integrity of the software supply chain and makes strategic decisions that align with the organization’s goals and risk management practices.
