Last Music Bot

A self-hosted Discord music bot with a React dashboard. Slash commands drive the same player the web UI does, with Lavalink handling audio and Spotify supplying autoplay recommendations.

Overview

Last Music Bot is two halves of one product: a Discord bot and a React dashboard that control the same player. Whether you type /play in a channel or click a track in the browser, the request lands in the same player service. The dashboard is not a read-only mirror of the bot; it is a second front end to it.

Audio is delegated to Lavalink, so the bot process never touches an audio stream; it sends the node a track and receives events back. That is what lets a single instance serve several guilds without turning into an encoding server.

It is designed to be self-hosted. You run it, you own the data, and the whole stack comes up under Docker.

Key Features

• Two Front Ends Slash commands and a React dashboard drive the same player service, so the two never disagree about what is playing.
• Lavalink Audio Playback is handled by a Lavalink node over the standard client, keeping the bot process free of audio work.
• Spotify Autoplay When the queue runs dry the bot keeps going, choosing related tracks rather than repeating the last one.
• Playlist Import Pull existing playlists in from Spotify and YouTube instead of rebuilding them by hand.
• Persistent Library Playlists, likes, history, and per-guild settings live in SQLite and survive restarts.
• Drag-and-Drop Queue Reorder the queue from the dashboard, on desktop or touch.
• Audited Actions Actions are written to an append-only JSONL log, so who-did-what is answerable after the fact.
• Scheduled Backups A backup service snapshots the databases on a loop, with a restore path that does not involve improvising.
• One-Command Stack Bot, dashboard, Lavalink, and the cipher helper all come up together under Docker Compose.
• Tested Unit, smoke, and end-to-end suites cover the player, the services, and the command handlers.

Slash Commands

The command surface is deliberately small. Anything beyond transport control belongs in the dashboard, where there is room for it.

Architecture & Stack

Discord and the dashboard are two doors into one player service. Below it, the work fans out: Lavalink for audio, the recommendation engine for autoplay, and SQLite for anything that must survive a restart. Click a node to jump to the section that documents it.

The Containers

Four services come up together. Splitting them apart is what allows a redeploy of the bot to leave audio playback untouched.

.
├── apps/bot/          # discord.js client, REST API, player, services, tests
│   └── src/
│       ├── api/           # Express route registration
│       ├── discord/       # Slash commands
│       ├── player/        # PlayerService - the one source of truth
│       ├── lavalink/      # Audio node client
│       ├── recommendation/# Autoplay + ANN index
│       ├── spotify/       # Auth, catalog, playlist import
│       ├── youtube/       # Playlist import
│       ├── store/         # SQLite stores + repositories
│       ├── audit/         # Append-only JSONL logger
│       └── backup/        # Scheduled snapshots
├── src/               # React dashboard (production UI)
├── lavalink/          # Lavalink node config
└── docker-compose.local.yml

Lavalink & the Audio Pipeline

The bot never touches an audio stream. It sends a Lavalink node a track and gets events back, and the node does the streaming, decoding, and mixing. That separation is the reason a redeploy of the bot does not interrupt playback: the audio container keeps running.

Almost every built-in source is switched off

Lavalink ships with source managers for YouTube, Bandcamp, Twitch, Vimeo and more. Nearly all of them are disabled here, and only http is left on. That looks like a mistake until you see the plugin list: the built-ins are turned off because the plugins replace them, and running both would mean two code paths competing to resolve the same URL.

Spotify is a catalog, not a stream

This is the part worth understanding. Spotify audio is never played. Spotify is used to identify the music; the audio is then sourced from YouTube. LavaSrc resolves each Spotify track by trying, in order:

providers:
  - "ytsearch:%ISRC%"     # 1. match the exact recording
  - "ytsearch:%QUERY%"    # 2. fall back to artist + title text

The ISRC is the recording's global identifier, so searching by it finds that recording, not a cover, a live take, or a remaster that happens to share the title. Only when a track has no usable ISRC does it fall back to a plain text search, which is the path that occasionally lands on the wrong version. That two-step order is the whole reason Spotify-sourced playback usually gets the right take.

Surviving YouTube

YouTube is a moving target, and two pieces of the config exist purely to cope with that.

The YouTube plugin is configured to rotate through several client identities: MUSIC, ANDROID_VR, WEB, WEBEMBEDDED, and TV. They break at different times and under different conditions, so if one client stops resolving, another is likely to still work. It is redundancy, not cleverness.

The second piece is yt-cipher, which is why there is a fourth container in the stack that otherwise looks unnecessary. YouTube protects stream URLs with a signature computed by JavaScript that changes regularly. Rather than making the audio node run that JavaScript itself, the node delegates signature work to a small dedicated service over the local network. Keeping it separate means the thing that breaks most often is also the thing you can update or restart on its own.

Tuning

Dashboard & REST API

The dashboard is a Vite + React 18 app. It holds no player logic of its own; it calls the same API the bot exposes, which is why the queue you drag in the browser is the queue Discord is playing.

The API is Express, authenticated with JWT, and validates request bodies with zod so a malformed payload is rejected at the edge rather than halfway through a state change. Routes are grouped by concern:

Library, Storage & Backups

State is split across two SQLite databases, and the split is deliberate: library.db holds what you want to keep (playlists, likes, history, settings, linked accounts), while player.db holds what is merely true right now. Losing the second is an inconvenience; losing the first is a loss.

Each concern gets its own repository rather than sharing one god-object over the connection, and schema changes run through an explicit migration path instead of being applied by hand.

Two safety nets sit underneath. Actions are appended to a JSONL audit log, which is append-only and therefore still trustworthy after something has gone wrong. And a backup service snapshots the databases on a schedule, with a restore command as a first-class script rather than an improvised copy.

Autoplay & Recommendations

An empty queue is where most music bots stop. This one keeps going: when the last track ends, the recommendation service picks what follows.

Rather than asking an API for "related tracks" every time, the bot maintains its own approximate nearest-neighbour index over a track index it builds up. Candidates are drawn from that index and enriched through the Spotify catalog, which keeps suggestions relevant to what has actually been playing instead of drifting into whatever is globally popular.

Playlists can be imported wholesale from Spotify (private, public, or embedded) and from YouTube, so an existing collection does not have to be rebuilt track by track.

Self-Hosting

The whole stack is Docker Compose. Node 24 or newer is required if you intend to run the bot outside a container.

# Fill in your own configuration first
cp .env.example .env

npm run dev:up:build     # first run: builds the bot and UI images
npm run dev:up           # thereafter
npm run dev:logs         # tail the bot
npm run dev:down         # tear it down

Configuration is entirely environment-driven: the same image runs locally and in production, with no code branching between them. .env.example documents every key the stack reads. Your credentials stay yours: they are gitignored, and the deploy path is built so that they are never uploaded from a developer machine.

Terms & License

Last Music Bot is open source under the GNU Affero General Public License v3.0. The Affero clause matters here: if you run a modified version as a network service that other people use, you must offer those users the source of your modifications. Running it unmodified for your own server carries no such obligation.

Lavalink, discord.js, and the other dependencies remain under their own licenses. Discord, Spotify, and YouTube are trademarks of their respective owners; this project is not affiliated with any of them, and you are responsible for complying with their terms of service.

Last Download Manager

A modern, feature-rich download manager built with C++ and wxWidgets. Accelerated multi-segment downloads, video site support via yt-dlp, browser extension integration, and robust crash recovery - all powered by native Windows APIs.

Overview

Last Download Manager is a native Windows download manager built on C++ and wxWidgets. It splits a file into segments and pulls them in parallel over WinINet, which is where the speed comes from, and it treats interruption as normal rather than exceptional: chunks retry, downloads resume, and progress is checkpointed to disk so a crash costs you seconds instead of a whole file.

Video sites are handled by shipping the problem out to yt-dlp, with ffmpeg and Deno fetched and updated automatically. A browser extension intercepts downloads and hands them to the running app over a local HTTP server.

Key Features

• Multi-Segment Engine Splits each file across parallel WinINet connections, which is where the throughput gain comes from.
• Resume & Auto-Retry Two-level retry with exponential backoff; part files survive failure, so an interrupted download continues rather than restarting.
• Crash Recovery Progress is written to the database periodically, so an unexpected shutdown does not cost the transfer.
• Checksum Verification MD5 and SHA256 hashes verified against the finished file.
• Video Sites yt-dlp integration covering YouTube, Vimeo, and 1000+ sites, with resolution and format chosen before the download starts.
• Managed Toolchain yt-dlp, ffmpeg, and the Deno runtime are downloaded and kept current automatically. Nothing to install by hand.
• Browser Extension Chrome, Edge, Brave, and Firefox: auto-intercept, right-click download, page video scan, and batch grabbing.
• Speed Graph Live throughput plotted over a rolling window, so a stalling connection is visible rather than inferred.
• Categories & Scheduler Automatic sorting into Documents, Video, Music, Images, Programs, and Compressed, plus start and stop times for queues.
• Tray & Dark Mode Minimise to tray with notifications, and a dark theme throughout.

Download Engine

The engine assumes networks fail. Retries are layered so that a brief blip is absorbed at the chunk level without disturbing the download, while a genuine outage backs off instead of hammering the server.

Resume

Segments are written as .part0, .part1, and so on, and are kept when a download fails, and that is what makes resume possible after the automatic retries are exhausted. On restart the app checks the existing size on disk, and validates Content-Range responses before appending, so a server that ignores the range request cannot silently corrupt the file.

Thread Safety

Status, sizes, and speed are atomics; metadata, chunk lists, and database writes are mutex-guarded. WinINet handles are owned by RAII session objects, and async tasks are tracked so they cannot outlive the download that spawned them.

Video & Tool Management

Video extraction is delegated to yt-dlp rather than reimplemented. The app fetches the toolchain itself on first use and keeps it updated, so there is no manual setup step.

All three live in %APPDATA%\LDM\tools\. Delete that folder and the app will simply fetch them again, which is the quickest fix when an extractor starts misbehaving after a site change.

Streams behind a CDN that checks where the request came from are handled by propagating the Referer header from the originating page.

Installation & Setup

Click the Download button above for the latest release. Requires Windows 10 or 11. Nothing else needs installing: the video toolchain fetches itself on first use.

Building from Source

Requires Visual Studio 2022 with the Desktop development with C++ workload and wxWidgets 3.2 or newer. Networking uses the native WinINet APIs, so there is no libcurl dependency to satisfy.

1. Build wxWidgets from wxwidgets.org.
2. Set WXWIN to your wxWidgets directory; the project expects libraries at $(WXWIN)\lib\vc_x64_lib.
3. Open LDM.sln, select Release and x64, and build.

# Either pass the flag...
LDM.exe --debug

# ...or drop an empty debug.txt next to the executable
type nul > debug.txt

Browser Extension & Local API

The extension does not download anything itself. It intercepts the browser's download, cancels it, and hands the URL to the running app, which means the app must already be running, since the extension will not start it for you.

1. Start LDM.
2. Open chrome://extensions, edge://extensions, brave://extensions, or about:debugging#/runtime/this-firefox.
3. Enable Developer mode.
4. Click Load unpacked (Chrome, Edge, Brave) or Load Temporary Add-on (Firefox).
5. Select the BrowserExtension folder from your LDM installation.

Beyond auto-intercept it adds a right-click Download with LDM entry, a video tab that scans the page for media and offers quality selection, batch Download All Links and Download All Media actions, a manual URL box, a live connection indicator, configurable hotkeys, and filters for file type, domain, and minimum size.

Local HTTP API

The two halves talk over a small HTTP server bound to loopback. It is worth understanding if you are debugging a connection problem, or building against it.

Content-Type: application/json
X-Auth-Token: <token from GET /token>

{
  "url": "https://example.com/Win11_25H2_English_x64.iso",
  "referer": "https://example.com/downloads"
}

referer is optional and only sent when the page supplied one; it is what allows downloads from CDNs that reject requests arriving without an origin.

Architecture & Component Layout

Two front doors, the wxWidgets window and the extension's HTTP server, feed one queue. DownloadManager owns that queue and dispatches to either the segmented HTTP engine or yt-dlp, depending on what the URL turns out to be. Click a node to jump to the section that documents it.

Last-Download-Manager/
├── LDM.sln
├── BrowserExtension/         # MV3 extension: background, content, popup, options
└── LDM/
    ├── main.cpp
    ├── core/                 # Download · DownloadEngine · DownloadManager · YtDlpManager
    ├── ui/                   # MainWindow · DownloadsTable · CategoriesPanel · SpeedGraphPanel
    ├── database/             # DatabaseManager - XML persistence
    ├── utils/                # HttpServer · Settings · ThemeManager · HashUtils
    └── resources/            # Icons, manifests, assets

Troubleshooting & FAQ

The issues that actually come up, and what is really going on underneath each.

Terms & License

Last Download Manager is open source under the GNU General Public License v3.0. You may use, study, modify, and redistribute it, provided derivative works stay under the same license and the source remains available.

yt-dlp, ffmpeg, and Deno are separate projects under their own licenses; LDM downloads and invokes them but does not bundle or modify them. You are responsible for respecting the terms of service of whatever site you download from.

Last Rich Presence

Windows app for accurate, polished Discord Rich Presence for media, creative, and productivity workflows. Built with C++20 and WinUI 3.

Overview

Last Rich Presence keeps Discord aligned with what you are actually doing on Windows, across three independent activity lanes: media playback read from Windows media sessions, creative work detected from Adobe-family desktop apps, and productivity work detected from Office-family apps. Each lane owns a separate Discord application, so a track, a Photoshop session, and a Word document can appear as distinct cards rather than fighting over one status.

The app is single-instance and tray-first: it can start minimized, close to tray, and redirect a second launch back to the running instance. An optional Chromium extension improves timeline accuracy for web players that Windows reports poorly.

Key Features

• Media Lane Reads active Windows media sessions (GSMTC) and builds presence with title, artist, album, playback state, and timeline.
• Creativity Lane Detects 23 Adobe-family desktop apps, from Photoshop and Premiere Pro through the Substance 3D suite, with project-name and window-title display.
• Productivity Lane Detects Word, Excel, PowerPoint, OneNote, Access, Publisher, Visio, Project, and Codex, with project or file-name display.
• Three Discord Apps Each lane connects under its own application ID, so lanes coexist as separate Discord cards instead of overwriting one another.
• Browser Companion Optional MV3 extension supplies high-confidence hints for 14 web players over Chromium native messaging.
• Hint Arbitration Browser hints are scored on playback state, tab visibility, confidence, and age, so a stale background tab cannot hijack the timeline.
• Privacy Modes Per-lane Normal, App Only, and Private modes, plus a sensitive-keyword filter and a blocked app and site term list.
• Detection Modes Choose whether a lane follows the foreground window, any visible window, or foreground with visible fallback.
• Tray-First Workflow Single instance, close to tray, launch on startup, start minimized, and a global Rich Presence master toggle.
• Diagnostics Export and import settings, inspect detection state, and enable source debug mode when a lane misbehaves.

Activity Lanes

The three lanes run independently. Each has its own detector, its own presence manager, and its own Discord application ID, and each can be disabled without affecting the others.

Detection Modes

The Creativity and Productivity lanes decide which app to report using one of three strategies.

Privacy Modes

Conflict & Idle Behaviour

When media and creative activity are live at once, CreativePriorityMode decides which wins: Auto, PreferMedia, or PreferCreative. When an app closes, CreativeIdleBehavior either holds the last card for five seconds (HoldLast5Seconds) or clears it at once (ClearImmediately), which avoids flicker when you are switching between documents.

Installation & Setup

Click the Download button above for the latest installer. Requires Windows 10 or 11 and the Discord desktop client, running. The web client does not expose the local IPC socket that Rich Presence needs.

Building from Source

Requires Visual Studio 2026 with the Desktop development for C++ workload, the MSVC v145 toolset, Node.js on PATH for the extension syntax checks, and Inno Setup 6 if you intend to produce the unpackaged installer.

The verification script restores NuGet packages, builds the solution, runs the extension's JavaScript syntax checks, executes the native guard tests, validates release artifacts, and performs a launch smoke test.

.\scripts\verify.ps1 -Configuration Debug -Platform x64

# Non-interactive runners have no desktop session for the launch smoke test
.\scripts\verify.ps1 -Configuration Debug -Platform x64 -SkipLaunchSmoke

# The MSIX path installs the package, launches it by identity, then uninstalls
.\scripts\verify.ps1 -Configuration Release-MSIX -Platform x64

Browser Extension & Hint Contract

Windows reports browser playback poorly: the timeline is often missing or stale. The optional MV3 extension fills that gap by reading the page directly and sending the desktop app a structured hint.

1. Open chrome://extensions or edge://extensions and enable Developer mode.
2. Click Load unpacked and select the browser-extension/ folder.
3. Open the extension popup to choose whether hints are enabled and which sites may send them.
4. Launch the desktop app once afterwards so it can refresh the per-user native-host registration.

Transport

The extension never talks to the app directly. It posts to a Chromium native-messaging host, which the app itself provides when launched with --browser-native-host; that host then forwards the payload into the running instance over a local named pipe. The app verifies the calling origin and the parent process before accepting anything, and it will not auto-launch if it is closed.

Hint Payload

Every tab reports its own hint. The background worker scores them and forwards only the winner, so a paused background tab cannot override the video you are actually watching. Playback state is worth the most, then tab visibility, then the scraper's own confidence, with older hints decaying.

{
  "schemaVersion": 1,
  "kind": "hint",
  "source": "lrp-browser-extension",
  "timestamp": 1749650412233,
  "data": {
    "service": "YouTube Music",
    "siteKey": "youtube_music",
    "mediaKind": "music",
    "title": "Time",
    "artist": "Hans Zimmer",
    "album": "Inception OST",
    "isPlaying": true,
    "positionSeconds": 191,
    "durationSeconds": 348,
    "pageHost": "music.youtube.com",
    "pageVisible": true,
    "tabId": 42,
    "sequence": 17,
    "confidence": 92,
    "rule": "media-session"
  }
}

When no tab qualifies, the extension sends { "kind": "clear" } instead, and the app falls back to whatever GSMTC reports on its own.

Supported Web Sources

Fourteen players ship with high-confidence scrapers: YouTube, YouTube Music, Spotify Web, SoundCloud, Apple Music, Amazon Music, Deezer, TIDAL, JioSaavn, Gaana, Wynk Music, Bandcamp, Mixcloud, and Twitch. Each can be toggled individually from the extension popup.

Architecture & Component Layout

Detection, presence building, and Discord IPC live in src/core/; the WinUI 3 shell, pages, and tray controller live in src/ui/. Each lane is a vertical slice (detector, presence manager, Discord application), and the browser chain feeds only the media lane. Click a node to jump to the section that documents it.

Last Rich Presence/
├── src/
│   ├── core/                 # Detection, presence building, settings, Discord IPC
│   └── ui/                   # WinUI shell, pages, settings, tray, animations
├── browser-extension/        # Optional MV3 companion extension
├── installer/                # Inno Setup script and installer guide
├── scripts/                  # Build and verification scripts
├── tests/                    # Native guard tests
└── Assets/                   # Branding and curated fallback app logos

Settings & Persistence

Settings are stored in the WinRT ApplicationData local settings container, not a config file you edit by hand. Use the Settings page, or the diagnostics export and import if you want to move a configuration between machines.

Privacy & Network

The app is local-first, but two features reach the network and are worth knowing about before you enable them. Album-art fallback may query itunes.apple.com; if no direct artwork exists and only a thumbnail is available, the app can upload those image bytes to Imgur to obtain a hostable asset URL. Both are governed by the browser privacy and album-art settings, and turning album art off stops them entirely.

Troubleshooting & FAQ

The most common issues seen during install, build, and daily use.

Terms & License

Last Rich Presence is open source under the GNU General Public License v3.0. You may use, study, modify, and redistribute it, provided derivative works remain under the same license and the source stays available.

Adobe, Microsoft Office, Discord, and the streaming services named above are trademarks of their respective owners. This project is not affiliated with, endorsed by, or sponsored by any of them; app detection relies only on publicly visible window metadata.

Last Music Player

A fast native Windows music player for local libraries, with optional remote playback through your own Music API. Offline playback comes first. Remote search, radio, lyrics, and imports stay behind a small provider contract you control.

Overview

Last Music Player is a high-performance, native Windows music player built specifically for local music enthusiasts. It features native integration with the Windows Shell, seamless playback management, SQLite-backed library indexing, and a contract-driven structure allowing users to hook up external audio streaming servers (Music APIs) via plain HTTP endpoints.

Key Features

• Local-First Play standard local formats (MP3, FLAC, M4A, WAV, Opus) with a blazing-fast startup time.
• Gapless Engine Multi-source native queue manager fetches the next song block in advance for zero gap clicks.
• Library Browser Browse by songs, albums, artists, and genres with SQLite-backed indexing.
• Playlists & Mixes Build manual playlists and use auto-generated mixes.
• Synced Lyrics Time-synced lyrics display when a Music API provider is configured.
• Windows Shell Sync Integrates natively with SMTC (System Media Transport Controls), media keys, and system flyouts.
• Google Cast Optional Cast output engine for streaming to Chromecast and Google Nest speakers.
• Discord Rich Presence Optional now-playing status on Discord.
• Music API Provider User-supplied remote catalog for search, streaming, radio, lyrics, and link imports via a simple HTTP contract.

Installation & Setup

Click the Download button above to get the latest release installer. Run the installer to configure the environment. Requires Windows 10 (2004+) or Windows 11.

Building from Visual Studio

To compile and build the client application locally:

1. Clone the repository recursively to fetch submodules: git clone --recursive
2. Open Last Music Player.slnx in Visual Studio 2022.
3. NuGet packages should restore automatically. If not, right-click the solution and choose Restore NuGet Packages.
4. Set the active architecture configuration to x64 (Debug or Release).
5. Build and run. The output binaries will write to the build directories.

Building from Command Line

Use the MSBuild toolchain from the Visual Studio Developer Command Prompt to compile the project headless:

MSBuild.exe "Last Music Player.vcxproj" /t:Build /p:Configuration=Release /p:Platform=x64

The release binaries will write directly to: x64/Release/Last_Music_Player.exe

Custom Secrets (AppSecrets)

For optional features like Discord Rich Presence, the developer API secrets are excluded from Git to prevent leakage. You can configure them locally for custom builds.

Configuration Steps

1. Navigate to the Backend/ directory.
2. Copy the template file AppSecrets.example.h and name the new file AppSecrets.local.h.
3. Open AppSecrets.local.h and insert your custom API client IDs.

#pragma once

// Discord Application Client ID for Rich Presence integrations.
// Replace with your custom Discord Developer Portal Application ID.
#define LMP_DISCORD_CLIENT_ID "your-discord-app-id-here"

Architecture & Component Layout

Last Music Player separates components into distinct native layers. The Frontend manages the WinUI 3 presentation structure, while the Backend handles state, cache, hardware playback queues, and SQLite interactions.

Core Code Directory Structure

Gapless Playback Engine Flow

The AudioPlayer.cpp class manages smooth transitions by utilizing the native Windows.Media.Playback.MediaPlaybackList API. When gapless playback is enabled:

• The currently playing track sits at index 0 of the playlist queue.
• A lookahead worker pre-loads the next song, configuring the audio stream into index 1 of the list in advance.
• When the current song terminates, the player transitions to the next track instantly without closing and reopening the audio channel.

SQLite Database Schema

Last Music Player manages the library metadata and user interactions locally using SQLite. The database stores local tracks scanned from disk, remote tracks resolving from the Provider API, local playlists, and configuration logs.

-- SQL query will display here

Database Versions & Schema Migration

The DB engine implements a version-gate check using PRAGMA user_version. The schema is currently at Version 6.

Music API Provider Contract

If you configure a custom Music API Provider under settings, the player offloads catalog searching, album indexing, streaming, related radio, and synchronized lyrics requests to your provider base URL via HTTP.

-- Code snippet loader

Authentication Standard

The client app communicates the API key configured in settings in two ways:

• JSON Endpoints: Rest query API calls from the client pass the key as an HTTP Authorization Bearer token header:

  Authorization: Bearer <api_key>

• Media Streams & Artworks: Since Windows Media and image rendering pipelines perform native queries direct from the OS stack where custom headers cannot be attached, keys are passed via query strings:

  ?access_token=<api_key>

Troubleshooting & FAQ

Common issues encountered during development, installation, or configuration of Last Music Player client and provider stacks.

Licensing & Contribution Terms

Last Music Player is distributed as a source-available project, not open-source. Using, modifying, or redistributing the application codebase is governed by specific licensing guidelines.

License Summary

The code is subject to the custom Last Projects License 1.0. Key tenets include:

• Personal Use: Free for natural persons studying, building, or modifying the software for strictly personal and non-commercial purposes.
• Modified Source: If you modify the codebase, you are required to publish the modified source code in a qualifying public Git repository within seven calendar days.
• Organizational Restrictions: Non-profits, companies, government institutions, and schools require a separately negotiated commercial license.
• Dataset Constraints: Using the source code or binary outputs for AI training datasets is strictly prohibited without explicit written consent.

Contributor Agreement (CLA)

By submitting code patches or pull requests to the project, you agree to grant ownership and redistribution rights to Last Projects. You can review the details in CLA.md.

For organization license requests or questions, reach out to: info@lastprojects.com.