Examine the governance jurisdiction of the third-party components you use in your professional projects#
What this is, concretely#
This commitment consists of systematically examining, for each professional project you start or take over, the governance jurisdiction of the third-party components you use. Concretely, this means opening the package.json, the requirements.txt, the Cargo.toml, the go.mod, the pom.xml, or the equivalent, identifying the substantial dependencies, and documenting for each the publisher or foundation that governs it, its jurisdiction, and its model (single-vendor, neutral foundation, proprietary).
The commitment does not require an analysis of every transitive dependency — it targets the substantial components you have consciously chosen and whose failure or licence flip would have a real impact on the project. The documentation may take the form of a “third-party components” section in the project README, of a separate DEPENDENCIES.md file, or of a structured comment in the architecture documentation.
The commitment stands as an individual declaration. It bears on your professional projects (clients or employer) to the extent that you have control or influence over the choice of components. For projects where you arrive midway on a frozen stack, the commitment translates into a documentary analysis you share with your team or your client.
Why this commitment matters#
Many developers choose their dependencies out of habit or network effect, without examining their governance. This behaviour is understandable — time-to-market pressure is real, the npm or PyPI ecosystem invites adding dependencies in seconds — but it has cumulative consequences. Thesis 6 of the manifesto recalls that sovereignty is an attribute of the entire chain: “the technological sovereignty of a piece of software is measured against its entire chain: production, maintenance, distribution, governance, funding, skills. None of these links is sufficient on its own; each one suffices to break it.”
Examining jurisdiction is the knowledge step that makes the risk zones visible. A critical dependency under Redis BSL/SSPL since March 2024, an essential component under HashiCorp BSL since August 2023, a single-vendor library with a single-maintainer concentration: these situations should at minimum be known to your team and your client. Without documentation, they remain invisible until the day a flip occurs.
The commitment resonates with thesis 5: “an open source project whose contributions, artefacts, or roadmap depend on a single sponsor is a revocable free project.” As a developer, you are on the front line to identify these situations in your daily stack. Your documentation creates a signal your colleagues, clients, and the community can pick up.
A concrete example#
A freelance Python developer working in parallel on three client projects takes this commitment in May 2026 with a 6-month horizon. For each new project and for ongoing projects she can take over, she adds a DEPENDENCIES.md file inventorying the substantial dependencies with four columns: name, jurisdiction, governance model, optional commentary.
On the first project (a Django application for a small local authority), the inventory identifies about twenty dependencies: Django (Django Software Foundation, United States, neutral foundation), PostgreSQL via psycopg2 (PostgreSQL Global Development Group, distributed governance with European dominance), Celery (open source single-vendor), Redis-py (Redis Inc., United States, noting that Redis 7.4+ is under BSL/SSPL — Valkey suggested as an alternative), Sentry SDK (Functional Software Inc., United States), pytest (Python Software Foundation, United States, neutral foundation).
For the second project, the inventory identifies a dependency on Elasticsearch via the official library; the developer discusses it with the client and proposes either switching to OpenSearch or reassessing whether PostgreSQL with full-text search would suffice. The client opts for the second solution. By the sixth month, all three projects have their DEPENDENCIES.md file up to date, and the practice is integrated into the freelancer’s standard documentation for future engagements.
Anti-pattern to avoid#
An analysis carried out but not shared with the team or the client loses most of its value — documentation is only useful if it circulates. An exhaustive list of all transitive dependencies without prioritisation makes the document unreadable and no one consults it. An examination conducted only once without updating gradually loses its informational value as the stack evolves and licences flip.
Success indicators#
By the 6-month horizon, you can reasonably consider this commitment fulfilled if your ongoing professional projects have documentation of the substantial third-party components with their jurisdiction and governance model, if the practice is integrated into your project-startup routine, and if the documentation is shared with the team or the client. In the long term, the commitment takes shape with regular updating and possible public sharing of feedback.
→ Documented in the dossier#
JSON schema category: audit. Default horizon: 6 months. Applicable to: individual declarations only.