Open Source Due Diligence Checklist Before Building a Product on a Repository

Why do open-source due diligence before building?

When a repository becomes the foundation of your product, its problems become your problems. A licence you misread, an abandoned project or an unpatched vulnerability can force a rewrite at the worst possible time.

Due diligence does not need a legal department. A structured afternoon with the checklist below catches most of the risks, and it gives you a written record to revisit when things change.

Scale the effort to the dependency’s role. A small utility library needs a quick licence and maintenance check; the framework or database your whole product runs on deserves every item on the list and a small proof of concept.

What should an open-source due diligence checklist cover?

How do you check the licence properly?

Read the actual licence file, not only the badge in the README. Check subdirectories too; some projects place enterprise or premium code under a different licence.

Map the licence to your use. Permissive licences such as MIT and Apache 2.0 allow most commercial use with attribution. GPL requires sharing source when you distribute. AGPL extends that to software offered over a network. Fair-code and source-available licences may forbid offering the software as a hosted service.

Look at the project’s history of licence changes. Projects owned by a single company can relicense future versions, as several infrastructure projects have done. That does not revoke existing versions, but it can leave you on an old branch.

How do you judge maintainer health?

Remember that a quiet project is not always an abandoned one. Mature, focused libraries may need few changes; look for prompt responses to security reports and compatibility updates rather than raw commit counts.

• Commits and releases over the past year, not just the last month.
• How many people have merge rights and actively review.
• Median time for maintainers to respond to issues and pull requests.
• Whether breaking changes are announced with migration guides.
• Signs of burnout: pinned issues asking for maintainers, archived repositories, long silences.
• Funding: sponsors, a company or a foundation behind the project.

How do you assess security?

Look for a SECURITY.md or equivalent, published advisories and how quickly past issues were fixed. A project that has disclosed and fixed vulnerabilities openly is often healthier than one with no history at all.

Run a dependency scanner on the repository and check for known vulnerabilities. For services you will expose to the internet, review authentication, input handling and default configuration yourself; defaults are often set for local development.

Check the default configuration too. Many self-hosted projects ship with open admin panels, sample credentials or debug modes meant for local use, and these defaults are a common source of real-world incidents.

How do you run due diligence step by step?

• Define how you will use the project: embedded library, self-hosted service, or base for a hosted product.
• Read the licence files and write down what your use requires.
• Review maintenance, governance and funding signals.
• Scan dependencies and check the security process.
• Clone, build and run the tests; note how long setup took.
• Try one realistic change to see how easy the code is to extend.
• Identify at least one alternative and how you would migrate data.
• Record the decision, the risks you accepted and a review date.

What are the common due diligence mistakes?

Automate what you can: licence scanners, dependency audits and repository health metrics. Use tools like the OpenSSF Scorecard for a quick view of security practices, then spend your human time on licence interpretation and architecture fit.

Curated sources can narrow the list before the deep review. RepoLoot’s catalog notes the licence, difficulty and business use of each project, so you can drop weak candidates early and spend the checklist on the few that matter.

• Trusting GitHub stars as a proxy for maintenance or quality.
• Reading only the README licence badge.
• Ignoring transitive dependencies and their licences.
• Testing the demo but not the upgrade path between versions.
• Skipping the exit plan because the project looks popular today.
• Doing the review once and never revisiting it.

How do you score a repository?

A simple scoring sheet makes comparisons between candidates fair and turns the checklist into a decision. Score each area from one to five and note the evidence behind the score.

Set minimum scores for the areas that can block you, such as licence and security. A high total should not hide a failing licence check.

Due diligence is a snapshot, and projects change. Put a review date on every critical dependency, typically once or twice a year, and repeat the checklist sooner when a trigger appears.

Triggers include a licence change, a new owner or acquisition of the company behind the project, a key maintainer leaving, a serious vulnerability or a long pause in releases. Each of these can change the risk you accepted.

Keep the findings where the team can see them, next to the dependency list or architecture docs. When someone proposes a new feature that relies more heavily on the project, the earlier review helps decide whether that is safe.

What changes if you plan a hosted product?

Offering the software as a service to customers raises the bar. AGPL requires making the source of your modified version available to users who interact with it over a network, and some source-available licences forbid competing hosted offerings entirely.

Hosted products also mean you are responsible for multi-tenant security, data isolation and backups, even if the project was designed for single-team use. Check whether the architecture supports tenants or whether you would run one instance per customer.

Finally, check trademark rules. A licence to use the code does not always include the right to use the project’s name or logo in your product or marketing.

• Confirm the licence allows hosted commercial use.
• Decide how you will publish modifications if copyleft requires it.
• Review tenant isolation and authentication.
• Read the project’s trademark policy.

Frequently asked questions

What is the most important item in open-source due diligence?

The licence, because it decides what you are allowed to do at all. After that, maintenance health and security matter most. A great project with a licence that forbids your use case, or with no active maintainers, is a risky foundation for a product.

How long does open-source due diligence take?

For a single repository, a focused review can take a few hours to a day, depending on size and how critical it is. Large frameworks or projects at the core of your product deserve deeper review, including a small proof of concept and a legal check of the licence.

Do I need a lawyer to check open-source licences?

For common permissive licences used in standard ways, many teams decide without one. For copyleft, source-available or custom licences, hosted products, or acquisitions, a lawyer familiar with open source is worth it. The cost is small compared with a forced rewrite.

What if a project I depend on changes its licence?

Existing released versions keep their original licence, so you can keep using them. Then decide whether to accept the new terms, move to a community fork if one appears, or migrate to an alternative. A written exit plan makes this decision much faster.