How long must you keep the source for a shipped GPL release?

For a written offer, GPLv2 says valid for at least three years. GPLv3 says at least three years and for as long as you offer spare parts or customer support for that product model. Keep the matching source and build scripts for every shipped release at least that long, and often longer.

What the license text says

These are the two clauses people point to when they set retention.

GPLv2, section 3(b): accompany the program with a written offer, valid for at least three years, to give any third party a complete machine readable copy of the corresponding source code, for a charge no more than your cost of physically performing the distribution.

GPLv3, section 6(b): convey object code in, or embodied in, a physical product with a written offer valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, giving access to the Corresponding Source on a durable medium or from a network server at no charge.

Other options exist. Both licenses let you ship the source alongside the binary instead of making an offer. If you do that, there is no offer to keep valid, though you still need to be able to reproduce the release. This is not legal advice. Check the full text that applies to your components.

Why the clock is easy to miss

A written offer is a promise that runs from the date you distribute. Teams often treat the build artifact as the record and delete old tags, build caches and registries. Three years later a request arrives for the exact source of a firmware version, and nobody can produce it.

Product companies feel this most with devices, desktop installers and on premises appliances, because customers keep running old versions for years. Our post on GPL source offers when shipping binaries covers the offer itself. This post covers the records behind it.

A retention rule you can write down

1. For each shipped release, store a record: version, ship date, components under GPL or LGPL, and which license version applies.
2. Store the exact source commit, a source archive, and the build instructions used for the release. The GPLv3 definition of Corresponding Source includes the scripts that control generating, installing and running the object code, so keep those too.
3. Keep the record for the longest of: three years from last distribution of that version, the end of support for the product model, and your own contract terms.
4. Protect the archive from cleanup jobs. Registry retention rules and storage lifecycle policies are the usual cause of silent loss.
5. Test a restore once a year. Pick an old release and rebuild from the archive.
6. Name an owner for incoming source requests and a response time.

Keep it with your SBOM

The easiest place to keep this is next to the release SBOM, since both describe what shipped. A release folder with the SBOM, the notices file, the source archive hash and the offer text is a compact evidence pack. See the post on what to archive for each software release for a broader list.

Do not equate three years with safe forever. If your support promise to customers is longer, the GPLv3 text points you to the longer period for physical products. Where unsure, keep longer, since storage is cheap compared with a cannot-comply situation.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how a record of what you shipped stays useful after release, because that is the same reason to keep the component list per version.

Safeguard's SBOM and dependency scanning produces a per release component list, and its evidence automation helps keep records together. You can try a free scan at gold.safeguard.sh.

Quick check

Sources

• GNU General Public License v2.0 text, SPDX License List
• GNU General Public License v3.0 text, SPDX License List

Last reviewed: 19 October 2026.