130 lines
5.2 KiB
Markdown
130 lines
5.2 KiB
Markdown
# 29 · Legal FAQ — *333 Scan/Day Free‑Tier Quota*
|
||
|
||
> **Status:** Published – applies to all open‑source (AGPL‑3.0‑or‑later) builds
|
||
> **Audience:** project contributors, downstream packagers, OSS users, lawyers
|
||
> **Scope:** clarifies how the daily‑quota mechanism interacts with copyright
|
||
> licences, fair‑use, forking rights and the AGPL network‑use clause.
|
||
> **Not a contract:** this FAQ is **informational** and does not replace the
|
||
> actual licence text (GNU AGPL‑3.0) shipped with every source tarball.
|
||
|
||
---
|
||
|
||
## 1 · Is the *333 scans per UTC day* limit a **licence** restriction?
|
||
|
||
**No.**
|
||
The quota is an **operational usage limit** enforced by runtime code
|
||
(`StellaOps.Quota` plug‑in).
|
||
The source code itself remains available under the
|
||
[GNU Affero General Public Licence v3](https://www.gnu.org/licenses/agpl‑3.0.html).
|
||
Any person may:
|
||
|
||
1. **Receive the complete corresponding source** (AGPL § 6).
|
||
2. **Modify** or **remove** the quota logic, and
|
||
3. **Run** those modified versions, **even over a network** (AGPL § 13),
|
||
|
||
provided they also comply with the licence duties (e.g. **offer**
|
||
their own modified source to users who interact with the modified
|
||
program over a network).
|
||
|
||
---
|
||
|
||
## 2 · Why doesn’t the quota violate AGPL § 0 or § 13?
|
||
|
||
* **§ 0** (Freedom to run the program) – You can run unmodified or
|
||
modified copies of Stella Ops for any purpose and in any quantity
|
||
inside your own infrastructure. The quota only limits *how many scan
|
||
operations the official binaries will accept*; it does **not** forbid
|
||
you from creating binaries without that limit.
|
||
|
||
* **§ 13** (Remote‑network interaction) – If you provide Stella Ops as a
|
||
service and keep the quota, users interact with an unmodified AGPL
|
||
work, so no extra obligations arise.
|
||
If you **remove** or **change** the quota, that counts as a
|
||
modification; under § 13 you must **make your modified source code
|
||
available** to those remote users.
|
||
|
||
---
|
||
|
||
## 3 · May I **fork** the project and delete the quota altogether?
|
||
|
||
Yes – the AGPL expressly permits this.
|
||
However, three practical notes apply:
|
||
|
||
| Aspect | Obligation / Consequence |
|
||
|--------|-------------------------|
|
||
| **Source availability** | You *must* provide the full modified source (including build scripts) under AGPL‑compatible terms. |
|
||
| **Trademarks** | The name **“Stella Ops”**, the star‑logo and the “333” banner are trademarked. Remove them or obtain prior written consent before redistributing a modified build. |
|
||
| **Update Kit tokens** | Official Offline‑Update‑Kit (OUK) tar‑balls embed signed Client‑ID JWTs that expect the quota code‑path. If you strip that path, you will also need to maintain your own OUK feed or rebuild the tar‑balls. |
|
||
|
||
---
|
||
|
||
## 4 · What about **educational labs** or “Hack Week” events that need more than 333 scans?
|
||
|
||
You have three options:
|
||
|
||
1. **Request a short‑lived *Workshop Token*** – project maintainers can
|
||
issue a signed JWT that temporarily raises the limit (subject to
|
||
availability).
|
||
2. **Spin up additional tokens** – each API token carries its own 333
|
||
scans/day budget; e.g. a class of 40 students can share ten tokens.
|
||
3. **Compile without quota** – ideal for private, non‑public courses;
|
||
remember to keep the modified source accessible to participants.
|
||
|
||
None of these options require a commercial licence fee.
|
||
|
||
---
|
||
|
||
## 5 · Does the quota create a **field‑of‑use restriction** (GPL FAQ concern)?
|
||
|
||
No. The limit is *quantitative* (how many scans per unit of time), not a
|
||
prohibition on *where* or *for what* purpose you run the software.
|
||
Therefore it does **not** impose an additional field‑of‑use restriction
|
||
and remains compatible with AGPL § 7.
|
||
|
||
---
|
||
|
||
## 6 · How does the **Offline Update Kit** interact with licence tokens?
|
||
|
||
* Every OUK tar‑ball ships a **signed Client‑ID JWT** with 30‑day
|
||
validity.
|
||
* The token is stored at `/keys/client.jwt` on the backend container and
|
||
refreshed on each OUK upload.
|
||
* If you fork the codebase and remove the quota, you must either
|
||
(a) ignore the token entirely, or
|
||
(b) generate and sign your own tokens – the signing key is **not**
|
||
included in the public repo for security reasons.
|
||
|
||
---
|
||
|
||
## 7 · Can forks override the limit?
|
||
|
||
Yes. Forks could provide Client‑ID tokens with `maxScansPerDay = 0`
|
||
(unlimited). The same runtime code path is used; no proprietary
|
||
mechanism exists inside the open‑source core.
|
||
|
||
---
|
||
|
||
## 8 · Why 333 – not 100, 500 or 1 000?
|
||
|
||
* 333 ≈ the 95th‑percentile daily build count of **small/medium‑sized
|
||
self‑hosted GitLab instances** we surveyed in 2024.
|
||
* It leaves *head‑room* for burst‑y days while nudging larger teams
|
||
towards Plus/Pro – the main revenue driver that funds continued
|
||
development of the open‑source core.
|
||
|
||
See *02_WHY.md § 5* for the full product‑management rationale.
|
||
|
||
---
|
||
|
||
## 9 · Who can I contact for **licensing support**?
|
||
|
||
* E‑mail: **legal@stella‑ops.org**
|
||
|
||
---
|
||
|
||
## 10 · Change Log
|
||
|
||
| Version | Date | Comment |
|
||
|---------|------|---------|
|
||
| **v1.0** | 18 Jul 2025 | First public revision – aligns with quota rev 2.0. |
|