Open-Source Dependency Stewardship Continues After Adoption

Adopting an open-source dependency does not end technical due diligence. The code remains available under the licence attached to the version in use, but the services, organisations, maintainers, and legal conditions around it may change. Drupal delivery teams therefore need continuing records and continuity plans for the software on which their work depends.

For Drupal agencies and site owners, much of this responsibility sits around Drupal rather than inside Drupal core. Modern delivery commonly relies on PHP packages, JavaScript libraries, databases, build systems, source-code platforms, cloud infrastructure, and managed hosting. Each choice carries assumptions about access, licensing, maintenance, security response, support, and replacement options.

Hosted repository access is one such assumption. GitHub’s trade-control documentation states that use of GitHub.com remains subject to applicable law, including United States export-control and sanctions rules. Some restricted parties, officials, organisations, and uses may therefore be denied access.

This is a condition attached to a hosted platform rather than to open-source development itself. Distributed teams should nevertheless maintain appropriate repository exports, mirrors, credential procedures, and deployment-continuity plans instead of assuming that one commercial service will always remain accessible under the same conditions.

Licensing can also change after a tool has become part of an organisation’s delivery process. HashiCorp announced on 10 August 2023 that future releases of several products would move from Mozilla Public License 2.0 to the Business Source License. APIs, software development kits, and most libraries remained under Mozilla Public License 2.0.

The Business Source License makes source code available but permits specified use restrictions before a release converts to another licence. Teams should therefore distinguish source availability from an open-source licence and record the terms attached to the version they actually deploy.

Redis announced on 20 March 2024 that Redis 7.4 would move from the BSD three-clause licence to the Redis Source Available License version 2 and Server Side Public License version 1. Redis later added GNU Affero General Public License version 3 as an additional option for Redis 8.

Redis’ current licensing information states that Redis 7.4 to 7.8 remain under the source-available dual licence, while Redis 8 and later are available under a choice of RSALv2, SSPLv1, or the OSI-approved AGPLv3. The sequence illustrates why architecture and procurement records should identify both the version and the applicable licence instead of relying on a product’s historical reputation.

Open-source governance can provide a route forward when commercial licensing changes. The Linux Foundation announced OpenTofu on 20 September 2023 as an open-source alternative to Terraform under neutral, community-oriented governance following HashiCorp’s licensing decision.

A successor project preserves choice, but migration still requires work. Teams need to assess compatibility, provider support, documentation, governance, release continuity, internal skills, and client acceptance. These are ordinary architecture and maintenance considerations, not arguments against open-source alternatives.

You May Like

Blog

The Letters That Changed Everything: How The DropTimes Discovered Its Voice Through Typography

Blog

The Letters That Changed Everything: How The DropTimes Discovered Its Voice Through Typography

Maintainer capacity is another part of dependency planning. In a Thoughtworks analysis published in July 2026, Chris Ford and Richard Gall argue that software may be inexpensive to distribute while remaining costly to maintain. They recommend that organisations be prepared to audit, patch, fund, contribute to, fork, or replace dependencies when necessary.

That is practitioner guidance rather than a legal requirement, but it identifies a practical imbalance. Organisations may derive substantial value from shared software while its maintenance depends on a small company, foundation, volunteer group, or individual maintainer. Dependency planning can therefore include contribution, funding, testing, documentation, and upstream collaboration as well as replacement options.

Regulation is making some dependency information more formal. The European Union’s Cyber Resilience Act establishes cybersecurity requirements for products with digital elements made available on the European Union market. Reporting obligations apply from 11 September 2026, and the main obligations apply from 11 December 2027.

The Act has specific provisions for free and open-source software. European Commission guidance on open source under the CRA says that FOSS supplied outside commercial activity is not within the Act’s market scope. It also says that developers contributing code to FOSS that is not under their responsibility are not covered merely because they contributed.

The CRA separately recognises open-source software stewards: legal persons that provide sustained support for qualifying FOSS intended for commercial activities and play a main role in its viability. Those organisations have tailored cybersecurity, cooperation, and reporting duties, but the Commission says they are not subject to administrative fines under the Act.

The CRA therefore does not turn every Drupal contributor, agency, or website operator into a manufacturer or open-source software steward. The applicable role depends on what is supplied, how it is made available, who controls it, and whether the activity falls within the regulation’s commercial scope. Organisations that may place affected products on the market should obtain advice appropriate to their circumstances.

Continuing dependency governance begins with accurate knowledge. Teams should record the deployed version and licence, the maintainer or governing body, the source and release infrastructure, the security-response process, the available support, and practical continuity options. They should also understand which evidence clients, auditors, insurers, or regulators may later request.

For Drupal teams, this work belongs in architecture reviews, maintenance agreements, procurement decisions, and long-term support plans. Open collaboration remains one of Drupal’s central strengths, and the wider FLOSS ecosystem makes modern delivery possible. Good dependency governance helps preserve those benefits by distinguishing open code from the hosted, commercial, and institutional conditions surrounding it.

The durable question is not whether open-source software is safe or risky in the abstract. It is whether an organisation understands its dependencies, supports sustainable maintenance where practical, and can respond responsibly when an upstream condition changes.