One receiver, several networks

There is no need to choose a single flag

A receiver can contribute to more than one service through compatible clients. That does not mean every installer is safe to run over every existing installation. Your goal is one clear receiving chain with intentional outputs, not several competing programs trying to operate one USB radio. [1]

Draw your current system before adding a feed. Name the decoder, local map, existing destinations and any MLAT return paths. Look up the new service in the feeding directory, then follow its instructions for an existing receiver.

Choose destinations because you value their coverage, tools, research or policies. A free account benefit is useful, but it should not be the only fact you know about where your observations go.

Messages out and calculated positions back are different streams

A network may want raw, timestamped receiver messages for its own processing. A local map may also display calculated MLAT positions returned by a network. Do not assume that this combined display is a clean source of your own observations for every other destination. Check the documented output and avoid loops. [1] [2]

There is a specific exception worth reading before enabling everything. Flightradar24's sharing page instructs people sharing alongside other networks to disable MLAT in its feeder configuration. Follow that service's current instructions; do not replace them with a generic claim that all MLAT clients can be enabled together. [3]

A checklist for each new destination

1. Read the official feeding guide and the service's terms. Check whether it needs a dedicated client, an account or a receiver identifier.
2. Confirm which existing decoder output it should consume. Verify its format and port on your own host.
3. Keep keys in the intended private configuration, outside screenshots and repositories.
4. Add the feed without replacing the decoder. Enable MLAT only according to that destination's instructions.
5. Check both connection and recent accepted data on the destination's status page.
6. Record how to stop the feed and remove or rotate its key. Then restart and check again.

A successful connection proves that two programs spoke. It does not prove the destination accepted a recent position, or that the data came from your antenna.

What you can share is not what you can reuse

Software licensing, the terms for supplying observations and the terms for consuming a service's API are separate questions. An open-source feeder does not automatically make the receiving service's entire database open for redistribution. A public map does not automatically grant a right to scrape and resell it.

Before building an application on a network's data, read its current API and data-use terms. Check attribution, retention, commercial use and onward sharing. Keep a dated record of the terms you rely on. This guide deliberately does not infer those rights from a network's name or marketing description.

Where Skylark fits

Skylark's documented forwarder reads a compatible local aircraft.json file rather than taking control of the SDR. It is intended to sit beside an existing receiver. Its current documented intake is for direct observations, not another network's aggregate or third-party MLAT results. Publication is approval-gated. [4]

See feeding Skylark for its particular compatibility checks and privacy distinctions. Keep your other feeds. A useful contribution is one you understand and can stop, not one you were talked into by a large green button.