All Docs
Getting StartedCalmony Sanctions MonitorUpdated March 11, 2026

DEP-16: Adding a LICENSE File to a Private SaaS Repository

DEP-16: Adding a LICENSE File to a Private SaaS Repository

Release: v0.1.48
Control: DEP-16
Category: Dependency / Licensing

Why a LICENSE File Matters for a Private Project

Many teams assume that marking a project private in package.json is sufficient to protect intellectual property. In practice, the absence of an explicit LICENSE file leaves several questions unanswered:

  1. IP ownership ambiguity — without a copyright notice, it is unclear who legally owns the code, which matters during due diligence, acquisition, or contractor disputes.
  2. Contributor and contractor terms — contributors need to know under what terms their work is incorporated. A license file (or a Contributor License Agreement) makes this explicit.
  3. Open-source attribution obligations — many upstream dependencies (MIT, BSD, Apache-2.0) require that their copyright notices are preserved. A top-level license file is the standard place to acknowledge this and to signal that the project itself is not open-source.

What Was Added

A LICENSE file has been placed in the repository root. For this private commercial SaaS the file contains a proprietary / all-rights-reserved notice that:

  • Asserts copyright ownership.
  • Prohibits redistribution or use outside the terms agreed with the owner.
  • Does not grant any open-source rights.

Choosing the Right License Type

ScenarioRecommended approach
Private, internal toolingProprietary notice or UNLICENSED SPDX identifier
Private, used by paying customersCompany's standard commercial software license
Source-available (read-only public)BUSL-1.1 (Business Source License)
Fully open-sourceMIT or Apache-2.0

Minimum Viable License File (Proprietary)

If you need a quick proprietary notice, use the following template:

Copyright (c) [YEAR] [COMPANY NAME]. All rights reserved.

This software and associated documentation files are proprietary and
confidential. Unauthorised copying, distribution, modification, or use
of this software, in whole or in part, is strictly prohibited without
the express written permission of [COMPANY NAME].

Replace [YEAR] and [COMPANY NAME] before committing.

SPDX Identifier

If the project uses tooling that reads SPDX identifiers (e.g. license-checker, FOSSA), add the following field to package.json:

{
  "license": "UNLICENSED"
}

This is already implied by "private": true in most auditing tools, but being explicit removes all ambiguity.

Compliance Checklist

  • LICENSE file exists in the repository root
  • package.json contains "license": "UNLICENSED" or the appropriate SPDX identifier
  • Copyright year and company name are correct
  • All contractors / contributors have agreed to terms that assign IP to the company
  • Dependency attribution requirements (MIT notices, etc.) are satisfied in a THIRD_PARTY_LICENSES or NOTICE file if required

Related Controls

  • DEP-16 — License File Present
  • Open-source dependency auditing should be run periodically with a tool such as license-checker or licensee to verify upstream attribution obligations are met.