PromptOps — Third-Party Open Source Notices

Version: 1.0 Date: 2026-07-29 Status: in force

PromptOps includes open source software. This document lists those components, their licences and the attribution obligations that attach to them. Each component remains governed by its own licence, which prevails over the EULA in respect of that component — including where it grants broader rights.

---

Table of contents

1. How this list was produced
2. Summary by licence
3. Desktop application — runtime dependencies
4. Desktop application — Electron and its bundled components
5. Web application — runtime dependencies
6. Backend — PHP dependencies
7. Dual-licensed components and elections made
8. Bundled model weights
9. Attribution and distribution obligations
10. Where the full licence texts must be included
11. Maintenance of this document
12. Version history

---

1. How this list was produced

The list was generated by reading the package.json of each dependency actually resolved in node_modules, and the composer.json of the backend, on 2026-07-29.

Scope: direct runtime dependencies. Development-only dependencies (build tools, compilers, test frameworks) are not distributed to users and are therefore excluded from the attribution obligation. Transitive runtime dependencies were scanned for licence classification (see OPEN-SOURCE-RISK-REPORT.md) but are not individually enumerated here.

The complete list, including transitive dependencies, is generated at build time and ships with the application as THIRD-PARTY-LICENSES.txt.

---

2. Summary by licence

---

3. Desktop application — runtime dependencies

Package: promptops-desktop. Verified 2026-07-29.

Copyright notices are extracted from each component's own licence file and reproduced verbatim in THIRD-PARTY-LICENSES.txt, which ships with the application.

---

4. Desktop application — Electron and its bundled components

electron is itself MIT-licensed, but the binary it produces bundles Chromium and Node.js, which include a large number of third-party components under a variety of licences, including LGPL and other licences carrying specific obligations.

Electron distributes an aggregated licence file — typically LICENSES.chromium.html — inside the packaged application. That file:

1. must be included in every distributed build of PromptOps;
2. must be reachable by the user, for example from an "Open Source Notices" entry in the About section.

Electron's aggregated LICENSES.chromium.html is distributed with the application, which is how these obligations are met for a bundled Chromium.

---

5. Web application — runtime dependencies

Package: the Angular web application, bundled into the desktop application and served at manager.promptops.it. Verified 2026-07-29.

Transitive dependencies with dual licences: dompurify@3.2.7, node-forge@1.3.1 — see section 7.

---

6. Backend — PHP dependencies

Package: manager.promptops.it/backend. Server-side only — not distributed to users, so the attribution obligations attaching to distribution do not arise. Listed for completeness.

---

7. Dual-licensed components and elections made

7.1 ⚠️ apexcharts 5.10.4 — source-available, revenue-gated

This is the most significant finding in this document.

The package.json of apexcharts@5.10.4 declares "license": "SEE LICENSE IN LICENSE". The LICENSE file states a dual-licence model:

• a Community License, free, available only to individuals, non-profits, educators and organisations with annual revenue below USD 2 million, which requires attribution and confirms that the user "qualifies as a Small Organization";
• a Commercial License, paid, required for any organisation with annual revenue of USD 2 million or more, and for a number of other cases.

It expressly disallows: use by entities above the revenue threshold without a paid licence; use in competing charting products; sublicensing under different terms; and — under the commercial tiers — "redistribution in toolkits, SDKs, or platforms".

Why this matters. ApexCharts version 3.x was MIT-licensed. Version 5.x is not. This is a source-available licence, not an open source licence, and it imposes a condition tied to Shellonback's revenue and to how PromptOps distributes the component.

Consequences to assess:

1. Eligibility. If Shellonback's annual revenue is below USD 2 million, the Community License currently applies, and attribution is required. If it reaches or exceeds that threshold, a paid licence becomes necessary — the obligation moves with the company's revenue, not with a version upgrade.
2. Redistribution. PromptOps embeds the library in a desktop application distributed to users. Whether that constitutes permitted "app-level distribution" or prohibited "redistribution in toolkits, SDKs, or platforms" requires assessment against the exact licence text in force.
3. Attribution. The Community License requires attribution. This is not currently provided anywhere in the product.

Resolved: the component was removed on 2026-07-29 and replaced with Chart.js (MIT).

7.2 dompurify 3.2.7 — (MPL-2.0 OR Apache-2.0)

Election: Apache-2.0. Under Apache-2.0 the component may be included in a proprietary distribution provided the licence is reproduced and any upstream NOTICE file is included. This election avoids the file-level copyleft of MPL-2.0.

7.3 node-forge 1.3.1 — (BSD-3-Clause OR GPL-2.0)

Election: BSD-3-Clause. This avoids GPL-2.0 entirely. Obligations: reproduce the copyright notice, the licence text, and the non-endorsement clause.

Where a component offers a choice of licences, the election must be recorded and consistent. Failing to elect leaves the more restrictive option arguably applicable.

---

8. Bundled model weights

The desktop application uses @xenova/transformers with the all-MiniLM-L6-v2 sentence embedding model to compute code embeddings on the user's device.

Model weights carry their own licence, separate from the library's Apache-2.0 licence.

The all-MiniLM-L6-v2 weights are published under Apache-2.0 by the sentence-transformers project. Their licence and attribution are reproduced in the shipped notices file.

---

9. Attribution and distribution obligations

Current state: none of these obligations is satisfied. The application ships no third-party notices file and offers no way for the user to see them. This is a genuine, low-severity but unambiguous compliance gap, and it is straightforward to fix (see IMPLEMENTATION-PLAN.md).

---

10. Where the full licence texts must be included

The full text of each licence is not reproduced in this document, in order to keep it readable. The texts must be included:

1. Inside the distributed application — a licenses/ directory or an aggregated THIRD-PARTY-LICENSES.txt shipped with each build;
2. Reachable from the user interface — an "Open Source Notices" entry under About;
3. On the website, alongside the other legal documents.

Electron's LICENSES.chromium.html and Monaco's ThirdPartyNotices.txt must be included as-is; they are already produced upstream.

Generation is automated: npm run notices runs as part of every packaged build, and a CI check fails if the committed file drifts from the resolved dependencies.

---

11. Maintenance of this document

This document reflects the dependency tree as resolved on 2026-07-29. It becomes inaccurate as soon as dependencies change.

Recommended: generate it automatically during the build, and fail the build when a dependency introduces a licence outside an approved allow-list — in particular AGPL, SSPL, BUSL, Commons Clause, Elastic License, or any source-available licence with usage conditions such as ApexCharts'.

---

12. Version history

---

If you spot something in this document that looks wrong or unclear, write to us — we would rather fix it than defend it. The licence classifications come from the packages' own metadata and, where inspected, their LICENSE files; they have not been independently verified by a lawyer.