* docs(license): widen the branding condition to all UI code and add NOTICE (MUL-5558)
The branding condition in 1b defined Multica's "frontend" as `apps/web/`
only, which left the code that actually renders the console brand outside
its own scope: the sidebar, invite and new-workspace brand surfaces live in
`packages/views/`, and the Electron and iOS clients mount the whole console
from `@multica/views` without touching `apps/web/`. A rebranded desktop
build could therefore satisfy the condition literally while removing every
Multica mark.
Replace the directory-enumerated "frontend" with a derivation-based
"Multica user interface" covering `apps/web/`, `apps/desktop/`,
`apps/mobile/`, `packages/views/` and `packages/ui/` across source, the
Docker "web" image, and compiled desktop/mobile binaries. Keep the
non-interface exemption so backend-only use stays governed by 1a rather
than by branding, and add 1c so that path still carries attribution.
Add a NOTICE file to give the attribution obligation somewhere to land:
the repository had none, and no per-file copyright headers, so Apache 2.0
section 4(c)/(d) had nothing to reproduce.
Move the "commercial license must be obtained" sentence into 1a, since it
describes only that condition and 1b/1c are cured by written authorization
and attribution respectively, not by purchase.
Co-authored-by: multica-agent <github@multica.ai>
* docs(license): separate the commercial license from the branding waiver (MUL-5558)
Conditions (a) and (b) were both cured by "explicitly authorized by
Multica in writing", so one authorization letter could be read as
releasing both — handing over commercial hosting rights when only a
rebranding permission was intended.
Name the two grants distinctly: (a) is cured only by a commercial license
obtained from the producer, (b) only by a written branding waiver. Add (d)
stating that neither implies the other and that neither can be inferred
from the producer's silence or from acceptance of contributions.
Co-authored-by: multica-agent <github@multica.ai>
* docs(license): name the published frontend image and cover relocated UI code (MUL-5558)
Co-authored-by: multica-agent <github@multica.ai>
* chore(docker): ship LICENSE and NOTICE in the published images (MUL-5558)
Co-authored-by: multica-agent <github@multica.ai>
* docs(readme): add bilingual License sections matching the updated conditions (MUL-5558)
Co-authored-by: multica-agent <github@multica.ai>
* docs(license): reposition as the self-contained, source-available Multica License (MUL-5558)
Co-authored-by: multica-agent <github@multica.ai>
* chore(release): align license metadata and ship NOTICE in release artifacts (MUL-5558)
Co-authored-by: multica-agent <github@multica.ai>
* docs(readme): describe Multica as source-available and add contribution terms (MUL-5558)
Co-authored-by: multica-agent <github@multica.ai>
* fix(landing): describe Multica as source-available instead of open source (MUL-5558)
Co-authored-by: multica-agent <github@multica.ai>
* revert(license): keep the Dify-style open-source framing, scope widening only (MUL-5558)
Co-authored-by: multica-agent <github@multica.ai>
---------
Co-authored-by: Bohan-J <bohan@devv.ai>
Co-authored-by: multica-agent <github@multica.ai>
* fix(web): resolve upstream URLs at runtime
* fix(web): keep unconfigured upstreams same-origin
* fix(web): restore dev-only localhost fallbacks for API and docs upstreams
`next dev` on a developer machine now falls back to the conventional
http://localhost:8080 backend (honoring BACKEND_PORT) and
http://localhost:4000 docs origin when nothing is configured, so a bare
`pnpm dev:web` keeps proxying out of the box. Builds and the runtime
proxy keep the strict resolvers, so prebuilt images still leave unset
upstreams unproxied.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Naiyuan Qing <145280634+NevilleQingNY@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
apps/web postinstall runs fumadocs-mdx, which reads
apps/web/source.config.ts. The deps stage only copied
package.json files, so `pnpm install --frozen-lockfile`
failed with "Could not resolve /app/apps/web/source.config.ts"
and blocked the GHCR multica-web image build in the v0.3.7 release.
Co-authored-by: multica-agent <github@multica.ai>
Publish stable GHCR self-host images, switch self-host deploys to official image pulls with a source-build fallback, and move self-host signup / Google OAuth config onto runtime /api/config.
When NEXT_PUBLIC_WS_URL is not set, the WebSocket URL defaulted to
ws://localhost:8080/ws. This broke real-time features (chat streaming,
live updates, notifications) for self-hosted deployments accessed over
LAN — the browser tried connecting to localhost on the client machine
instead of the Docker host.
Now the web app derives the WebSocket URL from window.location, routing
through the existing Next.js /ws rewrite. This works for localhost, LAN,
and custom domain setups without any extra configuration.
Also adds NEXT_PUBLIC_WS_URL as a Docker build arg for explicit override,
and documents LAN access configuration in SELF_HOSTING_ADVANCED.md.
Closes#896
NEXT_PUBLIC_* env vars must be available at Next.js build time to be
inlined into the client bundle. Without this, the Google OAuth button
never renders in self-hosted Docker deployments even when the env var
is correctly set in .env.
public/ is mode 750 locally, so COPY into the runner stage landed files as
root and the nextjs user fell under other perms, causing EACCES on scandir
at startup. Add --chown=nextjs:nodejs to the standalone/static/public COPYs.
The self-hosting Docker Compose setup fails to build on a clean clone due to several issues:
1. Dockerfile.web did not copy .npmrc into the deps stage. The project uses shamefully-hoist=true, so without it pnpm produces a different node_modules layout and module resolution breaks.
2. The builder stage copied individual node_modules directories from the deps stage (COPY --from=deps). This breaks pnpm's symlink structure -- especially on Windows where symlinks resolve to host paths. Additionally, packages/tsconfig has zero dependencies so its node_modules never exists, causing a hard COPY failure. Fixed by copying the full workspace from deps and running an offline pnpm install to re-link after source overlay.
3. next.config.ts imports dotenv but it was not declared as a direct dependency in apps/web/package.json. It resolves locally as a hoisted transitive dep but fails the TypeScript type check during next build in Docker.
4. docker/entrypoint.sh gets CRLF line endings on Windows due to git autocrlf, which breaks the shebang (container looks for /bin/sh\r). Added .gitattributes to enforce LF for shell scripts and a sed strip in the Dockerfile as a safety net.
* fix(docker): remove COPY for non-existent tsconfig/node_modules
The @multica/tsconfig package has zero dependencies, so pnpm install
never creates a node_modules directory for it. The COPY --from=deps
instruction fails with "not found" during docker compose build.
Closes#658
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix(docker): add dotenv as explicit dependency for web app
next.config.ts imports dotenv to load .env for REMOTE_API_URL, but
dotenv was never declared as a dependency. It worked locally as a
hoisted transitive dep but fails in Docker's stricter module resolution.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* docs: fix daemon setup instructions for local Docker deployments
The daemon setup section in SELF_HOSTING.md had production URLs as the
active example and local Docker URLs commented out. Since this is a
self-hosting guide, local Docker should be the primary example.
Key changes:
- Make local Docker URLs the default in daemon setup examples
- Add explicit warning that CLI defaults to hosted service
- Add 'multica config set' instructions for persistent setup
- Add link from Quick Start to daemon setup section
- Clarify that daemon runs on host machine, not inside Docker
- Update CLI_AND_DAEMON.md self-hosted section similarly
Closes#660
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
