Shipping GPLv3 Software: Prepare The Matching Source-Code Handover

If your business ships a GPLv3-covered program in object-code form, the practical question is not whether you can just post a generic repository link. The real task is to choose the right Section 6 delivery route for the way you convey the software, then prepare the matching Corresponding Source for that exact release. That usually means pinning the buildable source, scripts, notices, and any handover instructions to the same version customers actually receive, whether that delivery happens on hardware, physical media, or a download page.

That process matters because GPLv3 does not apply to every file in your company, and it does not turn network-only use into conveyance. Instead, the obligations depend on whether you are conveying a covered work and, if so, which object-code route you are using. For founders and software teams, the compliance risk often comes from operations gaps: an outdated archive, missing build scripts, or a supplier handoff that never clearly assigned responsibility.

This article is general information only and is not legal advice. It focuses on the US business decision of preparing a reliable GPLv3 source-code handover when you convey object code.

When Do GPLv3 Source Obligations Actually Start?

Start with the threshold question: are you conveying a GPLv3-covered work in object-code form?

Under GPLv3, a covered work is the original program under the license or a work based on it. That does not automatically mean every separate proprietary file, every unrelated internal tool, or every system component in your stack becomes subject to the license. The analysis is about the covered work you are conveying, not your whole codebase by default.

GPLv3 also distinguishes private use from conveyance. You can make, run, and modify covered works that you do not convey without triggering the Section 6 object-code handover routes. If your team runs a modified GPLv3 component internally, that alone is not the same thing as shipping copies to customers.

Just as importantly, mere interaction with users over a computer network, without transfer of a copy, is not conveying under GPLv3. So a network-only service model is not the same as distributing an app installer, firmware image, or downloadable package. That does not mean there are never other intellectual property or open-source issues to check, but it does mean you should not treat every hosted deployment as if Section 6 automatically applies.

A common business mistake is to collapse three different situations into one:

• running GPLv3 software privately inside the business
• letting a vendor modify or host it solely on your behalf under your direction and control
• conveying copies of the covered work to customers, resellers, or other recipients

The third category is where the Section 6 handover routes usually become central. The vendor arrangement is not a blanket exemption: Section 2 has specific conditions, including compliance when conveying material whose copyright you do not control and terms prohibiting copies of your copyrighted material outside the vendor's relationship with you. Check those conditions rather than treating ordinary outsourcing as automatically private use.

What Counts As Corresponding Source For A Release?

Once Section 6 is in play, the next question is what source you actually have to prepare. GPLv3 defines source code as the preferred form of the work for making modifications. For object code, the required package is called the Corresponding Source.

Corresponding Source is broader than a few human-readable files, but narrower than your entire engineering environment. It includes all source code needed to generate, install, and, for an executable work, run the object code and to modify the work. It also includes scripts that control those activities.

In practice, that can include:

• the exact source files for the shipped version
• interface definition files tied to those source files
• source for shared libraries or dynamically linked subprograms the work is specifically designed to require through close data communication or control flow
• build, packaging, and installation scripts needed to generate and install the release
• run scripts or configuration required to execute the covered work in the form you conveyed

It does not mean you must hand over every repository, every internal ticket, or every unrelated deployment tool. GPLv3 expressly excludes certain items from Corresponding Source, including System Libraries, general-purpose tools, and generally available free programs used unmodified to perform those activities, so long as they are not part of the work itself.

It also does not require you to include material users can regenerate automatically from other parts of the Corresponding Source. So if an artifact can be recreated from the source package you provide, the license does not require you to duplicate it just because it existed in your build output.

The safest practical approach is to think in terms of a release bundle, not a moving repository. Prepare the exact source package that matches the distributed binary version, with the scripts and files needed to build and install that version. If your public repository continues to change after release day, recipients should still be able to get the source for the version they actually received.

Which Section 6 Delivery Route Fits Your Distribution Model?

GPLv3 Section 6 gives several different ways to convey object code with the required source access. Choosing the right path matters because the operational steps are different.

Section 6(a): Physical Product With Source On Durable Physical Media

This route works when you convey object code in, or embodied in, a physical product or on physical distribution media and you accompany it with the Corresponding Source fixed on a durable physical medium customarily used for software interchange.

For a small business, this is the most literal handover: ship the device or disc and include the matching source on suitable physical media at the same time. It can be administratively simple, but only if your release packaging process is controlled.

Section 6(b): Physical Product With A Written Offer

This is the familiar written-offer route, but it is not the universal answer for all GPLv3 distributions. It applies to object code conveyed in, or embodied in, a physical product, including physical distribution media.

The written offer must be valid for at least three years and for as long as you offer spare parts or customer support for that product model, if longer. It must allow anyone who possesses the object code to get the Corresponding Source for all software in the product covered by GPLv3, either on durable physical media for no more than your reasonable physical distribution cost or by no-charge access to copy the source from a network server.

That means two practical things. First, the recipient class is broader than your original direct buyer. Second, if you choose a network-server option inside the offer, you still need a dependable source location and internal ownership over availability.

Section 6(c): Occasional And Noncommercial Pass-On Only

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

For most startups and software businesses, Section 6(c) is not a routine commercial workaround. If you are selling devices or software as part of ordinary business operations, do not assume you can rely on pass-through paperwork that was meant for limited occasional noncommercial distribution.

Section 6(d): Equivalent Source Access From The Same Place

This is usually the key route for downloadable software. If you convey object code by offering access from a designated place, whether free or paid, you can satisfy the source requirement by offering equivalent access to the Corresponding Source in the same way through the same place at no further charge.

The source does not have to be on the exact same server. It may be hosted on another server operated by you or a third party, as long as it supports equivalent copying facilities and you maintain clear directions next to the object code telling recipients where to find the Corresponding Source.

The important legal point is that responsibility stays with the conveyer. Even if a supplier, code forge, or storage vendor hosts the source archive, you remain responsible for ensuring the source is actually available for as long as needed to satisfy the GPLv3 requirement. GPLv3 does not set a fixed universal network retention deadline here, so avoid inventing one in your customer materials. Instead, assign operational responsibility and keep the archive available as required.

Section 6(e): Peer-To-Peer With Public No-Charge Source Offering

If you convey object code using peer-to-peer transmission, you may do so if you inform other peers where the object code and Corresponding Source are being offered to the general public at no charge under Section 6(d).

That makes Section 6(e) dependent on a compliant public source offering. It is not a separate excuse to avoid maintaining a reliable source location.

How Should A Download Page Or Source Archive Be Set Up?

For downloadable software, the handover usually succeeds or fails at the release-management level, not in the license text itself. A useful acceptance test is whether a recipient can identify the exact binary they received and obtain the matching Corresponding Source without guesswork.

Your download setup should usually make these points clear:

• the product or package name
• the exact released version or build identifier
• where the matching Corresponding Source can be copied
• that the source is available at no further charge when required under the chosen route
• any simple instructions needed to locate the source archive from the same designated place

The source archive itself should be organized around the exact release, not a rolling branch name that may later change contents. If you use another server for the source, put clear directions next to the object-code offering. Do not bury the handover in a separate legal page that a recipient has to hunt down.

A practical internal checklist for a release manager might include:

• freeze the release tag or commit for the shipped binary
• export the matching source tree
• include required build, install, and run scripts
• check whether any closely required shared-library source belongs in the package
• exclude only what GPLv3 actually excludes, such as System Libraries or unmodified general-purpose tools
• verify the archive can be copied from the designated location stated to recipients
• save a record of what was posted and when

That checklist is not itself a license requirement. It is an operations control that helps you show the release was prepared and made available in a way that matches the route you chose.

What Changes If The Software Is In A User Product?

There is an extra escalation point under GPLv3 when object code is conveyed in, with, or specifically for use in a User Product and the transaction transfers possession and use of that User Product to the recipient in perpetuity or for a fixed term.

In that situation, the Corresponding Source provided under Section 6 must be accompanied by Installation Information. GPLv3 defines that as methods, procedures, authorization 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 does not automatically apply to every business-to-business device. The license defines User Product in a specific way, including consumer products and certain items designed or sold for incorporation into a dwelling, with doubtful cases resolved in favor of coverage. If your software is embedded in hardware that may fit that definition, treat this as a flagged issue for release planning rather than an afterthought.

There is also an important limit. 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, such as where the work is installed in ROM. And the rule does not require ongoing support, warranty, or updates for a recipient's modified version. So you should not promise broad future maintenance rights just because installation information may be required.

What Should You Get From Suppliers Before You Ship?

If any part of the GPLv3-covered stack comes from a vendor, contractor, or upstream development partner, ask for the release handover package before you distribute. Waiting until after launch often exposes that nobody retained the exact build inputs for the version that shipped.

A sensible supplier handover file should cover:

• the released binary version and release date
• the matching Corresponding Source package
• build, install, and run scripts needed for that version
• a note of any excluded System Libraries or unmodified general-purpose tools
• the Section 6 route expected for your distribution model
• where the archive will be hosted or physically included
• which party is responsible for maintaining availability after release
• evidence of what was actually delivered to you

It is also worth aligning your software development agreement or procurement paperwork with those operational needs. The GPLv3 license sets the recipient-facing conditions, but your vendor contract is where you can assign release-packaging tasks, archive retention, and cooperation obligations if a customer asks for source or installation information.

A Realistic Download Handover Example

Suppose a company sells a desktop appliance download that includes a GPLv3-covered component inside the installer. Customers buy the installer from the company portal and receive object code immediately.

The company chooses the Section 6(d) route because the software is conveyed by access from a designated place. On the download page for version 4.2.1, the page identifies the matching Corresponding Source for version 4.2.1 and explains where it can be copied at no further charge. The source archive contains the preferred modifiable source for that release, the build and packaging scripts, install instructions needed to generate the shipped object code, and any interface definition files tied to the work.

The archive does not attempt to include the entire corporate monorepo, unrelated internal analytics tools, or standard operating-system libraries. If the source archive sits on a different hosting service, the download page gives clear directions next to the installer. The company keeps a release record showing the binary hash, source archive name, publication location, and internal owner responsible for availability.

That setup is much closer to GPLv3 compliance than a generic footer note saying source is available on request or a link to the current main branch of a repository that no longer matches the downloaded installer.

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 be broad, including necessary source and scripts, but it is not an automatic requirement to disclose every unrelated project, internal tool, or excluded System Library.

Is A Public Git Repository Enough?

Only if it actually provides the matching Corresponding Source for the conveyed release and fits the Section 6 route you are using. A moving repository that does not preserve the exact shipped version may fall short even if it contains some related code.

Do We Need A Three-Year Written Offer For Downloads?

Not necessarily. The at-least-three-year written-offer rule is part of Section 6(b), which is tied to object code conveyed in or embodied in a physical product or physical distribution media. Downloaded software is often handled under Section 6(d) instead.

Can We Rely On Our Supplier's Hosting?

You may use another server, including one run by a third party, if the source is offered with equivalent copying facilities and clear directions are given next to the object code. But GPLv3 still leaves responsibility with the conveyer to ensure the source remains available as required.

Does SaaS Trigger These Source Handover Rules?

Not by itself under GPLv3. Mere interaction over a network, with no transfer of a copy, is not conveying. The analysis changes when users receive copies of the covered work, such as installers, firmware images, or downloadable packages.

Key Takeaways

• GPLv3 source handover obligations turn on whether you are conveying a covered work in object-code form, not on every internal use or every network interaction.
• Corresponding Source means the source and scripts needed to generate, install, run, and modify the shipped work, with important exclusions such as System Libraries and unmodified general-purpose tools.
• Section 6 offers different delivery routes, and downloadable software commonly fits Section 6(d) rather than the physical-product written-offer model in Section 6(b).
• For release management, prepare the source package for the exact binary version conveyed, keep clear directions next to the object code, and assign responsibility for ongoing availability.
• If hardware or embedded products may qualify as User Products, check whether Installation Information becomes part of the handover.
• Supplier paperwork and release records are not substitutes for GPLv3 terms, but they are valuable controls for proving what source was prepared, where it was stored, and who must maintain it.

If your business needs help scoping an open-source compliance checklist, preparing supplier documentation, organizing a source-code handover process, or aligning software release terms with your distribution model, you can get started through the Sprintlaw platform. For more information, call (888) 449-8437 or email team@sprintlaw.com.