Ferro Analytics: An Appliance Full of Conflicting Licenses
Ferro Analytics sells a fraud-detection appliance to 140 banks. Each appliance is a container stack: Ferro's closed-source scoring service (a Go binary), an unmodified message broker licensed Apache-2.0, a database server licensed AGPL-3.0 that Ferro modified to add bank-specific audit hooks, and a small C helper that Ferro wrote by linking an Apache-2.0 compression library into a GPLv2-licensed command-line tool it found on a public repository. Ferro ships the appliance image to customers, who run it on their own hardware; Ferro also operates the same stack as a hosted service for 30 smaller clients. The legal team asks for a compliance review before the next release, and an engineer suggests 'just put everything under Apache-2.0 and publish the Dockerfile' to settle the question. Ferro has no Contributor License Agreement and has never published source.
1. For each component, state whether a source-disclosure obligation is triggered, and by what.
Read the worked answer
Component by component:
- Scoring service (Go, closed): no source obligation, provided it stays a separate process and does not link GPL or AGPL code. Communicating over a network socket is aggregation, not derivation.
- Message broker (Apache-2.0, unmodified): no source obligation; keep the license and NOTICE files.
- Database (AGPL-3.0, modified): the strongest obligation. Shipping the image is distribution, so source must be offered; running it as a hosted service triggers AGPL section 13, which requires offering the Corresponding Source to network users even without distribution.
- GPLv2 tool linked with an Apache-2.0 library: this combination cannot be distributed at all. Apache-2.0's patent-termination terms are additional restrictions GPLv2 does not permit; the FSF lists Apache-2.0 as incompatible with GPLv2 (it is compatible with GPLv3).
The appliance and the hosted service each trigger different clauses, so the review must cover both delivery modes.
2. The GPLv2/Apache-2.0 helper is the awkward piece. Set out the options in order of cost.
Read the worked answer
The conflict is about distributing a combined work, not about using either piece internally. GPLv2 section 6 forbids distributing a work under terms that add restrictions beyond the GPL; Apache-2.0's patent-retaliation clause is treated as such a restriction. Ferro can keep both pieces in its build, but cannot ship the linked binary.
Options, cheapest first:
- Replace the Apache-2.0 library with an MIT- or BSD-licensed equivalent - usually the smallest change.
- Keep the two as separate executables communicating over a pipe or socket; that is aggregation, and each keeps its own license.
- Check the tool's version: if it is GPLv2-or-later, moving to GPLv3 makes Apache-2.0 compatible, because Apache-2.0 is GPLv3-compatible.
- Ask the tool's copyright holders for an exception.
Relicensing the Apache library is not on the list - Ferro does not own it.
3. Assess the engineer's proposal to publish everything under Apache-2.0 and ship the Dockerfile.
Read the worked answer
It cannot be done unilaterally. Ferro owns its Go service and can license that under Apache-2.0, but it cannot relicense the AGPL database or the GPLv2 tool. Copyright licenses are one-way: AGPL-3.0 and GPLv2 do not permit sublicensing under a permissive license, and attempting it would itself be infringement.
Publishing the Dockerfile also does not discharge the source obligation. AGPL requires the Corresponding Source - the modified database source plus the scripts needed to build and install it - and it must be offered to hosted users, not only to appliance customers.
The right deliverable is a component inventory: license, modification status, delivery mode, and the specific obligation (notice, source offer, or nothing). That inventory, not a blanket license, is what legal should approve.