Bus Engine Licensing
Source access, binaries, and release materials.
This page summarizes licensing boundaries for Bus Engine OS release materials and Bus Engine source-access modules. It does not replace the applicable license texts, checkout terms, written agreements, or legal review.
Software boundary
Bus Engine OS combines components under multiple licenses. Open-source components remain under their respective licenses. Bus-owned operating-system integration modules are provided under their published source-access terms. Proprietary BusDK userspace products remain subject to their commercial licenses.
| Component family | Licensing treatment |
|---|---|
| Third-party open-source software | Distributed under the applicable upstream licenses with required notices, license texts, corresponding source, patches, and build materials where required. |
| Bus-owned Engine codebase | Monthly access uses the Functional Source License for Bus-related source code, with covered versions converting to MIT or Apache 2.0 after two years. The one-time option includes the current Bus Engine product-line codebase under MIT or Apache 2.0 at purchase plus one year of FSL-licensed updates. |
| Proprietary BusDK userspace products | May be distributed as binary-only commercial software where legally permitted and where no combined-work license requires source disclosure. |
FSL applies only to Bus-related code licensed by us. Third-party software, including open-source packages and separately licensed runtimes, keeps its own license terms.
Customer source delivery
Bus Engine does not offer source code publicly by default. For customer-only downloadable releases, recipients of GPL, LGPL, MPL, and similar covered binaries must receive or be able to obtain the corresponding source required by those component licenses. Covered source is provided to those recipients through the same customer release area at no extra charge, without turning the public marketing site into a source-code portal.
Release area contents
A Bus Engine OS release area should be prepared to include binary artifacts, checksums, package manifests, corresponding source archives, local patches, package and image build definitions, scripts needed to compile and install the covered binaries, license texts, copyright notices, third-party notices, and source-access instructions for Bus-owned source-access modules.
Providing only an upstream link is not enough when a distributed binary differs from upstream. The materials must correspond to the binary actually delivered to the recipient.
Redistribution rights
Customers receiving GPL-covered components receive the GPL rights for those components, including the right to copy, modify, and redistribute them. Commercial terms must not add restrictions that conflict with those open-source licenses. Permissive licenses such as MIT, BSD, and Apache generally allow binary-only redistribution of proprietary additions, but required notices and license terms must still be preserved.
Aggregate and combined-work review
A Linux installation image is usually an aggregate of separate programs, so including GPL, permissive, source-access, and proprietary programs in one image does not automatically put every independent program under the GPL. Actual linking, incorporation, plugins, shared libraries, generated code, and kernel module boundaries require fact-specific review before release.
Legal and compliance review
Before commercial release, Bus Engine OS release materials should be reviewed against the final SBOM, license expressions, modified-file notices, source bundles, combined-work boundaries, EULA carve-outs, trademark use, and any product-security obligations that apply to the target market.