Open-source licensing, community and export controls

Almost every robot today runs on open-source software: Linux, ROS 2, DDS implementations, OpenCV, PCL, Eigen, MoveIt, Nav2, Gazebo and countless Python libraries. Open source is a gift, but it comes with conditions. Each package has a licence that grants rights and imposes obligations, and ignoring them can force a company to publish proprietary code, withdraw a product or face legal claims. Robot software can also be subject to export controls, because some navigation, perception and autonomy technologies have military uses. This lesson explains the main licence families, how to comply when shipping robots, how to work with open-source communities, and the basics of export controls in Canada and the United States.

What a licence does

Copyright law gives the author of software exclusive rights to copy, modify and distribute it. A licence is the author's permission for others to do those things, on stated conditions. Without a licence, code found on the internet cannot legally be reused, however public it is. Open-source licences, approved by the Open Source Initiative against its Open Source Definition, all permit use, modification and redistribution, but they differ in what they require in return. The two broad families are permissive licences, which ask mainly for attribution, and copyleft licences, which require that derivative works be distributed under the same licence.

Distribution is the key trigger for most obligations. Software used only inside a company is generally not distributed; software installed on robots sold or leased to customers is. That is why licence compliance matters so much for robot companies: every robot shipped is a distribution of every open-source component in its image.

Permissive licences

Permissive licences let you combine the code with proprietary software and ship it without publishing your own source, provided you keep the copyright notices and licence text, usually in documentation or an 'open-source notices' screen. Apache 2.0, the default licence for new ROS 2 core packages, adds two important features: an explicit patent licence from contributors to users, which terminates if the user sues over patents in the software, and a requirement to state significant changes. BSD and MIT are shorter and simpler. Their low friction is a large part of why the ROS ecosystem has spread so widely in industry.

Copyleft licences

Copyleft licences use copyright to keep software open. The GNU General Public License (GPL) requires that if you distribute a work based on GPL code, you distribute the complete corresponding source of that work under the GPL too. The details of what counts as a derived work are debated, but statically linking a proprietary program to a GPL library is widely treated as creating one, while separate programs that communicate through pipes, sockets or messages generally are not. GPL 3 adds 'anti-tivoization' provisions for consumer products: users must be given the installation information needed to run modified versions on the device. The Lesser GPL (LGPL) relaxes the rules for libraries so that proprietary programs can use them, typically through dynamic linking, provided users can replace the library. The Affero GPL (AGPL) extends copyleft to software offered over a network, which matters for fleet servers and web dashboards.

The Linux kernel is under GPL 2, so a robot company shipping Linux must offer the kernel source, including its own driver modifications. Proprietary applications running on Linux in user space are not affected, because the kernel's licence notes that normal system calls do not create derived works. Robot companies typically keep proprietary code out of the kernel, publish their kernel patches and drivers, and keep a record of exactly which sources went into each image.

Licence compliance in practice

Compliance is a process, not a one-off check. Companies maintain a policy listing which licences are pre-approved (often Apache, BSD, MIT), which need review (LGPL, MPL) and which are not allowed in shipped products without legal approval (GPL in certain contexts, AGPL). Automated tools scan source and container images, identify components and licences, and produce the SBOM (lesson 10) in SPDX format, which also carries licence information. The release process then generates the required notices and source offers. ROS packages declare their licence in package.xml, and the REUSE specification and SPDX licence identifiers in file headers (such as SPDX-License-Identifier: Apache-2.0) make licences machine-readable.

# A toy open-source policy checker over a release's components (illustrative policy)
policy = {"Apache-2.0": "ok", "BSD-3-Clause": "ok", "MIT": "ok",
          "LGPL-2.1-only": "review", "MPL-2.0": "review",
          "GPL-2.0-only": "review", "GPL-3.0-only": "block", "AGPL-3.0-only": "block"}
components = [("rclcpp", "Apache-2.0", "dynamic"), ("pcl", "BSD-3-Clause", "static"),
              ("libqt", "LGPL-2.1-only", "dynamic"), ("solver_x", "GPL-3.0-only", "static"),
              ("linux", "GPL-2.0-only", "kernel"), ("fleet_db", "AGPL-3.0-only", "server")]
counts = {}
for name, lic, use in components:
    verdict = policy.get(lic, "unknown")
    if lic == "GPL-2.0-only" and use == "kernel": verdict = "ok: publish kernel source"
    counts[verdict.split(":")[0]] = counts.get(verdict.split(":")[0], 0) + 1
    print(f"{name:10} {lic:15} {use:8} -> {verdict}")
print("summary:", counts)

rclcpp     Apache-2.0      dynamic  -> ok
pcl        BSD-3-Clause    static   -> ok
libqt      LGPL-2.1-only   dynamic  -> review
solver_x   GPL-3.0-only    static   -> block
linux      GPL-2.0-only    kernel   -> ok: publish kernel source
fleet_db   AGPL-3.0-only   server   -> block
summary: {'ok': 3, 'review': 1, 'block': 2}

Contributing and community

Using open source well also means participating. Fixing a bug locally and keeping the fix in a private fork creates a maintenance burden forever, since every upstream release must be merged with the private change. Contributing the fix upstream shares the maintenance with the community. Good contributions follow the project's contribution guide, include tests and documentation, are small and focused, and respect the code of conduct. Many projects ask contributors to sign a contributor licence agreement or to certify the Developer Certificate of Origin by adding a Signed-off-by line to each commit, confirming they have the right to submit the code. ROS 2 core repositories use the DCO.

Companies that depend on open source also contribute through funding, maintainers' time, documentation and testing. The ROS ecosystem is stewarded by the Open Source Robotics Foundation, with industry support through the Open Source Robotics Alliance, working groups and special interest groups on topics such as navigation, security and real-time. Before relying heavily on a package, teams assess its health: recent releases, responsiveness to issues and pull requests, number of maintainers, test coverage and licence clarity. A critical dependency with one tired maintainer is a business risk.

Export controls

Export controls restrict the transfer of certain goods, software and technology to other countries, and sometimes to foreign nationals within a country, for national security and foreign policy reasons. Robots and their software can fall under them: high-performance navigation and inertial systems, certain cameras and lidar, encryption functions, unmanned vehicle technology and some AI capabilities appear on control lists, which are largely harmonized internationally through the Wassenaar Arrangement. Publicly available open-source software is often treated differently from proprietary technology, but the rules are detailed and the exceptions have conditions. Sanctions add country- and person-based restrictions on top.

In Canada, exports of controlled items are governed by the Export and Import Permits Act and the Export Control List, administered by Global Affairs Canada, which issues export permits. The list implements the Wassenaar categories, including dual-use items such as certain navigation equipment, sensors, encryption and unmanned systems, plus Canada-specific controls. Sanctions under the Special Economic Measures Act and related laws restrict dealings with listed countries and persons. Companies classify their products against the list, apply for permits where needed and keep records; technology transfers, including sharing controlled technical data with foreign colleagues, can also require permits.

For robot software teams, the practical steps are to know whether the company has an export compliance program, to classify products and significant software components with its help, to be careful when sharing technical data, source code or model weights across borders, and to screen customers and partners against restricted party lists. Rules on advanced computing and AI have changed frequently in recent years, so current guidance must always be checked.