Open source obligations, and what actually triggers them

Every obligation hangs off one word

Read any of the GPL family and the obligations attach to conveying — transferring a copy to someone else. GPLv3 says so explicitly: mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. Internal use inside one organisation is not distribution either. The Free Software Foundation's own FAQ is unambiguous that an organisation may develop a modified version and install it through its own facilities without any obligation to release it.

So the compliance question is not "do we use GPL code". It is "does a copy leave the building". For most engineering teams the honest answer varies by product line, and the boundary runs somewhere unexpected.

Permissive still has obligations, and they are the ones most often missed

MIT, BSD and ISC ask for very little: keep the copyright notice and the licence text with any copy you distribute. That is easy to satisfy and easy to forget entirely, which is why so many mobile apps have no third-party notices screen at all.

Apache 2.0 asks for more, and the extra items are specific. When you redistribute, you must include a copy of the licence, retain the copyright, patent, trademark and attribution notices from the source, state prominently that you changed the files you changed, and — where the original ships a NOTICE file — reproduce its attribution text in your distribution, in the source, the documentation, or a display the software itself produces. You do not have to release your modifications under Apache 2.0.

Weak copyleft: the boundary is the file, or the library

MPL 2.0 draws the line at the file. Covered software means the files carrying the licence notice, together with modifications — which the licence defines as any file resulting from an addition to, deletion from or modification of covered software, or any new file containing covered software. You may create and distribute a larger work under terms of your choice, provided you keep complying with MPL for the covered files. Proprietary code in separate files stays proprietary. Edits inside an MPL file do not.

LGPL draws the line at the library, and the mechanism is relinking. The user must be able to substitute their own build of the library and still run your application.

• Dynamic linking is the clean path. The library loads at runtime as a separate shared object, a user can replace it, and your application source stays closed. You still owe the library's licence text, the library's complete source or a written offer for it, and a prominent notice that you are using it — hiding the fact is not permitted.
• Static linking is where teams get caught. Compile the library into your binary and the user cannot swap it, so you must supply your application in object form — the object files — so they can relink against their own build. Most proprietary vendors will not do that, which makes static linking of LGPL code an accidental decision with a large consequence.
• LGPLv3 adds installation information. The user must be able not only to relink but to install and run the relinked binary on the device. This is the anti-tivoisation requirement, and it is what makes LGPLv3 difficult in locked-down consumer hardware.

Strong copyleft: the boundary is the whole program

GPL requires that when you convey a work based on the covered program, the recipient gets the corresponding source of the whole work under the GPL. The compliance question becomes where your program ends and the GPL program begins, and that is the part with no clean answer.

The Free Software Foundation has a position on where that boundary sits, and it turns on how the two pieces of code actually talk to each other.

AGPL and the network trigger

AGPL v3 is GPLv3 plus section 13. Where you modify the program and let users interact with it remotely over a network, you must prominently offer those users an opportunity to receive the corresponding source of your version, from a network server, at no charge. It exists precisely because hosted software escaped the conveying trigger.

The condition worth reading carefully is that it applies to your modified version. Running an unmodified AGPL program as part of a hosted service — which is most SaaS use of AGPL databases and infrastructure components — does not by itself trigger the source obligation, because there is no modified version to publish. That is a narrower rule than the reputation suggests.

Where this actually bites

• Acquisition and funding diligence. A scanner over the repository is now standard, and findings land as an indemnity, an escrow holdback or a remediation condition before closing. This is the single most common way an open source problem becomes a financial one.
• Enterprise customer questionnaires. Large buyers ask for a component list and licence attestations, and increasingly for a software bill of materials. A team that cannot produce one in a week has a sales problem, not just a compliance problem.
• Shipping a mobile app. The store submission is distribution. Every permissive dependency in that bundle needs its notice, and a copyleft dependency needs an answer before submission, not after.
• On-premise and appliance deals. The moment a hosted product is also sold to run inside a customer's network, the GPL analysis that never applied suddenly does — and it applies to the whole shipped image.
• Publishing your own code. Choosing the licence for your own repositories is the mirror of all this, and the choice determines who can build on it commercially.

A compliance process proportionate to the risk

1. Generate a component inventory automatically from the dependency manifests, on every build. A list maintained by hand is out of date within a sprint.
2. Keep an allow and deny list by licence family, decided once by someone senior. Permissive allowed; weak copyleft allowed with a linking rule; strong copyleft and network copyleft by exception only, with a named approver.
3. Fail the build on a new dependency outside the allow list, rather than reviewing at release. Removing a component in the week of a release is how deadlines are missed.
4. Generate the third-party notices file at build time from the same inventory, and ship it — an about screen, a documentation page, a file in the package.
5. Where you ship copyleft components, keep the corresponding source for each released version, and keep the written offer valid for as long as the licence requires.
6. Re-run the scan before diligence, not during it. The findings are the same either way; the difference is whether you fix them on your own timetable.

The reason to do this while nothing is wrong is that every remedy is cheap early and expensive late. Swapping a copyleft library in week two of a project costs an afternoon. Swapping it during a diligence process costs a re-architecture, under a deadline set by someone else, with the price of the deal moving while you work. The licences themselves are not the risk. Not knowing which ones you have shipped is.