Licensing #

arena builds a container image out of other people's work. This covers what those licences require and what we do about it. Short version: publish our changes, stay non-commercial, and keep the control plane a separate process.

A different architecture would not avoid any of it.

What is in the image #

	licence	what it asks
MegaMek code	GPL-3.0	ship our modifications as source
MegaMek data & assets	CC BY-NC-SA 4.0	non-commercial, attribution, share-alike
Suramadu	AGPL-3.0	as GPL, plus offer source to network users
Java runtime (Temurin)	GPLv2 + Classpath Exception	nothing; the exception covers normal use
Chakra Petch	OFL 1.1	ship the licence text with the font
arena's own code	GPL-3.0	ours, matching MegaMek

What we have to do #

1. Publish this repository. Patches, configs, scripts, all of it. Suramadu is AGPL and we serve it over a network, so §13 requires us to offer source to the people using it. Publishing removes the question entirely, and we have no reason to keep any of this private.

26.4.7 also puts that offer on the page itself, as a fixed source notice in the war's index.html. We serve our own copy of that page, so the notice is carried across in suramadu/web/index.html and styled in theme.css; dropping it would drop the one thing a network user actually sees.

2. Keep the container and the control plane separate processes. headquarters talks to arena over HTTP and never links a Suramadu jar. That boundary keeps the control plane outside the AGPL's reach, and it is a reasonable design in any case. See docs/launch-manifest.md in the headquarters repo; the manifest is that boundary.

3. Stay non-commercial. Two separate obligations require it: MegaMek's asset licence and Microsoft's Game Content Usage Rules. Accepting donations for hosting is generally considered fine; selling access is not.

Suramadu, not Webswing #

We use Suramadu, the AGPL-3.0 community fork by manticore-projects continuing from Webswing v20.2.5, the last release under that licence. We have no affiliation with the commercial product at webswing.org.

The fork was called "Webswing Lite" until 26.4.6, when it took the Suramadu name and renamed its artifacts with it — the archive, the war, suramadu.config, suramadu.properties and the frontend bundles. That rename is what removes the confusion the old "always write it in full" rule existed to manage, so the rule is gone.

What did not rename is the part a build actually binds to. The whole webswing.* system-property namespace survived intact — all ~200 of them, from webswing.appId to webswing.window.theme.titleHeight — as did every org.webswing.* package and the server's token_cookie. Upstream kept them so existing installations keep working, and we must keep writing them too:

stays webswing	where we use it
org.webswing.* Java packages	-Dawt.toolkit, the log4j2 stats logger
org.webswing.window.theme.*	window colours in the app config
webswing.drawDelayMs, webswing.dd*CacheSize, webswing.trustedFontDirs	client JVM tuning
webswing.websocketMessageSizeLimit	server JVM flag in the entrypoint
org.webswing.server.*	jetty.properties keys
webswing-loader-stub.js, data-webswing-*, window.webswing	the served index.html

A webswing string in this repo should be one of the above. Anything else is a leftover.

The trap runs the other way too: a suramadu string that upstream does not use is just as wrong, and harder to spot because it reads correct. webswing-embed.js did become suramadu-embed.js, but webswing-loader-stub.js beside it did not. Check the artifact before renaming; suramadu/verify-web.sh catches the ones that reach index.html, and nothing catches the rest.

The fork's README asks for attribution to the Webswing team for the original architecture, and we give it.

The distribution ships no LICENSE file. We redistribute it, so the Dockerfile's suramadu stage fetches the AGPL text into the bundle, and fails the build if it cannot.

Why AGPL matters more than GPL here #

Plain GPL would not reach a hosted service: running modified MegaMek on our own servers triggers no disclosure by itself. AGPL's §13 adds the network case, which is the case we are in.

It is also not cleanly separable from MegaMek. Suramadu does not proxy a separate process — it injects into the application JVM:

-Xbootclasspath/a:...suramadu-app-toolkit.jar:...modpatch-java-desktop.jar
--patch-module java.desktop=...modpatch-java-desktop.jar
-Dawt.toolkit=org.webswing.toolkit.WebToolkit11

MegaMek runs inside a JVM whose java.desktop has been patched with Suramadu code. Whether that combination counts as one work is an open question, not a clear no. That is why we publish, and why none of our code runs inside that JVM: MatchHost and MatchWatcher are separate processes using MegaMek's normal network protocol.

GPL-3.0 and AGPL-3.0 are compatible — GPLv3 §13 allows the combination — so there is no conflict, only the network clause to comply with.

Our patches #

Nine, in megamek/patches/patchset/, stored as unified diffs rather than copied source files. A copied file would silently discard upstream changes on the next release; a diff fails to apply instead, which is the behaviour we want.

Each one fixes a MegaMek bug rather than adapting MegaMek to our environment, so all nine should go upstream. An accepted PR costs nothing to maintain; a carried patch costs something every release. megamek/verify-patches.sh runs on every build and checks that the patched jar differs from stock in exactly those classes and no others.

Three more, in suramadu/patches/, applied to the frontend bundle inside the Suramadu war: keyboard input sent immediately, mouse input flushed faster, and frames acknowledged on receive rather than after paint. Suramadu is AGPL-3.0, so the same rule applies with more force — we serve the modified code over a network.

The patches ship inside the image at /opt/arena/patches (Suramadu's under patches/suramadu/), so the source of our modifications is distributed with the binaries that contain them.

BattleTech IP #

MegaMek operates under Microsoft's Game Content Usage Rules. Its notices state:

MechWarrior, BattleMech, 'Mech and AeroTech are registered trademarks of The Topps Company, Inc. Catalyst Game Labs and the Catalyst Game Labs logo are trademarks of InMediaRes Productions, LLC. MechWarrior Copyright Microsoft Corporation.

In practice:

• Keep the marks out of our own naming — BattleTech, BattleMech, 'Mech, MechWarrior, AeroTech, Alpha Strike, Clan names, Catalyst product names. This is why the domain is lance.blue: generic military vocabulary, no mark.
• Lore vocabulary inside internal identifiers is lower risk than in a brand or a domain, but keep it out of anything public-facing.
• We ship no artwork or unit data of our own. We run MegaMek's, under MegaMek's terms.

The boot screen's font #

suramadu/web/fonts/ holds Chakra Petch 700, the one face on the loading screen, under OFL 1.1. The licence asks for two things and both are already true: its text travels with the font, in OFL-Chakra-Petch.txt beside the woff2 files, and the font is not sold on its own. The whole of suramadu/web/ is copied into the image, so the licence reaches players by the same route the font does.

There is no Reserved Font Name on this family — the copyright line in that file carries no such clause — so a modified copy could keep the name. We ship unmodified downloads anyway, which keeps the question closed.

The insignia beside it, suramadu/web/insignia.svg, is our own artwork, copied from headquarters. Nothing is owed on it.

Before adding a dependency #

1. What is the licence, checked in the artifact or the repo — not from a search result or from memory? This project has already got that wrong once.
2. Is it AGPL, or otherwise network-triggering?
3. Does it require non-commercial use, and does that change anything?
4. Does it run in-process with MegaMek, or at arm's length?
5. Is it easily confused with a commercial product of a similar name — and if so, is the distinction stated everywhere?