Third-Party Notices and Licensing GuideLink to the section Third-Party Notices and Licensing Guide#

Status: 2026-10-15. This lists the runtime dependencies of the Python reference gateway (gateway/), the .NET SDK (dotnet/src/Univip.Protocol, Univip.Client), the .NET gateway (dotnet/src/Univip.Gateway) and the website (site/), with their licences. It also explains, in plain terms, what someone who distributes these programs has to watch for. It is not legal advice. Licences were read from the packages themselves (NuGet .nuspec and licence files, Python dist-info metadata, npm package.json and licence files, the PyAV wheel's FFmpeg build, ffmpeg -L, Debian copyright files); section 7 says how. Re-check them when a version changes.

1. This repositoryLink to the section 1. This repository#

The code, schemas, API description and tools are Apache-2.0 (LICENSE). The specification text is CC BY 4.0 (LICENSE-SPEC.md).

2. Summary for distributorsLink to the section 2. Summary for distributors#

3. .NETLink to the section 3. .NET#

3.1 SDK (Univip.Protocol, Univip.Client)Link to the section 3.1 SDK (Univip.Protocol, Univip.Client)#

Why JsonSchema.Net is held at 8.0.5. From 9.0.0, the NuGet packages of JsonSchema.Net, JsonPointer.Net (7.x) and Json.More.Net (3.x) declare a licence file, OSMFEULA.txt, the json-everything "Open Source Maintenance Fee Agreement", instead of an SPDX expression. In summary:

• The source code remains MIT.
• The agreement covers only the binary releases the project publishes.
• A monthly fee applies to users who use the software "as part of revenue-generating activities" and have an annual gross revenue of at least US$10,000, unless they already pay the maintainers for support.
• The fee "is not a license fee". The agreement does not restrict compiling from source, or obtaining or redistributing binaries from other sources.

A VMS vendor shipping the SDK with those binaries could owe the fee: the same kind of usage condition that led the project to avoid SIPSorcery. Univip.Protocol therefore pins JsonSchema.Net 8.0.5, whose package and dependencies declare plain MIT. The pin was checked as follows:

• The resolved graph (obj/project.assets.json) is JsonSchema.Net 8.0.5, JsonPointer.Net 6.0.1, Json.More.Net 2.2.0 and Humanizer.Core 3.0.1. Each .nuspec declares <license type="expression">MIT</license>, and the first three ship an MIT LICENSE file.
• 8.0.5 has the API Univip.Protocol uses except EvaluationOptions.IncludeApplicatorErrors. Without that option, 8.0.5 still reports the leaf errors of anyOf/oneOf, but not the summary error of the applicator itself.
• The validator built against each version was run over every repository example and about 8,000 mutations of them (members removed, retyped, set to unknown values; extra members; a higher MINOR), strictly and as a receiver: 16,110 cases. The validity verdict and the tolerated errors were identical in every case. The only difference was the anyOf/oneOf summary errors listed by 9.4.1.
• All .NET test suites pass on 8.0.5.

Upgrading to 9.x would bring the agreement back. Alternatives then are to pay the fee or to build json-everything from its MIT source.

3.2 .NET gateway (Univip.Gateway), in addition to Univip.ProtocolLink to the section 3.2 .NET gateway (Univip.Gateway), in addition to Univip.Protocol#

The gateway also runs an external ffmpeg program for video (section 5.1). It does not link to it.

4. Python gateway (univip-gateway)Link to the section 4. Python gateway (univip-gateway)#

These are the versions installed in the reference virtual environment, with the licence each package declares in its metadata.

What to do.

• For the permissive licences (MIT, BSD, ISC, Apache-2.0, PSF), keep their copyright and licence notices with any binary distribution. Apache-2.0 also asks you to keep NOTICE files (propcache and yarl ship one).
• pymavlink is LGPL-3.0. If you distribute it, provide its source (or a written offer for it), keep its licence, and let users replace it with a modified version. Since Python imports it at run time, the latter is normally satisfied.

5. FFmpeg and H.264 encodersLink to the section 5. FFmpeg and H.264 encoders#

5.1 .NET gateway: FFmpeg as a separate programLink to the section 5.1 .NET gateway: FFmpeg as a separate program#

The .NET gateway starts ffmpeg (found on PATH or through UNIVIP_FFMPEG) as a child process. It writes raw frames to the child's standard input and reads the encoded stream from its standard output. The gateway and FFmpeg are separate programs that communicate through pipes; neither is linked into the other. FFmpeg's licence therefore governs the FFmpeg build, not the gateway, whose code stays Apache-2.0.

media.encoder chooses the encoder:

If you only use an FFmpeg you did not ship, for example one installed from the operating system's packages, there is nothing to distribute and the GPL asks nothing of you.

If you distribute a GPL FFmpeg build, for example in a container image, an appliance or an installer, you must do the following for that build:

• pass it on under the GPL;
• include its licence and notices;
• provide the complete corresponding source of FFmpeg, x264 and the other GPL parts, or a written offer for it.

That obligation does not extend to the gateway, which only talks to FFmpeg through pipes.

5.2 Python gateway: PyAV links FFmpeg and libx264 into the processLink to the section 5.2 Python gateway: PyAV links FFmpeg and libx264 into the process#

aiortc encodes H.264 with av.CodecContext.create("libx264", "w") (aiortc/codecs/h264.py). This was verified in the installed av 17.1.0 wheel (manylinux_2_28_x86_64):

• Metadata. PyAV's own License-Expression is BSD-3-Clause. Its bundled CycloneDX SBOM lists only libxcb, libXau and libdrm, not FFmpeg or x264.
• Reported licence. av.library_meta reports every FFmpeg library as "LGPL version 3 or later". The configure line includes --enable-version3 --enable-libx264 --enable-libx265 but not --enable-gpl.
• Bundled libraries. The wheel's av.libs/ directory nevertheless contains libx264-*.so.165 and libx265-*.so.216. The libavcodec shared library lists both as NEEDED dependencies, and av.codec.Codec("libx264", "w") is available. libx264 and libx265 are GPL-2.0-or-later.

The reported "LGPL" string and the package metadata therefore understate the licence of what the wheel contains: it includes GPL code, linked into the gateway's process. Licence scanners that read package metadata will miss this.

Anyone who redistributes the Python gateway with this wheel should treat the PyAV/FFmpeg part as GPL. In practice that is GPL-3.0, since LGPL-3.0 FFmpeg combined with GPL-2.0-or-later x264 can only go out as GPL-3.0. The distributor must provide the corresponding source of FFmpeg, x264 and x265.

Because the libraries run inside the Python process, it is a legal question whether the gateway itself is affected. The cautious reading is that such a distribution as a whole should be offered under GPL-compatible terms; Apache-2.0 is compatible with GPL-3.0.

Ways to avoid GPL code in a distribution:

• Build PyAV against an FFmpeg without x264/x265. aiortc then has no H.264 encoder, so the Python gateway could offer only VP8.
• Use the .NET gateway with media.encoder: libopenh264 or a hardware encoder.

Other libraries bundled in av.libs/, with the licences of the same projects as given in Debian's copyright files (not all of them are installed here):

5.3 H.264 patentsLink to the section 5.3 H.264 patents#

H.264 is covered by patents licensed through a pool (Via LA). Software licences (GPL, BSD, MIT) do not grant those patent rights. Cisco pays the royalties for the OpenH264 binaries it distributes from its own servers, under Cisco's conditions; a build from source, or a copy you ship yourself, is not covered by that arrangement. Hardware encoders may or may not be covered by the hardware vendor's licence. Products that encode or decode H.264 commercially should get advice on patent licensing. (Proposed spec finding H-S9 asks Part 09 to mention this.)

6. Website (site/)Link to the section 6. Website (site/)#

These third-party files are part of the published site. npm run build copies their licence texts into site/dist/third-party-licenses.txt, which is served at /third-party-licenses.txt.

The generated notice file conservatively includes licence and notice files for the production dependency closure pinned in site/package-lock.json, excluding type declarations. This includes libraries used inside Mermaid's lazy-loaded chunks.

The build tools are not published with the site: Vite 8.3.4 (MIT), TypeScript 7.0.2 (Apache-2.0), markdown-it 15.0.2 (MIT), Shiki 4.5.0 (MIT; only its HTML output is published), github-slugger 2.0.0 (ISC), Vitest 5.0.4 (MIT) and Wrangler 4.151.0 (MIT OR Apache-2.0). site/package-lock.json pins them and their dependencies.

7. How this was verifiedLink to the section 7. How this was verified#

• NuGet. The .nuspec and licence files of each package in the resolved dependency graph (obj/project.assets.json) were read in the local package cache (~/.nuget/packages). Older versions of JsonSchema.Net and its dependencies were checked with their .nuspec from api.nuget.org.
• Python. importlib.metadata was read for the installed runtime closure of univip-gateway[media,mavlink] (License-Expression, License, classifiers and licence files).
• PyAV. Checks used: av.library_meta (configuration and licence strings), av.codec.Codec(...), the wheel's av.libs/ directory, readelf -d on libavcodec, the SBOM in av-17.1.0.dist-info/sboms/, and strings on the bundled x264 and x265 libraries. For pylibsrtp and cryptography, strings on their extension modules gave the libsrtp and OpenSSL versions.
• npm. The license field and the licence file of each package in site/node_modules were read, and site/dist/assets/ was listed to see which of them end up in the published site.
• System FFmpeg. ffmpeg -version, ffmpeg -L and ffmpeg -encoders were run against Ubuntu 24.04's 6.1.1, and /usr/share/doc/*/copyright was read for x264 and the other libraries.