THE FOUNDRA TAKE

A dependency decision should include permitted use and maintenance responsibility alongside technical fit.

Separate visibility from permission

The Open Source Initiative’s definition sets out criteria for open-source licensing. A repository being publicly readable is not the same thing as satisfying that definition. Some projects allow inspection while restricting particular uses. For a startup, the practical first step is to locate the licence associated with the exact version it plans to use rather than relying on a marketing label.

Map the intended use

Describe whether the component will run internally, be distributed to customers or form part of a hosted service. Those situations can raise different questions under different licences. Record modifications and other dependencies included with the component. If a condition is unclear or material to the business model, obtain appropriate specialist review before committing the architecture around an assumption.

FOUNDRA EXPLAINS

The dependency decision

01

Licence

Find the exact applicable terms.

02

Use

Describe deployment and distribution.

03

Maintain

Assess updates and security response.

04

Record

Keep versions, owners and decisions visible.

Foundra analysis: an explanatory decision framework, not measured company results.

Evaluate maintenance as well

A suitable licence does not guarantee an actively maintained project or a reliable security response. Review release activity, issue handling and how updates would enter the product. A hypothetical team may find that a technically elegant package creates substantial upgrade work because it sits on a critical path. Include the ability to replace it in the evaluation, especially when only one person understands the integration.

Laptop on desk book stacks (Unsplash)
Laptop on desk book stacks (Unsplash) · freddie marriage fredmarriage · CC0 · Context image

Keep a usable dependency record

Store the package version, licence, intended use and responsible owner in a place the team can maintain. Revisit the decision when the product’s distribution model changes or the dependency changes its terms for a new version. The objective is not to avoid useful shared software. It is to make the company’s rights, obligations and operating responsibilities clear enough that a dependency does not become an unexpected constraint.

Sources

  1. Open Source Initiative — source and reference material ↗ Open Source Initiative · Primary source

Have additional information? Request a correction.