Shipping GPLv3 Software: Prepare The Matching Source-Code Handover

When a business ships GPLv3-covered software in object-code form, the practical compliance question is usually not whether source code matters, but how it will be provided for that exact release. The licence does not automatically apply to every file in your company, and it does not treat network-only use as the same as handing over copies. Instead, the main job is to identify the covered work, work out whether you are conveying copies, decide which section 6 delivery route fits your product, and prepare the corresponding source so it actually matches what customers received.

For most downloadable software, the working answer is section 6(d): recipients who can download the object code should be able to get equivalent access to the corresponding source at no further charge, with clear directions if the source is hosted elsewhere. Physical products can use different paths, including accompanying source media or a qualifying written offer, but those routes have conditions and are not interchangeable shortcuts.

This article is general information only and is not legal advice.

When Do GPLv3 Source Obligations Actually Arise?

GPLv3 applies to a covered work, meaning the GPLv3 program itself or a work based on it. That is narrower than saying every repository, plug-in, internal tool or unrelated product in the business becomes subject to the same obligations.

The trigger for section 6 is conveying object code. Under GPLv3, conveying means a form of propagation that lets another party make or receive copies. By contrast, mere interaction with a user through a computer network, without transfer of a copy, is not conveying.

That distinction matters in day-to-day product decisions:

• If your team modifies a GPLv3 program and runs it only on your own systems, section 6 object-code handover may never be engaged because you are not conveying copies.
• If you provide a customer with an installer, firmware image, downloadable binary, appliance, USB media or other copy they can receive, you are in section 6 territory for the covered work being conveyed.
• If you distribute a larger package that includes separate and independent works alongside a GPLv3-covered component, the licence does not automatically spread to every separate item merely because they sit on the same medium as an aggregate.

That is why the first compliance step is scoping the covered work and the conveyance route, not making a broad promise that your whole company source tree will be published.

What Counts As Corresponding Source For The Release You Shipped?

GPLv3 defines source code as the preferred form of the work for making modifications. For object code, the key term is corresponding source under GPLv3. This is not just a courtesy copy of whatever happens to be in a public repository. It needs to be the source code required to generate, install and, for executable works, run the object code, and to modify the work.

It also includes scripts that control those activities. In practice, that often means build scripts, packaging scripts, interface definition files, configuration needed to reproduce the shipped build, and source for shared libraries or dynamically linked subprograms that the work is specifically designed to require through close communication or control flow.

Just as important are the exclusions. Corresponding source does not automatically mean every development asset or every upstream dependency. GPLv3 excludes:

• System Libraries
• general-purpose tools used unmodified in performing those activities
• generally available free programs used unmodified and not part of the work
• material users can regenerate automatically from other parts of the corresponding source

So the boundary is functional and release-specific.

Ask: what would a recipient need to generate, install, run and modify the covered work you actually conveyed? That question usually produces a tighter and more accurate package than either extreme of publishing too little or dumping an unrelated monorepo.

A useful internal test is whether an engineer who did not build the release the first time could understand how the shipped object code was produced and could modify the covered work using what you provided, without being blocked by missing scripts or hidden required components that are really part of the work.

Which Section 6 Route Fits Your Product?

GPLv3 section 6 gives several ways to convey object code lawfully, but each route has its own conditions. Choosing the right one depends on how your business supplies the software.

Section 6(a): Physical Product Accompanied By Physical Source

This path is straightforward for physical distribution. You provide the object code in, or embodied in, a physical product or distribution medium, accompanied by the corresponding source fixed on a durable physical medium customarily used for software interchange.

It can suit appliances, embedded devices or media shipments where you want the source handover to be complete at the time of supply.

Section 6(b): Physical Product Plus Written Offer

This is the familiar written-offer route, but it is narrower than many businesses assume. It applies where the object code is in, or embodied in, a physical product or physical distribution medium. The written offer must be valid for at least three years and also for as long as you offer spare parts or customer support for that product model.

The offer must be available to anyone who possesses the object code, not only your direct customer. It must give them either:

• a copy of the corresponding source on a durable physical medium for no more than your reasonable cost of physically performing that source delivery, or
• access to copy the corresponding source from a network server at no charge

This is not the default answer for downloadable software, and it should not be treated as a universal three-year promise that replaces the other section 6 routes.

Section 6(c): Occasional Noncommercial Pass-On

This route is very limited. It allows individual copies of the object code to be conveyed with a copy of the written offer, but only occasionally and noncommercially, and only if you received the object code with such an offer under section 6(b).

For a commercial software business, this is usually not a routine compliance strategy. It is a qualified pass-on rule, not a convenient workaround for regular product distribution.

Section 6(d): Equivalent Source Access For Downloads

For downloadable binaries, this is usually the most practical route. If you offer object code from a designated place, whether free or paid, you can offer equivalent access to the corresponding source in the same way through the same place at no further charge.

You do not need to force recipients to download the source at the same time as the object code. The source can be hosted on another server operated by you or a third party, as long as that server supports equivalent copying facilities and you maintain clear directions next to the object code telling recipients where to find the corresponding source.

The critical point is responsibility. Even if another server hosts the source archive, the party conveying the object code remains responsible for ensuring the corresponding source is available for as long as needed to satisfy the licence requirements. GPLv3 does not set a single fixed network retention deadline here, so the safer business practice is to align your retention and release-management processes with the period during which recipients may reasonably need the exact matching source for that conveyed version.

Section 6(e): Peer-To-Peer Distribution

If object code is conveyed by peer-to-peer transmission, this route can be used if you tell other peers where the object code and corresponding source are being offered to the general public at no charge under section 6(d).

That means section 6(e) relies on a compliant public offer under section 6(d). It is not a separate excuse to skip the source-hosting arrangements.

How Do You Set Up A Download Page That Actually Works?

A compliant download workflow is usually more about operational discipline than long legal wording. If you are shipping a desktop app, firmware image or other binary online, the source package should match that release and be easy to locate from the same distribution context.

A practical acceptance test for a download page is:

• the object-code version and the source package clearly refer to the same release or build
• the source archive includes the code and scripts needed to generate, install, run and modify the covered work, subject to the GPLv3 exclusions
• recipients can copy the source at no further charge
• if the source is on another server, the directions sit next to the object code and are clear enough that an ordinary recipient can find the exact source package without guesswork
• someone in your business is responsible for keeping the source location live and aligned with release management

Consider a realistic example. A software company posts version 4.2.1 of a GPLv3-covered command-line tool as a compiled download in its customer portal. The portal page should either make the matching source archive available there as well, or display clear directions right next to the binary download for obtaining the corresponding source from another server at no further charge. The archive should relate to version 4.2.1, not to an older branch, a development snapshot, or a general repository that no longer reproduces what was shipped.

What usually causes trouble is a mismatch between engineering practice and release promises: a rolling repository, missing build scripts, renamed branches, or outsourced build steps that are necessary in reality but not documented in the handover pack.

When Does Installation Information Become Relevant?

There is an extra branch in section 6 for a User Product. Broadly, this covers a consumer product and certain items designed or sold for incorporation into a dwelling. If you convey object code in, with, or specifically for use in a User Product, and the transaction transfers possession and use of that product to the recipient in perpetuity or for a fixed term, the corresponding source under section 6 must be accompanied by installation information.

Installation information means the methods, procedures, authorisation keys or other information required to install and execute modified versions of the covered work in that User Product from a modified version of its corresponding source.

This is a point for escalation, not a rule to apply mechanically to every business device or every B2B hardware supply. The licence also states an important exception: the installation-information requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product, for example where the work is installed in ROM.

It also does not require you to keep providing support, warranty or updates for modifications made or installed by the recipient. So the right question is not "do we support customer modifications forever?" but "does this product fall into the User Product branch, and if so, what information is actually required to permit installation and execution of modified versions?"

What Should You Collect From Suppliers And Development Teams?

Licence compliance often fails because the business shipping the binaries does not control the source handover inputs. If contractors, upstream vendors or internal teams contribute to the release, you need a repeatable handover process.

For each GPLv3-covered release, collect and record:

• the exact released version, build number or commit range that matches the conveyed object code
• the scoped description of the covered work, including what is included and what is treated as separate or excluded
• the corresponding source package for that release
• build, installation and run scripts needed for the covered work
• any interface definition files or required linked components that fall within corresponding source
• the chosen section 6 route for that product or channel
• where recipients obtain the source, including any third-party hosting arrangement used for section 6(d)
• who is responsible internally for maintaining availability and updating the source package when a new object-code release goes out
• evidence of what was displayed or provided to recipients at the time of conveyance, such as a download-page capture, product insert or release checklist

These records are good operational controls, but they are not all separate licence mandates. GPLv3 tells you the conditions for conveying object code. Your internal checklists, supplier clauses and release approvals are how you make those conditions happen consistently.

Useful Software Development Agreement terms often deal with version matching, build reproducibility, prompt delivery of source materials and scripts, and responsibility for maintaining a source archive during the relevant product lifecycle. Those terms help reduce gaps, but they do not replace the licence obligations owed to recipients.

Frequently Asked Questions

Do We Have To Publish Our Entire Repository?

No. GPLv3 focuses on the corresponding source for the covered work in object-code form. That can include more than raw source files, such as scripts and closely required linked components, but it is not an automatic requirement to publish every unrelated internal project or asset.

Can We Just Link To An Upstream Project Page?

Not safely, unless that source genuinely matches the object code you conveyed and the arrangement satisfies the route you are using. If you ship a modified or release-specific binary, a generic upstream page may not provide the exact corresponding source for your version.

Is A Private SaaS Deployment The Same As Conveying?

Not by itself. GPLv3 says mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. The analysis changes if customers receive copies, installers, firmware or other object-code distributions.

Can We Use The Written Offer Model For Any Download?

Section 6(b) is framed around object code in or embodied in a physical product or physical distribution medium. For ordinary downloadable distribution, section 6(d) is usually the more natural route.

Do We Need To Keep The Source On The Same Server As The Binary?

No. Under section 6(d), the source may be hosted on another server operated by you or a third party if it supports equivalent copying facilities and you provide clear directions next to the object code. Even then, you remain responsible for availability.

Key Takeaways

• GPLv3 source obligations attach to a covered work and depend on whether you are conveying copies, not merely operating software over a network.
• Corresponding source must match the object-code release and include the source and scripts needed to generate, install, run and modify the covered work, subject to stated exclusions.
• Section 6 offers different object-code delivery routes, and downloadable software usually fits section 6(d) rather than the physical-product written-offer model in section 6(b).
• A source archive, download page and supplier handover process should be aligned so recipients can actually obtain the exact matching source for the version they received.
• User Product installation information is a separate escalation point with qualifications and exceptions, not a universal rule for every device deployment.

If your business is shipping software and needs help with open source compliance reviews, supplier development terms, release documentation or IP risk in commercial software deals, Sprintlaw can help. Call 1800 730 617 or email team@sprintlaw.com.au.