I'm working in a company that develops and sells embedded systems. We are using Linux and some GPL software, alongside proprietary software. Some of the GPL softwares are modified to fit our needs.

Also, we are using a GPL tool to build our filesystem images, that is obviously modified by us.

What are my legal obligations regarding the distribution of all the modified content ?

I've been reading that I should also release / give instructions for rebuilding entirely the filesystems, which would lead me to release the entire build system, and would mean to release company knowledge for free.

  • Are you talking about GPLv2, GPLv3, GPLv2+, or some combination thereof? There are significant differences between GPLv2 and GPLv3 for embedded software. Commented Oct 19, 2018 at 15:45

2 Answers 2


First of all, you may want to discuss GPL compliance with your company's legal counsel and develop a clear strategy for dealing with GPL code. Complying with the GPL is not necessarily difficult, but it can place surprising obligations on you.

The intention of the GPL is effectively an end user protection effort, so that end users of the GPL-covered software always have the freedom to inspect and fix their software. To this end, it is necessary that the source code is available and that users can install modified versions. The different GPL versions express this intention in different terms.

The license of a GPL-covered software does not extend to any data processed by this software. If you have a GPL-covered tool that creates file system images, those images are not immediately covered by the GPL. However, if the images contain GPL-covered parts then those parts and only those parts are GPL covered. It is perfectly fine to have an image that contains both GPL-covered and differently-licensed parts side by side, as long as recipients of that image are free to exercise their rights under the GPL on those GPL-covered parts (such as making copies of the GPL-covered parts).

The GPL requirements only trigger when you distribute/convey/sell GPL-covered software. Purely internal use of a GPL-covered tool does not place any obligations on you.

  • For example, you might have a modified version of GCC to build your proprietary software. This is perfectly allowed and you are not required to publish your modified GCC version. (GCC is covered by the GPL.)
  • As a different scenario, you might have modified a GPL-covered software so that it requires your internal build tools, and you distribute binaries of the modified software. You are required to publish the corresponding source of your modified version. The corresponding source includes any scripts, tools, and other files that are necessary to build the software. This could include your internal tools.

For the GPL-covered software that you distribute as part of your embedded system (whether modified or not) you have to provide

  • licensing and copyright information (also applies to other open-source software)
  • source code of the GPL-covered software
  • possibly: installation instructions for GPLv3-covered software

How to provide the source code depends on the GPL version. For the case of an embedded system:

  • GPLv2 requires that you provide the machine-readable source code directly on a customary medium, or provide a written offer that is valid for at least three years.
  • GPLv3 requires that you provide the source code directly on a physical medium, or provide a written offer valid for at least three years and valid for your customer support duration. The offer may be for a physical medium or may refer to a download server.

In case you provide an offer, the offer must be valid for whoever obtains your software, not just your immediate customers. (Consider that customers may resell or lend their devices.)

The GPLv3 contains further requirements in case your embedded system is a “User Product”, i.e. intended for personal use or intended to be incorporated into a dwelling. If a device is normally used for both personal and other uses (e.g. commercial or industrial) it is still a User Product.

For User Products, you also have to provide installation information so that users can install and run modified versions on the device. This includes any passwords or signing keys necessary for such an installation. This obligation cannot be circumvented by leasing rather than selling the devices. You don't have to provide installation information if such an installation would be impossible, e.g. for a microchip with read-only memory.

You may want to review the open source software that you include in the embedded system:

  1. List any open source software with their copyright information and licenses. This is easiest if you build everything from source yourself.
  2. Make sure that your manuals etc. contain the necessary attributions as required by those licenses.
  3. In case GPL or LGPL code is copied into your proprietary software or is linked with your proprietary software, inspect the licensing status more clearly: your proprietary software may be covered by the GPL. Here, I'll assume everything is a standalone executable.
  4. For any GPL- or LGPL-covered software, prepare to publish the source code. Ideally, your release process creates source archives of the GPL-covered software and then builds the binaries from those source archives, to ensure that the archive contains the corresponding source. Decide how you will publish the source code (e.g. CD-ROM in the device packaging, or a written offer in the manual). If you offer a download link, add an item to your release checklist to upload the source archives to your server (or better yet, automate this).
  5. For any GPLv3- or LGPLv3-covered software, add the necessary installation information to the manual.
  • I am new and could not comment @amon post, is this practice respected in industry ? I highly doubt that. Lots of shipped embedded products have no code in them.
    – alpha027
    Commented Dec 17, 2022 at 22:01
  • 1
    @alpha027 The compliance with GPL is good practice and many (unfortunately not all) companies are following that. For example my Internet router is a Fritz!Box 7430. It has a UI including a legal page listing the licenses of 3rd party software included in it (unfortunately not a nice SBOM format), but it shows the GPL, LGPL, BSD, MIT, etc licenses and attribution notes. And the download page (at download.avm.de/fritzbox/license.txt ) includes an offer for the delivery source code. Other companies are similar, see for example tp-link.com/us/support/gpl-code . Commented Dec 20, 2022 at 8:17

Here's a concrete example. I'm considering creating a non-upgradable consumer product using an ATtiny85 microcontroller that, in part, uses a GPL2 library to control a string of RGB LEDs. (there is an alternative MIT-licensed library that would also do the job, but let's ignore that). The GPL2 library is of course (being embedded with no OS) statically linked, but is used unmodified.

It's theoretically possible to disassemble the device and use an in-circuit programmer to reflash the MCU.

I believe it would satisfy the letter and the intent of GPL2 to make available a stripped .o or .a file with the compiled proprietary code (no source), a link to the GPL library source on github, and a script to link the two.

  • 5
    definitely not! It would be a clear license violation. If you use a GPL-licensed library, you are required to make source code available of the application using that library. Commented Feb 29, 2020 at 11:57
  • 4
    What you describe would be fine if the libray uses the LGPL license, but not for the GPL license. The GPL license requires that the entire application (i.e. all code running on the device in your case) is made available under the terms of the GPL (or a compatible license). Commented Mar 1, 2020 at 8:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.