LedgerWorks: AGPL, Open Core, or Source-Available
LedgerWorks is a 38-person company behind LedgerLite, an accounting engine used by 5,000 small businesses. The code is Apache-2.0 and the company earns $3.1M a year from support contracts and custom integrations. A competitor, CloudBooks, now offers a hosted LedgerLite service, contributes nothing upstream, and has taken 400 paying customers. The founders debate three options: (a) move to AGPL-3.0 and sell a commercial exception; (b) keep Apache-2.0 and build an enterprise edition with single sign-on and audit reports behind a proprietary license; (c) switch to a source-available license that forbids competing hosted services. LedgerWorks has a signed CLA from all 14 external contributors and owns the copyright on 92% of the code; the remaining 8% came from an Apache-2.0 fork. The board wants a decision in 30 days and worries about community backlash and about losing self-hosted users who chose the product partly because it was permissively licensed.
1. Assess the legal feasibility of each option given copyright ownership, the CLA, and the fork code.
Read the worked answer
Feasibility turns on who owns the copyright:
- (a) AGPL-3.0: possible for future releases. LedgerWorks owns 92% and holds CLAs covering external contributions; the 8% Apache-2.0 fork code can be included because Apache-2.0 is compatible with AGPLv3. Existing Apache-2.0 releases remain Apache-2.0 permanently - that grant is irrevocable, so CloudBooks can keep running what was already published.
- (b) Open core: legally the simplest. The core stays Apache-2.0 and new enterprise modules are proprietary, provided they form a genuine separate work and do not link into copyleft components.
- (c) Source-available (BSL, Elastic License, SSPL): legally available because they own the code, but these are not OSI-approved open source. Distributions may drop the package and the 'open source' claim disappears.
All three are feasible; they differ in what they protect and what they cost.
2. Which option best addresses CloudBooks while preserving revenue and community trust?
Read the worked answer
Neither AGPL nor a permissive license stops CloudBooks by itself. AGPL's network clause requires a host to offer source, but only for the version it runs; a competitor running unmodified LedgerLite pays nothing and competes freely. AGPL mainly deters proprietary forks and closed modifications - it does not turn hosting into a paid activity.
That makes open core the stronger primary answer: keep the Apache-2.0 core for the 5,000 self-hosted users, and move features hosting customers actually pay for - single sign-on, audit reports, multi-tenant controls - into a proprietary enterprise edition. The core stays genuinely useful, so there is little reason to fork, and revenue follows features rather than license restrictions.
A source-available switch is the nuclear option: it might slow CloudBooks, but it breaks the open source promise and invites a fork from the last Apache commit. If used at all, limit it to a new server-side component announced well in advance.
3. What process and communication steps would reduce backlash and keep the decision defensible?
Read the worked answer
Process matters as much as the license. Announce the decision with the rationale (hosted free-riding, support revenue), a dated timeline, and an explicit statement that existing Apache-2.0 releases stay available. Confirm in writing that the CLA covers the relicense and that the 8% fork code has no conflicting terms.
Separate the two promises for the community: the core stays open, and the enterprise edition is additive. Publish a comparison of what remains free and offer a migration path for anyone on the old version.
If trust is fragile, a neutral governance step - a foundation holding the core, or a public roadmap committee with community seats - can do more than a license change. Backlash usually comes from surprise and from the sense that the rules changed after contributions were made, not from the license text alone.