letsbe
/
LetsBeBiz-Redesign
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
LetsBeBiz-Redesign/docs/legal/LetsBe_Biz_Open_Source_Comp...

18 KiB
Raw Permalink Blame History

LetsBe Biz — Open Source & Legal Compliance Check

Date: February 26, 2026 Prepared by: Claude (AI-assisted analysis) Status: REQUIRES LEGAL COUNSEL REVIEW Scope: Open source license compliance for managed service model, website/sales pitch accuracy, ToS/Privacy Policy gaps

Disclaimer: This is an AI-assisted compliance analysis, not legal advice. All findings should be reviewed by qualified legal counsel before acting on them. Open source licensing has limited case law and reasonable attorneys may disagree on interpretations.

Executive Summary

Overall Assessment: PROCEED WITH CONDITIONS

LetsBe's open source licensing posture is strong — you've already done the hard work of identifying and removing tools with incompatible licenses (n8n, Windmill, Typebot, Invoice Ninja, Akaunting, Twenty, Outline, Poste.io). The remaining tool stack is composed of genuinely open-source licenses (AGPL-3.0, MIT, Apache-2.0, GPL-2.0, LGPL-3.0, MPL-2.0, BSD-2-Clause, Zlib) that permit commercial hosting.

However, there are 7 action items across three categories that need attention before launch:

Priority Category Count
Critical (fix before launch) License compliance gaps 3
Important (fix before launch) Website/sales copy inaccuracies 2
Recommended (fix soon after) Legal document gaps 2

1. Open Source License Audit — Current 28-Tool Stack

1.1 License Inventory

License Tools Commercial Hosting Allowed Key Obligations
AGPL-3.0 (11 tools) Stalwart Mail, Listmonk, Nextcloud, MinIO, Documenso, Vaultwarden, NocoDB, Cal.com, Plane (expansion) ✅ Yes Source code disclosure if modified; network copyleft
MIT (8 tools) Chatwoot, Activepieces, Gitea, Umami, GlitchTip, Uptime Kuma, Diun, LibreChat, Ghost, Squidex, BookStack (expansion) ✅ Yes Include license/copyright notice
Apache-2.0 (2 tools) Keycloak, Drone CI ✅ Yes Include license/copyright; note changes; patent grant
GPL-2.0 (1 tool) WordPress ✅ Yes Source code disclosure if modified and distributed
LGPL-3.0 (1 tool) Odoo (Community Edition) ✅ Yes Source code of LGPL portions if modified
MPL-2.0 (1 tool) Penpot ✅ Yes Source code of MPL files if modified
BSD-2-Clause (1 tool) Redash ✅ Yes Include license/copyright notice
Zlib (1 tool) Portainer CE ✅ Yes Cannot misrepresent origin
Proprietary (2 tools) Orchestrator, SysAdmin Agent N/A Your own code

Verdict: All 28 tools in the current stack have licenses compatible with your managed service model. No tool prohibits commercial hosting, managed service provision, or deployment on customer servers.

1.2 AGPL-3.0 — Your Primary Compliance Obligation

11 of your 28 tools use AGPL-3.0. This is the most important license to get right.

What AGPL-3.0 requires:

The AGPL's "network copyleft" provision (Section 13) requires that if you modify AGPL software and make it available to users over a network, you must provide the corresponding source code. Two conditions must BOTH be met:

  1. You've modified the program (configuration changes are generally not considered modifications)
  2. You make the modified program available over a network

Your current posture is good:

  • You deploy unmodified upstream Docker images (stated in ToS §2.3 and §7.2)
  • You do not create derivative works of the open-source tools
  • Each tool runs on the customer's dedicated server (not LetsBe's infrastructure)

However, there are two risk areas:

🔴 CRITICAL ACTION ITEM #1: AGPL Source Code Access Mechanism

The issue: Even when deploying unmodified AGPL software, best practice (and some legal interpretations) require that you provide users with a way to access the corresponding source code. Several AGPL tools (Nextcloud, Cal.com, Stalwart Mail, etc.) include an "about" page or source code link in their UI, but not all do.

Your ToS §7.2 says: "You are the licensee — each tool runs under its upstream open-source license on your dedicated server."

What's missing: A practical mechanism for customers to access source code for all AGPL tools. While customers have SSH access to their VPS (and can inspect Docker images), this may not satisfy the AGPL's requirement that source code be "available" through the same network interface.

Recommendation:

  1. Add a page in the Hub or on each customer VPS that links to the upstream source repository for every deployed tool, along with the exact Docker image tag/version deployed
  2. Add a statement to the Open-Source Tools page on your website: "Source code for all tools is available from the upstream projects linked above. We deploy unmodified releases. The exact versions deployed on your server are listed in your dashboard."
  3. If you ever contribute patches upstream or make any modifications (even configuration patches baked into Docker images), you must make those available under the same AGPL license

Effort: Low (a few hours of development + copy updates)

🔴 CRITICAL ACTION ITEM #2: n8n Listed on Website But Removed from Stack

The issue: Your website copy (Open-Source Tools page, Page 6) still lists n8n under Automation alongside Activepieces:

| n8n | Advanced workflow automation | Sustainable Use License | n8n.io |

This is a significant problem for two reasons:

  1. n8n's Sustainable Use License explicitly prohibits hosting n8n as part of a paid service. Listing it implies you deploy it on customer servers as part of the managed service
  2. Your Tool Catalog v2.2 explicitly marks n8n as REMOVED with the note: "Sustainable Use License prohibits hosting as part of a paid service"
  3. Your objection handling guide (§4.2) also references n8n as "included in LetsBe" — this needs to be corrected

Additionally: Your Foundation Document §3.1 still lists n8n under the Automation category alongside Activepieces. This internal inconsistency could lead to accidental deployment or continued marketing of the tool.

Recommendation:

  1. Remove n8n from the website copy immediately
  2. Remove n8n from the Foundation Document tool table
  3. Remove the n8n reference from the Objection Handling Guide (§3.4 and §4.2)
  4. Audit all customer-facing materials for any remaining n8n references
  5. If you want to reference n8n anywhere, explicitly note it's available for internal/personal use only, not deployed on customer servers

Effort: Low (text edits across 3-4 documents)

🔴 CRITICAL ACTION ITEM #3: Odoo Community vs. Enterprise Clarity

The issue: Odoo Community Edition is LGPL-3.0, which is fine for your model. However, Odoo also has an Enterprise Edition under a proprietary license. Your website copy and sales materials reference "Odoo" without distinguishing which edition.

Specific risks:

  • If customers expect Enterprise-level features (e.g., advanced manufacturing, accounting localizations, HR payroll) that aren't in Community Edition, this could be a misrepresentation
  • The website pricing comparison says "CRM (HubSpot / Salesforce) €20-150 → Included" — but Odoo Community CRM has materially different capabilities than HubSpot or Salesforce
  • Your Tool Catalog lists Odoo as LGPL-3.0, which is correct for Community only

Recommendation:

  1. Clarify in website copy and the Open-Source Tools page that you deploy "Odoo Community Edition (LGPL-3.0)"
  2. In the pricing comparison table, be careful not to imply feature parity with commercial CRM/ERP tools — consider adding a footnote: "Open-source alternatives to these tools are included. Feature sets differ from commercial equivalents."
  3. Your ToS §2.3 already has good language about enterprise licenses being purchased separately — make sure this is visible on the website too

Effort: Low (copy edits)

2. Website Copy & Sales Pitch Compliance

2.1 Claims That Need Attention

🟡 IMPORTANT ACTION ITEM #4: "Your data never touches our systems" — Partially Inaccurate

The claim (Homepage): "Your data never touches our infrastructure or anyone else's."

The reality:

  • The Hub (hosted on LetsBe's EU infrastructure) processes account data, billing data, and aggregated telemetry
  • AI prompts (redacted) transit through OpenRouter to LLM providers — these pass through third-party infrastructure
  • Stripe processes payment data

Your Privacy Policy and ToS correctly distinguish these data flows, but the marketing copy oversimplifies. In a regulatory enforcement context, this kind of absolute claim could be problematic.

Recommendation:

  • Revise to: "Your business data stays on your server. Account management runs on our EU infrastructure. AI prompts are redacted before reaching any third party." or similar
  • The Privacy Policy's §4.4 "Data We Do Not Collect" section does this well — mirror that nuance on the website
  • Keep the strong privacy messaging, just avoid absolute claims that the legal docs then qualify

Effort: Low (copy edits on 2-3 pages)

🟡 IMPORTANT ACTION ITEM #5: "28+ tools" Count Accuracy

The claim: "28+ tools" appears throughout the website, pricing, and marketing materials.

The reality: Your Tool Catalog lists exactly 28 tools (including 3 core infrastructure tools — Orchestrator, SysAdmin Agent, Portainer — that aren't really "business tools" a customer would think of). The customer-facing tool count should reflect tools they'll actually interact with.

Also, the "+" in "28+" implies more than 28, but the catalog lists exactly 28.

Recommendation:

  • Either use "25+ business tools" (excluding core infrastructure) or "28 tools" (exact, no "+")
  • Alternatively, keep "28+ tools" but ensure the Open-Source Tools page actually lists 28+ distinct tools (which it currently does, though some like Static HTML hosting are thin)
  • Be consistent — the Foundation Document says 28, the website says "28+", and the tool grid on the Features page lists about 16 categories, not 28 individual tools

Effort: Low (decide on a number and update)

3. Legal Document Gaps

3.1 What You Have (and it's solid)

Your existing legal documents are remarkably thorough for a pre-launch startup:

  • Terms of Service v1.1 — Comprehensive, covers the infrastructure-provider positioning well, good AI disclaimers, proper EU consumer protections, EU AI Act section
  • Privacy Policy v1.0 — Detailed GDPR legal bases, CCPA disclosures, AI data flow transparency, subprocessor list
  • Data Processing Agreement — Referenced but not yet finalized (noted as open in ToS §14)
  • Cookie Policy — Drafted
  • Security & GDPR Framework — Thorough technical security documentation

3.2 Remaining Gaps

🟢 RECOMMENDED ACTION ITEM #6: Open Source License Disclosure Page

The gap: Your ToS §2.3 promises: "A complete list of deployed tools, their roles, and their licenses is published on our website." Your website copy (Page 6) has this list, but it currently lives in a Markdown doc, not a published web page. Before launch, this needs to be a live, maintained page.

What it should include:

  • Each tool name, description, license (with link to license text), link to upstream project, and the exact Docker image/tag deployed
  • A statement that you deploy unmodified upstream releases
  • Information on how to access source code (important for AGPL compliance — see Action Item #1)
  • Date of last update

Effort: Medium (requires building a page and a process to keep it updated)

🟢 RECOMMENDED ACTION ITEM #7: EU Representative (GDPR Art. 27)

The gap: Your Privacy Policy §1 notes this: "EU Representative (Art. 27): To be appointed before serving EU customers."

This is required before you serve your first EU customer. As a US-based LLC offering services to EU residents, you must designate an EU representative. Several services offer this (DataRep, MCF Technology Solutions, etc.) for a few hundred euros per year.

Effort: Low-medium (select a provider, update legal docs)

4. Additional Compliance Observations

4.1 Things You're Doing Right

These deserve acknowledgment because many startups miss them:

  1. License vetting is thorough. You caught and removed n8n, Windmill, Typebot, Invoice Ninja, Akaunting, Twenty, Outline, and Poste.io — all for legitimate license incompatibilities. Your selection criteria (§1 of Tool Catalog) explicitly excludes BSL, Sustainable Use, and similar source-available licenses.

  2. Infrastructure-provider positioning is smart. Your ToS §2.3 positions LetsBe as deploying upstream software on customer-owned servers, not as a software vendor. This is the correct legal framing for AGPL compliance — the customer is the licensee, running the software on their infrastructure.

  3. "Unmodified upstream Docker images" claim is important. If true (and maintained), this significantly reduces AGPL source code obligations. Make sure this is enforced in engineering — any LetsBe-specific patches baked into Docker images would change the calculus.

  4. AI data flow transparency is excellent. The Privacy Policy's §6 (AI and Your Privacy) and the four-layer Safety Wrapper are documented with more rigor than most enterprise SaaS companies manage.

  5. DeepSeek opt-in with enhanced redaction addresses the China data transfer concern proactively.

  6. EU AI Act section (ToS §12) positions you ahead of most competitors on transparency.

4.2 Future Risks to Monitor

  1. Odoo LGPL-3.0 and custom modules: If you ever build Odoo modules or customize Odoo code (not just configuration), those modifications must be released under LGPL-3.0. This is worth discussing with counsel before your engineering team starts building Odoo integrations that go beyond API calls.

  2. Expansion catalog tools: As you add P1/P2 tools from the expansion catalog, re-verify licenses at integration time. Licenses can change between versions (as you discovered with Typebot's switch from AGPL to FSL).

  3. AGPL "modification" boundary: The AGPL community generally considers configuration changes and API calls to not be "modifications" that trigger source code obligations. However, if you ever ship custom Docker images that bundle LetsBe-specific code with AGPL tools, that could be interpreted as creating a derivative work. Keep the Safety Wrapper and tool adapters architecturally separate from the tools themselves.

  4. Ghost's MIT license and content: Ghost is MIT-licensed, which is the most permissive. However, Ghost's default themes may have different licenses. Verify that any themes deployed are also properly licensed.

  5. Cal.com's AGPL and API usage: Cal.com's AGPL-3.0 license means that if you modify Cal.com's code (not just use its API), you must share the modifications. Your adapter-based approach (calling APIs without modifying source) should be fine.

4.3 Sales Pitch Observations

Your Objection Handling Guide is generally well-aligned with your legal docs, with one exception already noted (n8n reference in §3.4 and §4.2). Two additional notes:

  1. §2.4 ("Is this GDPR compliant?") — The response says "Yes — by design, not by checkbox." This is good but should add the qualifier that full GDPR compliance also depends on the customer's use (they're the data controller). Your ToS §12.2 covers this well — consider referencing it.

  2. §2.3 ("How do I know my data won't be used to train AI models?") — The response says "Your documents, emails, and CRM data stay on your server." This is correct for storage, but redacted prompts containing business context do reach LLM providers. The response later addresses this, but leading with "data stays on your server" and then qualifying it could feel misleading. Consider leading with the nuanced version.

5. Summary Action Items

# Priority Action Owner Effort
1 🔴 Critical Add source code access mechanism for AGPL tools (Hub page + website statement) Engineering + Legal Low
2 🔴 Critical Remove n8n from website copy, Foundation Doc, and Objection Handling Guide Matt Low
3 🔴 Critical Clarify Odoo = Community Edition (LGPL-3.0) in all customer-facing materials Matt Low
4 🟡 Important Revise "data never touches our systems" claims to match Privacy Policy nuance Matt Low
5 🟡 Important Standardize "28+ tools" count across all materials Matt Low
6 🟢 Recommended Build and publish the Open-Source Tools page as a live web page with version info Engineering Medium
7 🟢 Recommended Appoint EU Representative per GDPR Art. 27 before serving EU customers Matt + Legal Low-Med

6. Counsel Review Recommendations

Before launch, we recommend qualified legal counsel review the following specific questions:

  1. AGPL hosting model validation: Does deploying unmodified AGPL Docker images on customer-owned VPS instances, managed by LetsBe as a service, constitute "conveying" under AGPL §2? Does the infrastructure-provider positioning hold up?

  2. "Customer is the licensee" framing: Your ToS §2.3 and §7.2 say the customer is the licensee of the open-source tools. Is this legally defensible given that LetsBe provisions, configures, and maintains the deployments?

  3. AI prompt data and GDPR: Redacted AI prompts transit to US-based LLM providers. Is the EU-US Data Privacy Framework + SCCs transfer mechanism sufficient, particularly given the business context that may remain in redacted prompts?

  4. EU consumer protection specifics: German Widerrufsbelehrung format requirements, button labeling for orders (noted as open in ToS §14, item #6)

  5. Liability cap adequacy: €500/12-month-fees cap (ToS §8.2) given the scope of data processed and AI-driven operations

This document should be treated as a working compliance checklist and updated as items are resolved. It is not legal advice and should be supplemented by review from qualified legal counsel familiar with open source licensing, GDPR, and EU/US commercial law.