License

dev3d is free software under the GNU Affero General Public License, version 3 or later. The identifier is AGPL-3.0-or-later. This page explains what that licence is, why this project chose it specifically, what it asks of you in the situations people actually find themselves in, and what it does not ask.

What the licence is

Four things are worth knowing before anything else:

• It is a strong copyleft licence. If you convey the program, or a work based on it, to someone else, they must receive the same freedoms you had — including the source and the right to modify it. You cannot take dev3d, change it, and hand out a binary with the changes locked up.
• It is the GPL version 3 plus one section. The AGPL is not a different philosophy from the GPL; it is GPLv3 with section 13 added, aimed at software whose primary use is being a server. Everything else in the GPLv3 — the patent grant in section 11, the anti-lockdown terms in section 6, the termination and cure procedure in section 8, the warranty disclaimer in sections 15 and 16 — carries over unchanged.
• "or later" is a choice you get to make. The project offers the licence as version 3 or any later version published by the Free Software Foundation. If the FSF ever publishes an AGPL v4, you may take dev3d under that instead. Nothing forces you to; if you prefer to be governed by exactly v3, you may treat it that way.
• There is no warranty. Sections 15 and 16 disclaim it as far as the law allows. The software is provided as-is. That matters more than usual here: the orchestrator runs shell commands and writes files in a workspace you point it at.

The authoritative text is the LICENSE file at the root of the dev3d repository. It is the verbatim GNU AGPL v3 text, 661 lines of it, and it carries no project copyright line of its own — the only notice inside the file is the Free Software Foundation's. The machine-readable identifier appears in all four package.json files in the repository: the root, apps/server, apps/web and packages/core. If a page on this site and the licence text ever disagree about your obligations, the licence text wins.

Why this licence, and not a permissive one

dev3d is designed to be operated as a server. That is not an incidental detail of its packaging — it is the shape of the product. The office is a browser console that connects to a local process over a WebSocket, and that process holds the provider keys, the SQLite database, the workspace directories and the plugin host. Everything valuable happens on the machine running the server, and the browser is a view onto it.

Under a permissive licence — MIT or Apache-2.0 — someone could take dev3d, modify it, host the modified version as a service, and never publish a line of what they changed. Nothing in the licence would require it, and nothing in the architecture would make it hard: the user never receives a binary, so there is no distribution event to hang an obligation on. That is the one outcome the project's own design makes likely, which is why the licence was picked to close it.

An ordinary GPL would not have closed it either, and it is worth being precise about why. The GPL's obligations attach to conveying the program to someone else. Running a program on your own server, letting other people reach it over a network, and never shipping them a copy is not conveying it under GPLv3 — that was the long-standing "application service provider" loophole. Section 13 of the AGPL exists for exactly that case and no other. The project did not choose the AGPL because it dislikes commercial use (it does not), or because it wants to force contributions back into upstream (it cannot — the licence requires source for your version, offered to your users, not a pull request to this project). It chose the AGPL because the likely failure mode of a permissively licensed orchestrator is a hosted fork that never gives anything back, and the AGPL is the one standard licence that speaks to that case.

The network clause: section 13 in plain terms

Section 13 is headed Remote Network Interaction. The operative sentence, stripped of its cross-references, says this: if you modify the program, your modified version must prominently offer all users interacting with it remotely through a computer network the opportunity to receive the Corresponding Source of your version, by giving them access to that source from a network server at no charge.

Read carefully, that sentence has five parts that each matter:

1. The trigger is modification and remote users — not "running a server". You can run dev3d as a long-lived service with a hundred users and, if you have not modified it, section 13 does not apply to you at all.
2. The users have to be interacting with it remotely. The dev3d console talking to the server over the WebSocket is precisely that interaction. So is a colleague on the same office network opening the console in a browser. So is a paid customer of a hosted fork.
3. The offer has to be prominent. A URL nobody can find is not an offer. In practice: a link in the console itself, a line on an about or status page, or a documented address a user is told about. "It is on GitHub somewhere" does not satisfy it if your version differs from what is on GitHub.
4. The source you must offer is your version's. Not upstream's repository, and not a diff. If you changed routing weights, added a provider, patched the tool sandbox or replaced the store, those changes have to be available as source.
5. At no charge. You may charge for the service, for support, for hosting, for anything you like — but you may not make access to the source a paid extra. Handing someone a tarball on request satisfies it; so does a public branch; so does a written offer valid for a stated period.

Section 13 has a second paragraph about combining the program with GPLv3-covered material — if you link or combine the two into a single work and convey it, the Corresponding Source has to cover the whole combination in the way section 13 describes. That is the same aggregation-versus-combination line as the GPL, applied to the network case.

The two common cases, and four more

The honest summary is that almost everybody falls into the first row, and the licence asks nothing of them. The table below spells out the cases that actually come up.

What you are doing	What the AGPL asks	What it does not ask
Running it unmodified for yourself, or for your own team, with no changes to the source	Keep the licence and the notices intact if you pass a copy on	Any publication, any contribution, any payment. Nothing about your prompts, your workspace or your data.
Running it unmodified and letting other people use it over a network — a shared console for your team, or a paid service on a stock build	Nothing beyond keeping the licence intact. You are not distributing a modified version, so section 13 is not triggered.	Offering anyone your source. There is nothing of yours to offer; upstream's source is upstream's.
Modifying it and keeping the modified version entirely to yourself, with no remote users	Nothing. Modification is unrestricted and private modification is unrestricted.	Publishing your changes.
Modifying it and letting other people use that modified version over a network	Offer those users the Corresponding Source of your version, prominently, at no charge. This is section 13.	A public repository, a specific host, a specific format, or a pull request to this project. A tarball behind a URL in your console is enough.
Conveying a modified build to someone as a product they install	The full GPLv3 conveying terms: source or a written offer, the notices, the installation information required by section 6 where it applies	That they publish their own modifications — the obligation travels with the copy you conveyed.
Embedding dev3d into a larger proprietary product	Section 13's combination paragraph applies if the result is one work. In practice this is the case to get advice on, or to avoid.	—

What "Corresponding Source" means

The AGPL defines it in section 0, and the definition is deliberately broad: all the source code needed to generate, install, and for an executable work run the object code, and to modify the work, under the same licence. Concretely, for a modified dev3d, that means:

• The modified TypeScript sources for every workspace you changed — apps/server, apps/web, packages/core.
• The scripts and configuration needed to build and install it: the package.json files, the lockfile, the TypeScript configuration, the build scripts. If you added a build step, that step's own inputs are part of it.
• The interface definition files and anything else needed to modify and rebuild — the point is that a competent person can take what you offered, change it, and run the result.

What it does not include:

• System libraries and general-purpose tools that are not part of the work — Node itself, the operating system, a compiler, a database engine you did not modify.
• Your data. The SQLite store, your prompts, the contents of your workspaces and your provider keys are not source code and are not covered.
• A diff against upstream. A diff is a helpful thing to also publish, but the definition asks for source, not for the delta.
• A hosted repository. The licence asks for access to the source from a network server or a written offer; it names no forge and no format.

Why a plugin is separate work

A plugin is your own work. Loading one into the orchestrator does not make it a derivative of the orchestrator, and the project does not ask you to licence a plugin under the AGPL.

The reason is the shape of the interface rather than a legal fudge. The host imports your entry module and hands it one small object with five members: manifest, settings, log, registerTool and on. It does not hand over the router, the store, the run engine or the office state. Everything a declarative plugin contributes — models, skills, routing rules, role templates, pipelines, panels — is data that the host validates and then acts on itself, so no code of yours runs at all. A code plugin's tools are registered under a name derived from your plugin id and handed the run's workspace root, which is a convenience rather than a cage: the module runs in the orchestrator's own process, so its reach is that process's reach. That narrow, documented interface is the same line the Free Software Foundation draws when it explains that a plugin using only a program's documented interface is generally a separate work.

Three honest caveats:

• This is a description of an interface, not a legal opinion about your plugin. A plugin that copies dev3d source into itself, or that is deliberately incomplete without dev3d in a way that makes the two a single work, is a different analysis — and it is your analysis to make.
• A plugin's own licence is the publisher's choice. The marketplace stores whatever license string a manifest declares and shows it on the listing as a badge, so a plugin can be MIT, Apache-2.0, proprietary, or AGPL itself. The site's listing table falls back to MIT when a manifest names no licence — that is a database default for a missing field, not a claim about your intent, and you should always fill the field in.
• Loading a plugin is loading code. For a code plugin the host genuinely imports and runs your module in the orchestrator process, with the orchestrator's authority. That is a security fact the terms and the plugin guide both state plainly; it is not a licensing fact, and it does not change the separate-work analysis.

If the AGPL does not suit your situation

Because the project holds the copyright, it can license the software differently for a specific use. If you need dev3d under other terms — embedding it in a proprietary product, shipping a closed derivative, or an internal policy that simply forbids AGPL — the way to ask is the contact form. Say what you want to do with it, and you will get a straight answer about whether that is something the project is willing to license and on what basis. Nothing on this page is a promise that any particular request will be granted.

There are also three routes that avoid the question entirely, and they are usually the better ones:

1. Talk to the office over its wire protocol instead of embedding it. A separate process that connects over the WebSocket is a separate program. That is a genuine boundary, not a technicality.
2. Write a plugin rather than a fork. Your work stays yours, under your licence, and it survives upstream upgrades. This is the route the project actually wants people to take.
3. Run upstream unmodified and keep your integration outside it. Configuration, skills, pipelines and provider settings all live outside the source tree, and changing them is not modifying the program.

What the licence never requires, in any of these cases: publishing modifications you never let anyone else use, contributing anything back, paying anything, or asking permission to run the software.

Questions people actually ask

Can I use dev3d commercially, at work, for client projects?

Yes. The AGPL is a free-software licence, not a non-commercial one. You can run dev3d to do paid work, use it inside a company, use it to produce deliverables you sell, and charge for the work it helps you do. There is no fee, no registration and no restriction on the output. The only thing you cannot do is take the source, modify it, and convey or serve the modified version without giving its users the source.

Can I host dev3d as a service for other people?

You can. If you host an unmodified build, section 13 asks nothing of you at all. If you host a modified build, you must prominently offer every user interacting with it over the network access to your version's Corresponding Source, at no charge. There is no threshold of users, no revenue test and no requirement to ask anyone's permission first. If you patch the router for your own hosting setup, that patch is part of what you offer.

What licence does my plugin have to be?

Any licence you like. The plugin you write is your work, and the orchestrator's licence does not reach into it, provided you are using the documented plugin interface rather than copying dev3d's code into your plugin. Declare the licence honestly in the manifest's license field so the listing shows it, note that a code plugin runs with the orchestrator's authority, and consider that a plugin under a permissive licence is easier for other people to trust and adopt.

What exactly is "Corresponding Source", and is a link to my repository enough?

Corresponding Source is the source needed to generate, install, run and modify the work — your modified dev3d, plus its build and install scripts. A public link to the branch you actually deploy is a perfectly good way to satisfy section 13, if it is the version you are running and the offer to reach it is prominent. A link to a stale mirror, or to upstream's repository when your build differs from it, is not. If your version is private, a written offer to provide the source on request, valid for a stated period, is the usual alternative.

What to check if you are unsure

Your question	Where the answer is
What does the licence actually say?	LICENSE at the dev3d repository root — the verbatim AGPL v3 text, 661 lines
Did I modify the program?	Did you change anything inside apps/server, apps/web or packages/core? Changing skills, plugins, pipelines or settings does not count.
Do remote users interact with my version?	Does anyone but you open the console, or call the API, or use a tool that reaches your server? If yes to both this and the row above, section 13 applies.
Have I satisfied it?	Is there a prominent, working, no-charge route to the source of the version you are actually running?
Is a plugin covered?	No — unless it copies dev3d's code into itself or is otherwise part of the same work. Declare its own licence in the manifest either way.
Can I license differently?	Ask. The copyright holder can license otherwise; this page cannot promise the answer.

Related reading: the terms for using this site, the marketplace policy, the plugin guide and architecture decisions, which records why the licence was chosen alongside the other structural decisions.