Gplv3 Licensing Guide For Erpnext Customizations
This whitepaper provides a detailed, client-focused interpretation of licensing implications when commissioning custom software in the Frappe/ERPNext ecosystem.
It is written for founders, delivery owners, legal reviewers, and solution architects who need a practical decision framework that is clause-aware.
Legal note: This document is operational guidance, not legal advice. Final positions should be validated with counsel for your jurisdiction and transaction structure.
Executive Summary
When a client hires an implementation partner for ERPNext/Frappe customization, two systems govern the outcome simultaneously:
- Contract system — ownership, work-for-hire, confidentiality, support rights, reuse rights.
- License system — MIT / GPLv3 / AGPLv3 obligations attached to covered code.
The key operational truth is that these systems are parallel, not interchangeable.
- Contract allocates IP and commercial rights between parties.
- OSS licenses govern recipient rights and distribution obligations for covered code.
- Contract terms cannot validly remove rights that the applicable OSS license grants recipients for covered components.
Decision Tree A — Frappe-Centric Customization Path (MIT)
Decision Tree B — ERPNext-Centric Customization Path (GPLv3)
1) License Topology in this Ecosystem
| Component | License | Practical Baseline |
|---|---|---|
| Frappe Framework | MIT | Permissive model; lower reciprocity constraints |
| ERPNext | GPLv3 | Strong copyleft model for covered distribution contexts |
Frappe CRM (crm) |
AGPLv3 | Network-use copyleft profile |
LMS (lms) |
AGPLv3 | Similar network-use copyleft profile |
Why clients should care
In mixed stacks, obligations follow coupling and distribution behavior—not just repository location.
2) GPLv3 Clause Terms You Should Understand (Exact Terms)
When reading GPLv3, these terms are central:
- “covered work” (from GPLv3 definitions context)
- “propagate”
- “convey”
- “Corresponding Source”
- “aggregate” / separate independent works
Practical importance
- Whether a deliverable is a covered/combined work affects obligations.
- Whether you “convey” to a recipient affects trigger conditions.
- Corresponding Source scope affects what must be made available for covered deliveries.
3) “Arm’s Length” — What is Interpretive vs What is Textual
“Arm’s length” is widely used in compliance conversations but is not itself a named defined term in GPLv3.
For clause-grounded analysis, map discussion to: - GPLv3 §5 (aggregate / separate independent works framing) - GPLv3 §1 (Corresponding Source scope and tight-coupling interpretation context)
Practical reading
- More arm’s-length profile: service/process/API boundary and deployable separability.
- Less arm’s-length profile: in-process extension and inseparable runtime coupling.
4) Source-backed GNU FAQ Signals (High-Value Interpretive Guidance)
The GNU GPL FAQ provides strong interpretive guidance for implementation scenarios.
4.1 Combined program signals (plugins)
GNU FAQ (#GPLPlugins) states that if components establish “intimate communication by sharing complex data structures”, they can be treated as a single combined program.
4.2 Dynamic linking position
GNU FAQ (#GPLStaticVsDynamic) states that static or dynamic linking with a GPL-covered work forms a combined work in GPL interpretation.
4.3 Aggregate concept
GNU FAQ (#MereAggregation) clarifies that separate programs distributed together as an aggregate do not automatically collapse into one license scope, provided recipients can still exercise each component’s license rights.
4.4 Public posting misconception
GNU FAQ (#GPLRequireSourcePostedPublic) clarifies GPL does not force publishing private modifications to the public by default; trigger depends on release/conveyance context.
5) Same-Bench ERPNext Customization: Conservative Client Position
If the custom app: - runs in same Frappe/ERPNext bench/process, - depends on ERPNext internals for core behavior, - deeply hooks into ERPNext doctypes/events/workflows, - and is not practically deployable independently,
then conservative delivery governance should classify it as higher coupling risk and compliance-sensitive under copyleft analysis.
This is not a final legal judgment by itself; it is a prudent client risk-control posture.
6) Distribution Scenarios and Trigger Behavior
Scenario A — Internal-only (no external recipient conveyance)
Distribution obligations are generally not triggered yet.
Scenario B — Selective delivery (one/few clients)
Recipient-facing obligations for covered components can apply.
Scenario C — Public release
Same obligation family applies at broader scale.
Critical clarification
“Private to one client” is still a conveyance event for recipient-facing analysis.
7) Is Public GitHub Publication Mandatory?
Not automatically in every scenario.
What matters first is recipient-facing compliance for covered components.
That said, recipients of covered code can have rights to further redistribution under license terms.
8) Work-for-Hire vs OSS Compliance: Parallel Control Layers
Work-for-hire allocates ownership commercially.
It does not automatically neutralize OSS obligations attached to covered components.
Therefore, your agreement should explicitly include: - ownership map, - source-delivery protocol, - OSS supremacy language, - support/access continuity, - confidentiality boundaries.
9) Edge Case in Depth: Frappe-Only Core + Optional ERPNext Bridge
This should be treated as two compliance states:
State A: Frappe-only core
- runs without ERPNext bridge,
- no ERPNext internal dependency for core execution,
- lower coupling sensitivity.
State B: ERPNext bridge
- optional integration layer uses ERPNext internals/hooks/workflows,
- higher coupling sensitivity for recipient delivery governance.
Recommended architecture
my_app_core(Frappe-path)my_app_erpnext_bridge(ERPNext-path)
This separation improves auditability, legal clarity, and package-level governance.
10) Contract Blueprint (Clause-Ready)
Your MSA/SOW should include explicit sections for:
- Ownership boundaries (client-specific vs pre-existing assets)
- Source-delivery protocol (what, when, format, conditions)
- OSS consistency clause (contract subject to applicable OSS licenses)
- Support/access continuity model
- Confidentiality scope partition
- Escalation trigger for formal licensing review on ambiguous coupling
11) Implementation Governance Model
- Classify each module: Frappe path / ERPNext path / mixed.
- Confirm conveyance model: internal-only / selective / public.
- Align contract language before build freeze.
- Prepare recipient compliance packet where required.
- Run post-delivery patch/release compliance checks.
12) Common Misconceptions (Corrected)
Misconception
“Work-for-hire ownership removes GPL obligations.”
Correction: ownership and license obligations are separate controls.
Misconception
“Selective private delivery means no obligations.”
Correction: recipient-facing obligations may still apply for covered components.
Misconception
“Same bench means all components have same licensing posture.”
Correction: posture depends on coupling and deployability boundaries.
13) Clause → Client Action Matrix (Legal Review Fast-Track)
| Clause / Source | What it governs | Client action at delivery time |
|---|---|---|
| GPLv3 §0 (Definitions) | Scope terms (covered work, propagate, convey) |
Classify each deliverable before handover: covered vs non-covered, conveyed vs internal |
| GPLv3 §1 (Corresponding Source) | What source must be available for covered object-code delivery | Maintain a source map + build/install scripts for covered components |
| GPLv3 §5 (Modified Source + Aggregate) | Whole-work licensing logic + separate aggregate carve-out | Document whether module is independent aggregate or combined extension; avoid ambiguous packaging |
| GPLv3 §6 (Conveying Non-Source Forms) | Permitted source-offer methods for object code | Pick one delivery method (accompanying source, written offer, network access) and record it in release notes |
| GPLv3 §10 (Downstream Licensing) | Automatic recipient rights, no extra restrictions | Remove contradictory clauses (no-redistribute/no-source for covered parts); align MSA language |
| GPLv3 §12 (No Surrender of Others’ Freedom) | If obligations conflict, you may not convey | Run pre-delivery legal check to ensure no contract term conflicts with GPL obligations |
GNU FAQ #GPLPlugins |
Plugin coupling test (intimate communication vs separate process) | For plugin architectures, produce a technical coupling memo before contracting |
GNU FAQ #MereAggregation |
Distinguishes aggregate from combined program | Keep packaging boundaries explicit (separate artifacts/docs) when claiming independence |
GNU FAQ #GPLRequireSourcePostedPublic |
Clarifies no automatic public posting in every case | Use recipient-facing source delivery process even when not publishing publicly |
GNU FAQ #GPLStaticVsDynamic |
FSF interpretation of linking in combined-work analysis | Flag dynamic/static linking cases for legal review in ERPNext-coupled modules |
Minimum audit packet (recommended)
Before each client handover, attach: 1. Module classification sheet (Frappe-path / ERPNext-path / mixed) 2. Covered-component inventory 3. Corresponding Source index 4. License/notice bundle 5. Delivery method declaration (how §6 is satisfied) 6. Contract-compatibility check note
14) Board-Level Readiness Checklist
Before approving delivery:
- [ ] Module classification complete (Frappe vs ERPNext coupling)
- [ ] Conveyance model confirmed
- [ ] Clause-level review complete (definitions/source/conveyance/aggregate/downstream terms)
- [ ] Contract language aligned with OSS obligations
- [ ] Recipient packet requirements defined
- [ ] Support continuity terms signed
Conclusion
The right strategic question is not “contract or GPL?”
It is:
“How do architecture, coupling, conveyance model, and contract terms align with license obligations for this specific customization path?”
Clients that answer this at design stage avoid costly post-delivery disputes and maintain both compliance integrity and commercial predictability.
References (Primary)
- GNU GPL v3 license text: https://www.gnu.org/licenses/gpl-3.0.en.html
- GNU GPL FAQ (master): https://www.gnu.org/licenses/gpl-faq.html
- GNU FAQ — Plugins / combined-program guidance (
#GPLPlugins) - GNU FAQ — Aggregate guidance (
#MereAggregation) - GNU FAQ — Source posting misconception (
#GPLRequireSourcePostedPublic) - GNU FAQ — Static vs dynamic linking position (
#GPLStaticVsDynamic)
