Scheduled AI Pipeline Workstation

The scope of the review is recorded as it is: upstream is a large Java monorepo, reading it file by file is not feasible, and upstream's source code is not on the buyer's execution path — the runtime is the official distribution image kestra/kestra:v1.3.30, pinned by compose with a tag plus a digest, and the same digest fetches the same image; upstream's code serves only as the vetting snapshot and the basis for derivative development. The files we built were reviewed line by line (docker-compose.yml, the two demonstration flows under flows/, scripts/init-env.sh, QUICKSTART.md, LICENSE-99LL and .env.example), all of them handwritten on this production line. The outbound connection surface found: the AI demonstration flow calls api.openai.com (the buyer has to fill in a key, and the flow is disabled by default); after login the web interface fetches news and templates from api.kestra.io carrying an instance identifier; and the platform's anonymous usage reporting is on by default and likewise goes to api.kestra.io (our compose file does not turn it off). What was removed: upstream's dind compose file mounting the docker socket, and the GitHub workflows, were deleted; the compose file used for delivery mounts no socket and does not run as root.

The executable script QUICKSTART refers to is scripts/init-env.sh (ours, reviewed line by line: it draws a random password from /dev/urandom and writes it into .env, does not overwrite an existing one, and performs no network action itself). The compose file used for delivery has no build section, so the buyer compiles nothing — docker compose up pulls the official image pinned by digest, and a digest is content-addressed, so it cannot resolve to a different set of bytes because the build happened on a different day. Upstream's development scripts (gradlew, Makefile, build-and-start-e2e-tests.sh and others) are kept along with the snapshot, and QUICKSTART does not refer to them.

This product is a frozen snapshot and does not follow upstream: upstream's source code is pinned at 86b2968 (see the evidence link), and the product repository consists of that snapshot plus our own work commits; the runtime image is pinned at kestra/kestra:v1.3.30 with a digest attached. The source snapshot was taken from upstream's main line after that distribution.

SPDX:LicenseRef-99LL-Product

Two layers of licence, both inside the delivered tree: (1) upstream kestra-io/kestra is Apache-2.0 — the LICENSE at the root of the delivered tree is word for word the standard full text of the Apache License 2.0 (this is determined from that file itself plus the license.spdx_id from REST, not from the null licenseInfo from GraphQL); commercial use, modification, redistribution and making it private are permitted, and the obligation is to retain the licence notice; upstream has no NOTICE file (ATTRIBUTION.md records this). Upstream's LICENSE is kept verbatim, not a word changed. The enterprise edition code lives in a separate closed-source repository upstream and is not in this snapshot. (2) We generate LICENSE-99LL from the 99LL product licence template v1 as the sale and liability terms for the part we built (this does not override upstream's licence), and spdx expresses this as LicenseRef-99LL-Product; the template's delivery version field carries the git tag v1.3.30-99ll.1, which was applied after the delivery commit was settled.

Recorded as it is, with no pretence of having scanned: the runtime is the official image kestra/kestra:v1.3.30, and the Java dependency tree inside it was not actually scanned package by package — upstream publishes under Apache-2.0 and manages its own dependency licences, but we have no machine evidence of that, so the licence status is flagged as uncertain. The files we built are a compose file, YAML flows and shell scripts; they install no packages, so they add no dependency that is distributed with the zip. If the buyer enables the AI demonstration flow, what it calls is OpenAI's service, not a dependency being distributed.