Open Source & SBOM Policy

​

Purpose

To establish how Neuroscale consumes open-source software (OSS), publishes OSS, contributes to external OSS projects, and produces and maintains a software bill of materials (SBOM) for each release. The policy is designed to protect Neuroscale’s intellectual property, satisfy customer and regulatory SBOM obligations, and reduce supply-chain risk.

​

Scope

All Neuroscale software, services, and infrastructure; all employees and contractors who write, review, or operate Neuroscale software; and all third-party packages, libraries, container images, models, datasets, and other components incorporated into Neuroscale products or used in Neuroscale’s internal build, deploy, or test pipelines.

​

Policy

Neuroscale uses OSS deliberately. Every dependency added to Neuroscale code carries license obligations, security risk, and supply-chain risk. The controls below ensure that those obligations and risks are identified, accepted, and managed. This policy supplements the Secure Development Policy, Vulnerability Management, and the AI Acceptable Use Policy.

​

Inbound OSS — license review

​

Allowed-license list

The following licenses are pre-approved for inbound use as a dependency in Neuroscale products without additional legal review, subject to dependency-hygiene rules below:

• MIT License
• BSD 2-Clause (“Simplified BSD”)
• BSD 3-Clause (“New BSD”)
• Apache License, Version 2.0
• ISC License
• Python Software Foundation License (PSF)
• zlib / libpng License
• Unlicense / CC0 1.0 Universal (public-domain dedications)
• Boost Software License 1.0
• Mozilla Public License 2.0 (MPL 2.0) — file-level copyleft; permitted but engineers must avoid modifying MPL-licensed source files unless prepared to publish those files. Linking to unmodified MPL components is acceptable.

​

Review-required list

The following require General Counsel review before adoption, regardless of the use case:

• GPL family — GNU GPL v2, v3, and “or-later” variants.
• LGPL family — LGPL v2.1, v3. Dynamic linking and use as an unmodified shared library may be acceptable; static linking and modification typically are not. Approve case-by-case.
• AGPL family — GNU AGPL v3. Particularly sensitive for SaaS because of the network-use trigger; assume not approved for production code unless the General Counsel explicitly approves.
• SSPL (Server Side Public License), Commons Clause, BUSL (Business Source License), Elastic License v2, and other “source-available but not OSI-approved” licenses.
• CC-BY-SA, CC-BY-NC, and other Creative Commons licenses applied to code, datasets, or models — review for share-alike and non-commercial restrictions.
• Custom or vendor-specific licenses — including any license not on the allowed list above.
• Public-domain claims that are not accompanied by a recognized dedication (CC0, Unlicense). Bare “public domain” assertions require GC review.
• Components with no clear license — also require GC review; assume “all rights reserved” until resolved.

​

Process

1. Engineers proposing a new dependency identify the license and confirm it is on the allowed list.
2. If the license is on the review-required list — or if the engineer is unsure — the engineer files a request to the General Counsel via legal@neuroscale.ai before merging.
3. License findings (allowed / approved-with-conditions / denied) are recorded in the dependency-tracking system in Snyk and the engineering wiki.
4. Code review (see Code Review) confirms the license check before merge. SCA tooling (Snyk, Dependabot) flags license findings on every PR.

​

License attribution

• A third-party-notices file (commonly THIRD_PARTY_NOTICES.md or NOTICES.txt) is generated and maintained per release for any product that ships to customers. The file lists each third-party component, its version, its license, and any required attribution text.
• For permissive licenses (MIT, BSD, Apache), the attribution file satisfies the typical attribution requirement.
• For Apache 2.0 components, any required NOTICE file content is preserved.
• Customers may request the third-party-notices file for any release; Customer Success delivers it on request.

​

Dependency hygiene

• Pinning. Application dependencies are pinned (lockfiles checked into source). Container base images are pinned by digest where feasible.
• Scanning. Dependabot and Snyk run on every PR; GitHub Advanced Security and Semgrep run static analysis. Findings are triaged per Vulnerability Management.
• Upgrade cadence. Patch and minor upgrades are reviewed at least monthly. Critical / high vulnerability patches are deployed within the timelines defined in Vulnerability Management.
• End-of-life dependencies. Dependencies that are unmaintained, archived, or have reached end-of-life are flagged for replacement; the engineering team prioritizes replacement before the next major release.
• Provenance. Where available, signed releases (Sigstore, OIDC-based provenance, npm provenance, GitHub Attestations) are preferred. Container images built by Neuroscale are signed and the supply chain is recorded.

​

Software Bill of Materials (SBOM)

​

Generation and format

• An SBOM is generated for every customer-shipped release of every Neuroscale product.
• SBOMs are produced in CycloneDX or SPDX format and include, at minimum, the components and metadata required by the U.S. NTIA “Minimum Elements for an SBOM” (July 2021): supplier name, component name, version, unique identifier, dependency relationship, SBOM author, and timestamp.
• SBOMs are generated in CI by GitHub Actions during the release build.
• SBOMs are signed (e.g., via Sigstore / cosign) and stored alongside release artifacts.

​

Distribution

• SBOMs are made available to customers on request via Customer Success.
• Where required by contract or by federal-customer policy under Executive Order 14028 (“Improving the Nation’s Cybersecurity”) and OMB Memorandum M-22-18 / M-23-16 (Software Supply Chain Security), SBOMs and accompanying attestations are delivered.
• Where required for products placed on the EU market under the EU Cyber Resilience Act (Regulation (EU) 2024/2847), SBOMs are produced and maintained per the CRA technical documentation requirements. The CRA entered into force on December 10, 2024; vulnerability-handling and incident-reporting obligations apply from September 11, 2026, and the full set of CRA obligations applies from December 11, 2027 to “products with digital elements” placed on the EU market. Neuroscale’s product surface is reviewed against the CRA scope (Annex I essential cybersecurity requirements; Annex II information and instructions; Annex VII technical documentation) by the General Counsel and the CTO at least annually and prior to any first-time placement on the EU market; today, Neuroscale’s SaaS offering is delivered as a service, not as a “product with digital elements” within the meaning of CRA Art. 3(1), so the CRA does not directly apply, but on-prem or shipped-software offerings (see AI Acceptable Use) trigger the full obligations on the dates above.

​

Outbound OSS contributions by employees

​

Personal-time contributions

Employees may contribute to OSS projects on their personal time, on personal equipment, and not using Neuroscale Confidential information. Contributions on personal time that relate to Neuroscale’s actual or anticipated business may still implicate the employee’s IP-assignment agreement; if in doubt, employees should consult the General Counsel.

​

Work-time contributions

Contributions on Neuroscale time, on Neuroscale equipment, or that draw on Neuroscale Confidential information — including bug fixes, drivers, integrations, libraries, and example code — require:

• Manager approval (engineering manager or higher).
• General Counsel approval for any non-trivial contribution, any contribution that involves a Contributor License Agreement (CLA) on behalf of Neuroscale, or any contribution that may include or be derived from Neuroscale-proprietary code.
• Sign-off compliance with the receiving project’s contribution requirements — including signing CLAs in Neuroscale’s name (only with General Counsel approval) and using the Developer Certificate of Origin (DCO) sign-off where required.

Neuroscale-proprietary code (other than the contribution itself, once approved for release) must not be included in an outbound contribution.

​

OSS that Neuroscale publishes

Where Neuroscale publishes its own software as OSS:

• Default license: Apache License, Version 2.0, unless the General Counsel approves a different license. Apache 2.0 is preferred because of its express patent grant.
• Copyright headers. Source files include a copyright notice (Copyright (c) [year] NEUROSCALE LLC) and a SPDX license identifier (e.g., SPDX-License-Identifier: Apache-2.0).
• NOTICE file. Apache-licensed projects include a NOTICE file as required by the Apache 2.0 license.
• Repository hygiene. Public repositories live in the neuroscale GitHub org; branch protection, code-of-conduct, contribution guide, and issue templates are configured.
• Security disclosure. Each public repository has a SECURITY.md directing reporters to security@neuroscale.ai; see the Incident Response Plan.
• Trademark. Use of the Neuroscale name and logo in OSS distributions is subject to Neuroscale trademark guidelines maintained by Marketing and the General Counsel.
• Release approval. Initial publication of a Neuroscale OSS project requires CTO and General Counsel sign-off.

​

Copyright and IP

• Employee work product. Neuroscale retains copyright in employee work product per the Proprietary Information and Inventions Assignment (PIIA) agreement signed at hire.
• Generative-AI assistance. Code generated or substantially assisted by AI coding tools is treated as third-party code for license purposes. The license-filtering features of approved AI coding tools (e.g., GitHub Copilot Business duplicate-detection / public-code filter) must be enabled. See the AI Acceptable Use Policy. Generative-AI contributions to Neuroscale-published OSS must be reviewed for any license-attribution or “tainting” risk by the General Counsel.
• Clean-room. Reverse-engineering or re-implementation of third-party software requires a documented clean-room procedure approved by the General Counsel.
• Datasets and models. Datasets and pre-trained models also carry licenses; the rules above apply equally to those components. See the AI training-data section in the AI Acceptable Use Policy.

​

Cross-references

• Secure Development Policy
• Vulnerability Management
• Secure Coding
• Code Review
• AI Acceptable Use Policy
• Third-Party Management Policy
• Incident Response Plan

​

Exceptions

Requests for exceptions must be submitted to the CTO and the General Counsel for approval. License-related exceptions require General Counsel approval. Exceptions are documented and time-limited, and are reviewed at the next annual policy review.

​

Violations & enforcement

Report violations to the CTO or the General Counsel. Violations may result in revocation of repository access, removal of non-compliant components, suspension of system and network privileges, and disciplinary action up to and including termination. Material license-compliance failures affecting customers may also be reported to affected customers per the Incident Response Plan.

​

Version history