Before you add an open-source dependency

For developers and technical buyers at Northstar Works, a fictional organization used as the sample setting

Write down what you intend to use, how you will use it and which license terms apply, then share that with the owner who coordinates review. Doing this before the dependency lands in a build or a purchase order makes questions cheaper to answer.

This page is a coordination aid. It does not approve a component, and it does not replace the organization's review procedure or a legal determination. When the answer is unclear, pause the change and ask rather than infer permission.

Intended use

Reviewers can only judge a component against a described use. Record these five things in your request:

  • Component and version: the exact name, the version you plan to pin, and where you downloaded it from.
  • Purpose: the specific job it will do, such as parsing invoice files, rather than a general label like utility library.
  • Where it runs: a developer laptop, an internal service, a customer-facing service or software shipped to customers.
  • Modification: whether you will use it as published or change its source or build.
  • Exposure: whether it will be distributed outside Northstar Works or its functionality offered to outside users over a network.

Who does what

The requester supplies this context. The component owner named for the product or service coordinates the review and keeps the record. A specialist reviewer in IT and Security, or in Legal, is consulted when the table below says so.

License questions: what to record and when to ask

A discussion aid for preparing your request. It is not a legal decision table; the specialist decides what a license requires.

Situation What to record Ask a specialist when
Used as published, internal only License name, license text location, version, notices that ship with it The license text is unfamiliar or has conditions you cannot summarize
Source or build modified What changed, why, and where the modified copy is kept Always, before the modified version is used beyond a test environment
Shipped to customers or partners Which product bundles it, how it is packaged, and which notices are included Always, before the release is planned
Offered to users over a network Which service exposes it and who can reach that service The license text mentions network use or sharing of source
Combined with other components Which components are linked or bundled with it, and how The licenses differ or either one has conditions on combined work
License missing, unclear, or dual-licensed Where you looked, and which option you believe applies Always. Do not choose the option yourself

Worked example: a parsing library for an internal service

The Billing Platform team at Northstar Works wants to add ledger-parse, a fictional open-source library, to read supplier invoice files in an internal reconciliation service. The requester prepares this record for the Billing Platform technical lead, who is the component owner.

  • Component and version: ledger-parse 2.4.1, pinned, downloaded from the project's official release page.
  • Purpose: read CSV and XML invoice files into the reconciliation service.
  • Where it runs: an internal service with no customer access.
  • Modification: none; used as published.
  • Exposure: not distributed, and not offered to outside users.
  • License notes: the project states a permissive license. The requester saved the license text from the release and noted that it asks for the copyright notice to be kept.
  • Open question: the library bundles a second small component whose license file is empty.

Because of that open question, the owner does not treat the request as complete. The requester asks the specialist reviewer about the bundled component and holds the change until the answer is recorded. A few weeks later the team wants to ship the same library inside a customer-installed tool. That is a different distribution context, so the owner opens a fresh review.

Review evidence to keep

Keep these where the component owner can find them. A recorded item shows what was known and asked; it is not an approval.

Component identity

What exactly was reviewed.

  • Name, pinned version and source location
  • Date you downloaded or reviewed it
  • Names of any bundled components

License text

The words the review relied on.

  • A saved copy of the license text for that version
  • Any notice files that ship with it
  • The license option chosen, if it offers more than one

Intended-use notes

The context the review assumed.

  • Purpose, where it runs and whether it is modified
  • Whether it is distributed or exposed over a network
  • The service or product that will depend on it

Questions and findings

What was asked and what came back.

  • Each question raised, who it went to and the reply
  • Any condition the specialist asked you to meet
  • The role responsible for tracking the component

Common questions

Do I need a new review when I upgrade to a newer version?

Tell the component owner. A minor version bump with the same license and the same use may only need the record updated. If the license text changed, or the component now bundles something new, treat it as a new question and consult a specialist.

What if I can't find the license, or the project lists two?

Record where you looked and what you found, then stop. Do not pick an option or assume that no license means free to use. Send the details to the component owner so a specialist can respond.

The dependency is already in production. What should I do?

Do not remove it on your own. Gather the details in the table above, tell the component owner, and pause any change to how it is used until the owner or a specialist has replied.

I'm buying a product that includes open-source components. Does this apply?

Yes. As a technical buyer, ask the supplier which open-source components and licenses the product includes, and record the answers with your intended use. Share them with the component owner or the specialist reviewer before you commit.

My use is a test or prototype. Can I skip this?

Keep notes even for a prototype, because prototypes often become real services. Note that the use is a test. If the prototype moves toward production, shipping or sharing outside the team, return to the table and ask the relevant specialist before it does.

Ongoing ownership

A review is a snapshot. Each dependency needs a named role, not a person, so the record outlasts team changes.

Component owner

The technical lead for the product or service that depends on the component.

  • Keeps the review record with the evidence listed above
  • Reopens the review when the triggers below occur
  • Routes unclear license questions to a specialist

Specialist reviewer

A trained reviewer in IT and Security or Legal, consulted as the table indicates.

  • Answers license and obligation questions
  • Says what must be recorded or done before use
  • Is the only route for a decision on unclear or modified components

When to revisit a review

Return to the component owner whenever one of these changes:

  • the pinned version changes, or the component's license text does
  • you start modifying the source or build
  • the component is shipped, bundled with another product or offered to outside users
  • the service that uses it changes owner or purpose

For operational questions, such as where to submit a request or who covers a specialist role, use the IT and Security route Northstar Works publishes for dependency questions. If you are unsure which route applies, ask your component owner first.