Shipping GPLv3 Software: Prepare The Matching Source-Code Handover

When a business ships software covered by GPLv3 in object-code form, the practical question is not simply whether source code must be available somewhere. The real task is to choose the correct section 6 delivery route for that specific release, assemble the matching corresponding source, and make sure the handover method actually fits how the software is being conveyed. A download page, device shipment or partner handover can each point to a different compliance approach.

That starts with two boundaries. First, GPLv3 applies to the covered work, not every file, repository or internal tool your company owns. Second, source-code obligations are tied to conveyance of object code under the licence terms. Running software privately, or allowing users to interact with it over a network without transferring a copy, is not the same thing as conveying it.

For founders and software teams, the safest approach is to prepare the source package for the exact released build before shipment, document who is responsible for hosting or supplying it, and avoid casual promises such as "the repo is online somewhere". This article is general information only and is not legal advice.

When Do GPLv3 Source Obligations Actually Arise?

GPLv3 uses the defined term "covered work". That means the original GPLv3 program, or a work based on it. It does not automatically sweep in every unrelated asset in your business just because your product includes some GPLv3-covered code.

The licence also distinguishes between using software internally and conveying copies to others. If your team modifies and runs a covered work only inside the business, GPLv3 does not impose section 6 object-code handover steps purely because of that internal use.

Equally, mere interaction with users through a computer network, without transfer of a copy, is not conveying under GPLv3. So a network-only service is not the same thing as shipping an installer, appliance image, mobile app package or downloadable binary.

That distinction matters because many compliance problems start with the wrong trigger question. The issue is usually not "do we use GPL code anywhere?" but "are we conveying object code of a covered work, and if so, by which route?"

It is also worth separating a covered work from a wider aggregate. GPLv3 recognises that a covered work can sit alongside separate and independent works without automatically making the licence apply to those other parts. That does not answer every integration question, but it does mean you should map the relevant GPLv3-covered component precisely rather than assume the whole company repository must always be handed over.

What Counts As Corresponding Source?

For GPLv3, source code means the preferred form of the work for making modifications. When you convey object code, the key package is the "Corresponding Source". That is broader than a few main source files and narrower than your entire engineering environment.

Corresponding Source 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 to control those activities.

In practice, that usually means you should think about the exact release bundle, not just the development repository. A proper handover may need:

• the source files for the GPLv3-covered program or modified version;
• build scripts, packaging scripts and configuration needed to generate the shipped object code;
• installation scripts or procedures needed to install that version;
• interface definition files tied to the work; and
• source for shared libraries or dynamically linked subprograms that the work is specifically designed to require through close data communication or control flow.

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, used unmodified in performing those activities if they are not part of the work. And it need not include material that users can regenerate automatically from other parts of the Corresponding Source.

So the right question is not "must we disclose every repository and every tool?" The better question is "what source and scripts are actually needed to generate, install, run and modify the conveyed covered work?"

This is why a generic link to a public code hosting profile can be risky. If the repository is missing release tags, build instructions, required scripts or the exact files matching the shipped binary, it may not meet the practical standard the licence expects.

Choosing The Right Section 6 Delivery Route

GPLv3 section 6 gives several ways to convey object code while also making the Corresponding Source available. They are alternatives, but they are not interchangeable. The correct route depends on how you distribute the object code.

6(a): Physical Product With Source On A Durable Physical Medium

This route is straightforward for physical shipments. The object code is conveyed in, or embodied in, a physical product or physical distribution medium, and the Corresponding Source accompanies it on a durable physical medium customarily used for software interchange.

This is a direct handover model. It suits businesses that want the source package physically supplied with the product rather than hosted separately.

6(b): Physical Product With A Written Offer

This is the route many people remember, but it is not the universal rule for every GPLv3 distribution. It applies where object code is conveyed in, or embodied in, a physical product or physical distribution medium, and the shipment is accompanied by a written offer.

That 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. It must allow anyone who possesses the object code to obtain the Corresponding Source for the covered software in that product, either on a durable physical medium for no more than your reasonable cost of physically performing that conveyance, or by access to copy it from a network server at no charge.

This is narrower and more technical than a casual statement such as "source available on request". If you rely on 6(b), the offer wording, scope and fulfilment process matter.

6(c): Occasional And Noncommercial Pass-On

This is not a normal commercial workaround. It is only available occasionally and noncommercially, and only where you received the object code with a compliant 6(b) written offer and pass on individual copies with that offer.

Most startups selling products or distributing commercial software should not treat 6(c) as a routine compliance path.

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

For downloadable software, this is often 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 have to force users to download the source at the same time as the binary. But the access must be equivalent, and the directions to the source should be clear next to the object code.

The licence also allows the Corresponding Source to be hosted on another server, operated by you or a third party, so long as that server supports equivalent copying facilities and you maintain clear directions next to the object code explaining where the Corresponding Source can be found. The responsibility still remains with the business conveying the object code. Outsourcing hosting does not outsource the obligation.

6(e): Peer-To-Peer Distribution

If you distribute object code using peer-to-peer transmission, you can use this route provided you tell other peers where the object code and Corresponding Source are being offered to the general public at no charge under 6(d).

That means 6(e) depends on a compliant public 6(d) source offering sitting behind it.

What A Good Download Handover Looks Like

Take a simple example. A software business offers a downloadable appliance image from its customer portal. The image contains a GPLv3-covered component that the team has modified. The portal should not merely provide the binary and a vague open source notice.

A stronger 6(d) setup would usually include:

• the exact release name or version of the downloadable object code;
• a source archive that matches that release, rather than the latest development branch;
• build and install scripts needed for that release;
• clear instructions on the same download page telling recipients where to copy the Corresponding Source; and
• no extra charge for that source access.

If the source archive is hosted on a separate file server, the download page for the object code should clearly direct users there. The business conveying the image should still monitor that the source remains available for as long as needed to satisfy the licence requirements. The licence does not set a fixed general network retention period for 6(d), so do not assume a standard three-year rule applies to all downloadable distributions.

The aim is a matching handover. If a customer downloads version 4.2.1, they should be able to find the Corresponding Source for version 4.2.1, not an unrelated repository snapshot from six months later.

When Installation Information Becomes Part Of The Job

There is an extra branch under section 6 for certain User Products. This does not apply to every B2B device or every hardware sale, so it should be treated as a specific escalation point rather than a universal assumption.

Where object code is conveyed in, with, or specifically for use in a User Product, and the transfer gives the recipient possession and use of that User Product in perpetuity or for a fixed term, the Corresponding Source under section 6 must be accompanied by the required Installation Information.

GPLv3 defines a User Product to include a consumer product normally used for personal, family or household purposes, and anything designed or sold for incorporation into a dwelling. Doubtful cases are resolved in favour of coverage. The classification does not turn only on whether this particular buyer is a business, so check the product definition before relying on a B2B label.

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.

There is also an important exception. This 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.

Even where Installation Information is required, the licence does not force you to keep providing support services, warranty or updates for recipient-made modifications. So the question is about enabling installation of modified versions where the licence requires it, not guaranteeing ongoing support for altered systems.

Supplier Handover Controls Worth Setting Up

If a supplier, contractor or acquired development team touched the GPLv3-covered component, your release process should gather enough evidence to support the chosen section 6 route. These are practical controls rather than magic words, but they make compliance much easier.

• Identify the covered work and the exact object-code release being conveyed.
• Record the release version, build date and packaging details.
• Store the matching Corresponding Source for that release, not just rolling repository access.
• Capture build, installation and packaging scripts needed to generate or install the release.
• Note any source elements excluded because they are System Libraries, unmodified general-purpose tools or automatically regenerable material.
• Choose the intended section 6 route for each distribution method: physical media, written offer, download access or peer-to-peer.
• Record where the source is hosted or physically stored, who maintains it and who checks availability.
• Require suppliers to hand over enough material for your business to satisfy the chosen route, rather than assuming their own repository practices will be enough.

These records are not themselves a substitute for the licence conditions. They are evidence and operational discipline. The licence tells you what must be conveyed; your open source software policies and internal checklist help you do it consistently.

A Software Development Agreement can also help by requiring version tagging, release archive delivery and cooperation on open-source notices. But contract wording does not override GPLv3 itself. Allocating responsibility in a contract does not, by itself, satisfy section 6 when the required source handover is missing or incomplete.

Frequently Asked Questions

Do We Have To Publish Our Entire Company Repository?

Not necessarily. The focus is the Corresponding Source for the covered work in object-code form that you are conveying. That may include more than a narrow code subset, especially where scripts and tightly required components are involved, but GPLv3 does not say every unrelated company file must be disclosed.

Is A Public Git Repository Always Enough?

No. A repository may still fall short if it does not match the shipped release, lacks required scripts, or does not clearly connect to the conveyed object code. Availability, release matching and completeness matter.

Does SaaS Automatically Trigger GPLv3 Source Delivery?

No. Mere interaction with users over a computer network, without transfer of a copy, is not conveying under GPLv3. A separate analysis may still be needed if copies are actually delivered in some other way.

Can We Use A Written Offer For Downloadable Software Instead Of Hosting Source?

The familiar written offer route in 6(b) is tied to object code conveyed in, or embodied in, a physical product or physical distribution medium. For ordinary downloadable distribution, 6(d) is usually the more relevant route.

Can Another Provider Host The Source For Us?

Yes, the Corresponding Source can be hosted on another server if it supports equivalent copying facilities and you give clear directions next to the object code explaining where to find it. But the business conveying the object code remains responsible for ensuring availability.

Key Takeaways

• GPLv3 source obligations attach to conveying object code of a covered work, not to every internal use case or every file your business owns.
• Network-only interaction without transfer of a copy is not conveying under GPLv3.
• Corresponding Source means the source and scripts needed to generate, install, run and modify the conveyed work, subject to specific exclusions such as System Libraries and certain unmodified general-purpose tools.
• Section 6 offers different delivery routes, and downloadable software will often rely on 6(d) rather than a universal three-year written offer.
• A compliant handover should match the exact released binary, include clear source directions, and assign responsibility for hosting or fulfilment.
• User Product installation information is a separate issue that only arises in the qualified circumstances set out by GPLv3.
• Supplier records and release controls are practical safeguards, but they do not replace the licence conditions themselves.

If your business is shipping software with GPLv3 components, our legal team can help you review open-source licence obligations, prepare supplier and contractor handover terms, assess release documentation, and tidy up software licensing risks before launch. You can reach Sprintlaw on 08081347754 or at team@sprintlaw.co.uk.