Skip to main content
You wrote it; you keep the rights. The plugin system is designed around the idea that plugin authors own their work and pick the licensing model that suits their goals. The Altnautica registry is one distribution channel among several; it does not change who owns or licenses what.

​
You can monetize plugins

Nothing in the plugin system stops you from charging for your plugin. You can:
  • Sell licences directly to operators.
  • Ship a closed-source proprietary plugin under your own EULA.
  • Run a subscription or activation server and have your plugin check in against it.
  • Bundle paid support, updates, or a hardware product.
  • Offer a free open-source community edition plus a paid pro edition under different licenses.
How you handle pricing, billing, taxes, refunds, support, EULAs, and commercial contracts is entirely up to you. Altnautica is not a party to your transaction with your customers.

​
Pick any license

Declare the license in the manifest using a valid SPDX identifier or expression: 
plugin:
  license: "GPL-3.0-or-later"      # OSS
  # or
  license: "Apache-2.0"            # OSS, permissive
  # or
  license: "MIT"                   # OSS, permissive
  # or
  license: "BSD-3-Clause"          # OSS, permissive
  # or
  license: "LicenseRef-MyProductEULA-1.0"   # your own commercial EULA
For SPDX, see spdx.org/licenses. For custom or proprietary licenses, use the LicenseRef-<your-id> form and ship the full license text in the archive at LICENSE.txt. The host runtime does not gate plugins by license at install time. Operators see the declared license string in the install dialog and can decide whether they accept it. The agent and the GCS are licensed GPL-3.0-or-later. If your plugin links into the same process (the GCS iframe is a separate process by default; the agent’s inprocess isolation mode is the case that matters) then the GPL’s copyleft can apply. The practical patterns:
  • GPL-friendly host integration. Default. The agent runs third-party plugins as separate subprocesses over a defined IPC surface. The GCS sandboxes plugins inside iframes that communicate by postMessage. Subprocess and iframe boundaries are widely treated as license boundaries; your plugin can ship under a license different from the host without copyleft reaching into your code.
  • Inprocess isolation. Reserved for first-party Altnautica plugins. Third-party plugins do not get inprocess linkage today, so the GPL-linkage question does not arise.
  • Vendor SDKs. A proprietary SDK loaded by your plugin runs inside your plugin’s subprocess, not the host’s. You are responsible for whether the SDK’s licence allows distribution with your plugin. See Vendor binaries.
If you are uncertain whether your distribution model is compatible with the GPL, talk to your own counsel. Altnautica is not your lawyer.

​
How distribution channels interact with licensing

There are three distribution channels for plugins. Each one has different requirements.
ChannelHostingLicense requirement
Local file installOperator drops a .adosplug archive on the device.Any license. The archive moves between two parties without Altnautica in the loop.
URL installYou host the archive on your own server. The agent fetches it.Any license. The agent verifies the signature; it does not check the licence string against an allowlist.
Hosted registryAltnautica hosts the archive on its registry.The publisher must grant Altnautica the right to redistribute the archive.
For commercial closed-source plugins, URL install is usually the right channel. You keep your archive on your own infrastructure, your own gating logic decides who gets the download URL, and your EULA is part of your transaction with the operator. The agent does not need to know any of that. The hosted registry is best for OSS plugins where free redistribution is the intent. For commercial offerings, the registry’s auto-publish gate is OSS-licence-only and discretion on hosted distribution rests with the registry operator.

​
The hosted registry’s auto-publish list

The Altnautica-hosted registry’s auto-publish path accepts these licenses without manual review (when the registry is live):
LicenseSPDX idNotes
GPL-3.0-or-laterGPL-3.0-or-laterRecommended for plugins that link with the agent or the GCS, both of which are GPL-3.0-or-later.
Apache-2.0Apache-2.0Permissive. GPL-compatible in the consumer direction. Includes a patent grant.
MITMITPermissive. GPL-compatible.
BSD-3-ClauseBSD-3-ClausePermissive. GPL-compatible.
Anything else routes to manual review at the registry operator’s discretion. The same plugin can ship through URL install with no review involved.

​
Vendored binaries

Some plugins must ship vendor SDKs (camera firmware, gimbal control libraries, RKNN model files with their own license). Declare every vendored binary in the manifest: 
assets:
  - path: "vendor/example-sdk/libexample.so"
    role: "vendor-binary"
    sha256: "<computed-by-pack.sh>"
    license: "Proprietary"
    license_file: "vendor/example-sdk/LICENSE.txt"
    vendor_name: "Example Vendor"
    vendor_url: "https://example-vendor.example.com"
  - path: "vendor/example-sdk/LICENSE.txt"
    role: "license-text"
    sha256: "<computed-by-pack.sh>"
Rules for vendored binaries:
  • Each vendored binary must declare its own license and ship the full license text inside the archive at vendor/<name>/LICENSE.
  • The plugin’s overall plugin.license is independent. A GPL-3.0-or-later wrapper around an Apache-2.0 vendor SDK is fine. A GPL-3.0-or-later wrapper around a proprietary SDK is fine provided the proprietary terms allow distribution.
  • The manifest’s vendor-binary flag triggers mandatory subprocess isolation (no inprocess) and a bumped risk band on the install dialog.
  • The static analyzer never inspects vendor binaries; the publisher is on the hook for what they ship.
  • Operators see the vendor name on the install dialog and on the plugin detail page, with a link to the vendor URL and the bundled license text.
If a vendor SDK forbids redistribution, the plugin cannot be hosted on the registry. URL install from the vendor’s own server is the fallback; the agent treats vendor-binary archives the same way regardless of how they arrived.

​
Patent grants and DRM

Plugins that bundle DRM, attempt to enforce DRM, or include software patents that they assert against the host or other plugins are rejected. The registry’s redistribution right is conditioned on the publisher not asserting patents against the host runtime or against other plugins running on the same host. Add a SECURITY.md at the root of your plugin’s source repository. The file should cover:
  1. How to report a security issue (preferred contact channel).
  2. PGP key or signal channel for sensitive reports.
  3. Your typical response cadence so reporters know what to expect.
  4. The current major versions you support with security fixes.
  5. Whether you publish post-mortems.
The static analyzer reads the linked source repo at submit time. A present SECURITY.md is a soft signal that nudges a borderline submission toward auto-publish. A missing SECURITY.md does not block submission.

​
Trademark policy

Altnautica brand assets are reserved. Specifically:
AssetReserved
The name “ADOS”Reserved as a product family name. Plugins must not call themselves “ADOS X” or “ADOS-something”.
The name “Altnautica”Reserved. Do not use in plugin names, descriptions, or icons.
The Altnautica logoReserved. Do not embed in your plugin’s icon or screenshots.
The Mission Control logoReserved. Same rule.
The Drone Agent logoReserved. Same rule.
Domain names containing altnautica or adosReserved.
What is allowed:
  • Stating compatibility: “Works with the ADOS Drone Agent”, “Mission Control plugin”, “for ADOS Mission Control”.
  • Pointing to the Altnautica docs or GitHub from your README.
  • Using the standard manifest field compatibility.ados_version to declare the agent versions you target.
Pick a plugin name that is yours. The reverse-DNS plugin id in the manifest (com.your-name.something) makes namespace ownership explicit. If you are an integrator or partner who wants to use the trademarks in marketing material, get in touch through the contact channel on altnautica.com for a trademark usage agreement.

​
The registry’s role: distributor, not author

The registry hosts archives published by their authors. The registry does not author the plugins. Specifically:
  • The registry redistributes signed archives the publisher uploaded.
  • The registry runs static analysis at submission time as a defense-in-depth measure, not as a quality endorsement.
  • The registry hosts metadata (description, screenshots, README) the publisher provided.
  • The registry does not modify the archive bytes after upload.
A plugin’s behavior at runtime is the publisher’s responsibility. The host’s containment (signatures, permissions, sandboxing) is the registry’s collaboration with operators to limit blast radius.

​
No warranty

The agent and the GCS ship under GPL-3.0-or-later, which carries no warranty. Plugins inherit the same default. Specifically:
  • Plugins distributed via the Altnautica registry come with no warranty from Altnautica.
  • The plugin’s own license governs what the publisher warrants. A GPL-3.0-or-later plugin disclaims warranty per GPL section 15.
  • Verified-publisher status is not a warranty. It is a domain- ownership proof plus a track record on the registry.
  • The static-analyzer report is a snapshot of detected patterns at submission time. It is not a security audit.
Operators run plugins at their own risk. The host’s job is to make that risk visible (risk badge, permission set, signer trust, revocation list) and bounded (subprocess isolation, capability checks, resource limits).

​
Hosted-registry availability

The Altnautica-hosted registry is best-effort and is not yet live. When it ships, the operations terms (availability targets, status page, incident communication) will be published alongside the launch. Until then, the local-file install path and the URL install path are the supported channels. If your deployment needs contractual availability terms, run a self-hosted registry. The agent and the GCS work identically against your own endpoint, and the operating terms become whatever your own infrastructure provides.

​
See also