Shipping GPLv3 Software: Prepare The Matching Source-Code Handover

When a business ships software that includes a GPLv3-covered program in object-code form, the practical question is not whether you can simply point to some repository later. The real task is choosing the correct section 6 delivery route and preparing the matching Corresponding Source for that exact release. That usually means checking what you are actually conveying, confirming whether the handover is by download, physical product or peer-to-peer distribution, and making sure the source package includes the code and scripts needed to generate, install, run and modify the covered work.

Just as importantly, GPLv3 does not automatically apply to every file in your company or every system around the product. It applies to the covered work, and the source obligation depends on the route you use when conveying object code. Mere network interaction, without transferring a copy, is not the same thing as conveying. This article is general information only and is not legal advice.

What Are You Actually Obliged To Provide?

Start with the boundaries of the licence obligation. GPLv3 applies to the Program and works based on it, described as a covered work. It does not mean your whole development environment, every private internal tool, or every separate and independent product in your business must be handed over.

That distinction matters because teams often overcorrect in one of two ways. One is assuming a bare link to a public code repository will always do. The other is assuming every connected component, including unrelated proprietary material, must always be disclosed. Neither approach is accurate.

If your team only runs GPLv3 software internally, or a vendor hosts it for you without copies being transferred to end users, the source-code handover rules for conveyed object code may not be triggered in the same way. GPLv3 draws a line between conveying copies and mere interaction over a computer network. Network-only use is not, by itself, conveying.

Where you do convey object code under section 6, you must provide the machine-readable Corresponding Source using one of the permitted routes. So the next decision is not abstract compliance. It is identifying the exact release being shipped and matching it to the source package and delivery method you will rely on.

What Counts As Corresponding Source?

GPLv3 defines source code as the preferred form of the work for making modifications. For object code, the key term is Corresponding Source.

In practical terms, Corresponding Source means all the source code needed to generate the object code, install it, run it if it is an executable work, and modify it. It also includes scripts used to control those activities. For software teams, that usually means more than a folder of application source files.

A proper source handover may need to include:

• the source files for the covered work in the form your developers actually use to modify it
• interface definition files tied to the covered work
• source for shared libraries or dynamically linked subprograms that the covered work is specifically designed to require through close data communication or control flow
• build scripts, packaging scripts, install scripts, and other scripts needed to generate, install or run the shipped object code

There are also important exclusions. Corresponding Source does not include System Libraries. It also does not include general-purpose tools or generally available free programs that are used unmodified in building or installing the work, where those tools are not part of the work itself. And if something can be regenerated automatically from other parts of the Corresponding Source, you do not necessarily need to include that regenerable output as a separate item.

This is why an all-repository dump is not always the right answer. A repository may contain unrelated experiments, internal security material, third-party code outside the covered work, or deployment infrastructure that is not required as Corresponding Source. At the same time, a trimmed archive can fail if it leaves out necessary scripts or closely required source components.

The safest practical test is this: can a recipient, using what you provided, understand, modify, generate, install and run the covered release without needing missing private materials that should have been part of the Corresponding Source?

Which Section 6 Route Fits Your Delivery Model?

GPLv3 allows several different ways to convey object code with Corresponding Source. The route matters because the documentation and operational controls should match it.

6(a): Physical Product With Physical Source

This route is for object code in a physical product or on a physical distribution medium, accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.

This is the most direct physical-product option. If you ship a device, appliance or boxed media and include the matching source on a durable medium with it, your operational burden is clearer because the source accompanies the object code.

6(b): Physical Product With A Written Offer

This route also applies to object code in or embodied in a physical product, but instead of shipping the source with it, you include a written offer. That 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 allow anyone who possesses the object code to obtain the Corresponding Source for the GPLv3-covered software in the product, either:

• on a durable physical medium for no more than your reasonable cost of physically providing it, or
• by access to copy the Corresponding Source from a network server at no charge

This is not a universal shortcut for every software release. It is a qualified route for physical products, and the offer terms need to line up with the licence wording. A generic statement hidden in sales terms is not a substitute for designing the actual fulfilment process.

6(c): Occasional Non-Commercial Pass-On

This option is narrow. It only allows you to convey individual copies of object code with a copy of the written offer, and only occasionally and non-commercially, where you yourself received the object code with such an offer under 6(b).

That makes 6(c) a poor fit for routine commercial distribution. It should not be treated as a standard workaround for product teams or SaaS vendors that also ship local agents, appliances or downloadable binaries.

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

For downloadable software, 6(d) is often the most relevant route. You can offer access to the object code from a designated place, whether free or paid, and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge.

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

The key point is responsibility. Even if another server hosts the source, the party conveying the object code remains responsible for ensuring the source is available for as long as needed to satisfy the licence requirements. GPLv3 does not give a fixed network retention deadline here, so teams should avoid inventing one in customer documents and instead keep operational controls around continued availability.

6(e): Peer-To-Peer Distribution

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

In other words, 6(e) depends on a proper public 6(d) offering behind it. It is not a separate excuse to omit source access.

Download Handover: What Good Looks Like

Take a software business that distributes an installer for a desktop application containing GPLv3-covered components. The installer is made available from the company download page after purchase.

A stronger 6(d) setup would look like this:

• the download page for version 4.2.1 of the installer identifies that matching source is available for that same release
• the source archive is clearly labelled for version 4.2.1 rather than pointing vaguely to a moving development branch
• the source package includes the required source files and scripts needed to generate, install and run that covered release
• if the source is hosted on a separate source server, the download page places clear directions next to the object-code download
• the source is available at no further charge beyond the charge, if any, for accessing the object code

A weaker setup would be a purchase page that says source is available on request, while the actual repository contains only current development code, missing build scripts, or a later version that does not match the shipped binary. GPLv3 is concerned with the Corresponding Source for the conveyed object code, not a general promise that some source exists somewhere.

When Installation Information Becomes A Separate Issue

There is an extra branch to consider for a User Product. GPLv3 defines this term around consumer products and certain things designed or sold for incorporation into a dwelling. Where object code is conveyed under section 6 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, the Corresponding Source must be accompanied by Installation Information.

Installation Information covers 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 the Corresponding Source.

This is not a rule for every business-to-business device. It is a product-classification and transaction-specific question.

It also has a stated 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, for example where the work has been installed in ROM.

Just as importantly, providing Installation Information does not mean you must continue support, warranty or updates for a customer-modified version. The licence says that obligation does not extend that far.

How To Prepare The Supplier Handover Internally

Many GPLv3 issues arise because the release team, procurement team and engineers each hold part of the picture. A practical internal handover should tie those pieces together before shipment.

Useful checkpoints include:

• the exact release or version identifier for the object code being conveyed
• the location of the matching Corresponding Source package for that release
• confirmation of which section 6 route is being used
• the scripts included to build, install and, where relevant, run the covered work
• notes on excluded items, such as System Libraries, general-purpose tools used unmodified, and regenerable outputs
• where another host or supplier provides storage, confirmation that clear directions will appear next to the object code and that availability will be maintained
• whether any product needs a separate User Product and Installation Information review

These are sensible controls rather than magic words. A checklist helps the business organise evidence and handover responsibilities, but it does not replace the licence conditions.

If a supplier contributes the GPLv3 component or hosts the source archive, your commercial documents and Software Development Agreement should support the licence workflow. For example, you may want release-matching obligations, source-archive delivery standards, notice requirements, hosting continuity commitments and cooperation if a product is discontinued. Those are business protections, not substitutes for the licence itself.

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 closely required source and scripts, but it does not automatically require every internal repository, unrelated product or general-purpose tool.

Can We Just Link To Git Hosting?

Sometimes, but only if the setup actually meets the chosen section 6 route. For a 6(d) download model, the recipient needs equivalent access to the matching Corresponding Source through the same place, at no further charge, with clear directions if the source is on another server.

Does SaaS Always Trigger GPLv3 Source Handover?

Not automatically. Mere interaction over a network, without transfer of a copy, is not conveying under GPLv3. The source-code handover question becomes more acute when you convey object code to recipients.

Can We Use A Three-Year Written Offer For Any Software Delivery?

No. The 6(b) written-offer route is framed for object code in or embodied in a physical product or physical distribution medium. It should not be treated as the default answer for ordinary downloadable software.

Does Installation Information Mean We Must Support Customer Modifications?

No. If the Installation Information branch applies, it is about enabling installation and execution of modified versions in the qualifying User Product. It does not create a general obligation to keep providing support, warranty or updates for modified versions.

Key Takeaways

• GPLv3 source obligations attach to the covered work and the way you convey object code, not to every file or system in your business.
• Corresponding Source is the source and scripts needed to generate, install, run and modify the covered release, subject to specific exclusions such as System Libraries and certain unmodified general-purpose tools.
• Choose the right section 6 route: physical source under 6(a), qualified written offer for physical products under 6(b), the narrow pass-on rule in 6(c), equivalent download access under 6(d), or peer-to-peer with a compliant public source offer under 6(e).
• For downloadable software, make the source package match the exact shipped version and keep clear directions next to the object-code download if the source is hosted elsewhere.
• Review whether any User Product transaction triggers Installation Information, and build supplier and release controls that support the licence workflow.

If your business is shipping software with GPLv3 components, Sprintlaw's legal team can help with open source compliance reviews, software supply terms, supplier handover clauses and release-process documentation. Call 0800 002 184 or email team@sprintlaw.co.nz.