Is Open‑Source Software Still Truly ‘Domestic’? Understanding Licensing Risks

Open‑source reliance in Chinese IT infrastructure

Chinese vendors entered the IT‑infrastructure market later than many global competitors, so they frequently adopt existing open‑source projects to accelerate development. This practice is technically necessary but introduces licensing risk when upstream projects change their terms.

Case study: GBASE 8A

The distributed data‑warehouse product GBASE 8A incorporated the standard‑edition source code of Inforbright. Around 2015 Inforbright altered its license, converting the code to a closed‑source model. Despite this change, GBASE 8A continued to grow its market share, indicating that the vendor had re‑engineered the storage engine and was no longer dependent on the original open‑source code.

Other notable license transitions

Redis – In 2019 Redis introduced a proprietary RSAL license for certain high‑level modules while keeping the core server under the Apache 2.0 license.

MongoDB – Shifted from the SSPL (a source‑available license) to a commercial license after a financing round.

Elasticsearch – Moved from the Apache 2.0 license to the Elastic License, also tied to fundraising and IPO activities.

These changes are driven by business objectives (e.g., shareholder profit) rather than malicious intent, but they illustrate the volatility of open‑source licensing when a single corporate entity controls the project.

Risk assessment when selecting open‑source components

When evaluating a dependency, consider the governance model:

If a project is primarily maintained by one company and the core code resides under that company’s control, the probability of a future license change is higher.

Community‑driven projects with diverse maintainers and no dominant corporate sponsor present a lower risk of sudden relicensing.

Linux distributions and GPL compatibility

The most widely used Linux distributions are technically GNU/Linux – a combination of the Linux kernel (a relatively small code base) and the GNU system (the surrounding user‑space tools and libraries). Contributions to the kernel and GNU components are accepted only if their licenses are compatible with the GNU General Public License (GPL). Consequently:

Any attempt to relicense a GPL‑compatible component under an incompatible license would be rejected by the maintainer community.

If a component were relicensed incompatibly, the community would quickly develop or adopt an alternative implementation.

Therefore, a wholesale shift of GNU/Linux away from GPL is extremely unlikely.

Enterprise responsibilities in an open‑source ecosystem

Contribute high‑quality upstream code to increase influence and reduce dependency on external vendors.

Strictly honor the licenses of all incorporated open‑source components; failure to do so can lead to being black‑listed by the community.

Maintain a support model comparable to established vendors (e.g., Red Hat’s RHEL) that provides timely patches and assistance, rather than merely repackaging upstream code without service commitments.

By actively participating in upstream development and offering reliable support, domestic vendors can move beyond “shell‑wrapping” open‑source projects and foster a sustainable ecosystem.