Keep an open licence or a way out

How to do it

Read the licence's SPDX identifier in the package metadata and compare it with the OSI list. Several popular projects have moved to source-available licences that limit hosting or competing use. A managed service is fine when you can leave, so test the export before you depend on it. Keep your own data in standard formats, such as SQL dumps, JSON and CSV. Check licences in the build, as the dependency licence rule in Lock and audit dependencies describes.

Examples

Using these examples: they show one way to follow this rule. Keep the behaviour and the check, not the syntax. Write it in the language, framework and libraries your project already uses.

JavaScript example

const ALLOWED = new Set(['MIT', 'ISC', 'Apache-2.0', 'BSD-2-Clause', 'BSD-3-Clause', 'MPL-2.0', 'PostgreSQL']);
export const unapproved = packages => packages.filter(pkg => !ALLOWED.has(pkg.license));

Python example

ALLOWED = {"MIT", "ISC", "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "MPL-2.0", "PostgreSQL"}

def unapproved(packages: list[dict]) -> list[dict]:
    return [pkg for pkg in packages if pkg["license"] not in ALLOWED]

How to check

A licence checker in the build passes with an allow list of OSI-approved licences. Every managed service has a tested export, run in the last 12 months.

Sources

• OSI Approved Licenses
• SPDX License List

Related rules

• Lock and audit dependencies in Security testing
• Avoid MongoDB as the default database in Software choices
• Avoid HashiCorp tools under the Business Source License for new work in Software choices