Publishing an Internal Stress-Testing Library Under Apache-2.0
Northbridge Bank's model risk team has spent 18 months building a Python stress-testing library: 42,000 lines, 14 internal contributors, and three contractors supplied by a staffing agency who wrote roughly 30% of the code. The business wants to publish it on public GitHub through the bank's open source program office, with a press announcement in six weeks, under Apache-2.0. A legal scan returned four findings. First, a 900-line module was adapted from a GPL-3.0 project. Second, the test harness depends on a charting package released under the Elastic License 2.0. Third, no file carries a license header or SPDX identifier. Fourth, the contractors' engagement terms are silent on copyright assignment. The engineering lead argues the GPL module is "only a small part" and proposes publishing now and cleaning up later. The program office has one lawyer, two reviewers, and no authority to delay the announcement.
1. Rank the four findings by the risk they pose to a public Apache-2.0 release, and state what must happen to each before publication.
Read the worked answer
1. GPL-3.0 module (highest). GPL-3.0 and Apache-2.0 are incompatible: you cannot distribute GPL code inside an Apache-2.0 work. "Only 900 lines" is not a licence defence - de minimis is a doctrine about statutory exceptions, not a permission you can rely on in a compliance review. Three options exist: remove the module and clean-room re-implement it from the specification by someone who has not read the GPL source; obtain permission from every copyright holder of that module (rarely practical); or license the whole project GPL-3.0 (almost certainly unacceptable to the bank and to downstream consumers). Removing and rewriting is the realistic path.
2. Contractor contributions (high). The bank cannot grant Apache-2.0 rights over code it does not own. The agency contract must be amended with an IP assignment or a corporate CLA covering past contributions, or those commits must be rewritten by employees. Silence in the contract means the bank has a licence at best, not ownership.
3. Elastic License 2.0 test dependency (medium). ELv2 is source-available, not OSI-approved. A dev/test-only dependency that is never redistributed is lower risk, but scanners and downstream consumers will flag it, and the README claim "open source" becomes contestable. Prefer replacing it with a permissively licensed charting library.
4. Missing headers (low legal risk, high process cost). Add LICENSE, NOTICE and SPDX identifiers per file with a scripted pass; this is mechanical and can run in parallel with everything else.
2. The engineering lead proposes "publish now, clean up later". Give your recommendation and the criteria you would use to decide.
Read the worked answer
Recommendation: do not publish until findings 1 and 2 are closed. Publishing is a licence grant, not a draft. Once the repository is public under Apache-2.0, every clone, fork and vendored copy carries a grant the bank cannot retract. Deleting the GPL module in week seven does not undo the grant already made over the week-six snapshot; it converts a fixable internal issue into a public compliance incident affecting anyone who relied on the Apache-2.0 terms, and it is exactly the kind of thing a due-diligence questionnaire surfaces years later.
Criteria I would apply:
- Can the offending module be excised inside the window? If a clean-room rewrite takes four weeks, the six-week date survives; if it takes twelve, the date does not.
- Is the announcement date a business constraint or a habit? Announcements can be decoupled from technical release, or scoped: announce the project, the governance and the roadmap, and state the source will be published when IP review closes. That is credible and reversible.
- Is contractor IP paperable in days? An agency amendment is often a two-week legal task; a refusal is a rewrite task.
- Can findings 3 and 4 run in parallel? Yes - dependency replacement and header tooling are independent of the publication decision.
A gated release with a written exit criterion for each finding gives the business a date and gives legal a defensible position. "Clean up later" gives neither.
3. The bank's legal team asks why Apache-2.0 rather than MIT, given that the bank holds patents in this area. How do you frame the trade-off?
Read the worked answer
The choice is not cosmetic, because Apache-2.0 contains a patent clause and MIT does not.
Apache-2.0, section 3 grants every downstream user a royalty-free patent licence covering the contributors' patents that are necessarily infringed by their contributions, and it terminates that grant for any party that initiates patent litigation alleging the software infringes. For the bank this cuts both ways:
- Cost: the bank gives up the ability to assert its own patents against users of this library, and against anyone who builds on it.
- Benefit: it removes the fear that stops regulated firms and vendors from adopting bank-published code, and it gives the bank the same protection against a contributor who later sues.
MIT/BSD-3-Clause are shorter, are compatible with almost everything, and are silent on patents - which in practice means downstream counsel must assume patent risk and may decline adoption. BSD-3 adds a non-endorsement clause; Apache-2.0 adds a trademark non-grant and a NOTICE retention obligation, which suits a bank that cares about its name not being used on a modified fork.
Frame it as a decision legal must make consciously: if the bank intends to enforce patents in this domain, publishing under Apache-2.0 is a strategic concession and MIT is marginally less exposed (though still arguably an implied licence). If the goal is broad adoption and foundation hosting, Apache-2.0 is the ecosystem default and the only choice most foundations will accept without discussion. Either way, write the rationale into the approval record so the next reviewer does not reopen it.