How one Discord DM turned into a deep‑dive on copyleft, client friction, and protecting an open‑core business.

The DM That Sparked a Rethink

Discord user: “Was the AGPL‑3.0 license intentional? I think that means it couldn’t be used in a closed‑source app.”

When Replyke v5 launched a couple of days ago, it shipped under a single AGPL‑3.0 license - for both the server and the client packages. A day later, this question came in through Discord. It raised a valid point and prompted a closer look at whether the licensing setup aligned with how developers would actually use the framework.

What Is Replyke?

Replyke is a headless framework for adding modern social features - such as comments, feeds, mentions, notifications, and reactions - into any app with minimal effort. It’s built for developers who want powerful plug-and-play tools without having to reinvent the wheel on complex social features that aren't part of their core value proposition.

The system consists of three main parts:

Server - a backend that handles data storage, social graph logic, moderation, and auth.
Core Hooks & Contexts - React-based tools that simplify interaction with the API and manage frontend state.
UI Components - fully functional components like a comment section that developers can drop into any React app and style as needed.

Take a typical use case: a developer building a cooking app wants users to post recipes, comment on them, and follow each other. With Replyke, they can import the SDK, drop in the <SocialCommentSection />, and connect to the hosted backend - no server work required.

This makes Replyke an appealing option for solo developers and small teams. But licensing plays a major role in how approachable that option actually is.

Why I Picked AGPL Everywhere (at First)

Keep improvements open. Replyke’s backend is the “secret sauce.” AGPL’s network‑copyleft clause ensures anyone running a modified server shares those changes.
One repo, one license. Simplicity felt safer on launch week.
Community spirit. Strong copyleft matched my open source ethos—until I realized it also erected walls for exactly the developers I wanted to help.

The Problem With Blanket Copyleft on Front‑Ends

Bundling = derivative work. Import an AGPL React hook, ship a JS bundle, and your whole front‑end must go AGPL.
Friction for small teams. Indie devs rarely have daylight to consult lawyers - or the desire to release their entire cooking‑app source code.
Perception matters. Many hear “AGPL” and stop reading.

The result: a license intended to ensure freedom can end up discouraging use.

Mapping Goals to License Features

Goal	Needed License Trait
Let devs build proprietary UIs	No strong copyleft on client packages
Keep server forks public	Strong copyleft (AGPL) on server
Prevent copy-and-paste rebrands	Trademark policy > license text
Offer corporate certainty	Patent grant (nice-to-have)

Licensing is a product-market fit exercise.

The Candidates I Considered

License	Pros	Cons
BSD-3-Clause	Ultra-permissive, non-endorsement clause	No patent grant; forks can rebrand easily
LGPL-3.0	Must publish modified lib files	Extra compliance burden; scares some lawyers
MPL-2.0	File-level copyleft; lighter than LGPL	No patent grant; still some friction
Apache-2.0	Permissive & patent grant; widely adopted	Doesn’t stop rebrand—handled via trademark

The decision tipped when I realized Apache-2.0 gives the same freedom as BSD-3 but with the patent safety net corporations look for.

The Final Split

🔒 Server (AGPL-3.0-only)

If you fork and deploy @replyke/server, you must share your changes. The community benefits, and it protects the hosted business model.

🔓 Client (Apache-2.0)

Import the hooks, tweak the UI, bundle it in your app - no obligation to publish code.

™ Trademark Notice (excerpt)

"Replyke" and the Replyke logo are trademarks of Replyke. You may not use these trademarks, or any confusingly similar marks, in connection with your own products or services without prior written permission. This includes, but is not limited to, using the trademarks in advertising, promotional materials, or as part of your product names.

Copyright licenses guard code; trademarks guard brand.

Why This Matters Beyond Replyke

Open-core playbook. Many SaaS businesses keep the backend copyleft and the SDKs permissive.
Developer empathy. The lighter your license friction, the faster others build cool things on top of your platform.
Legal literacy. A single DM can save (or sink) months of future adoption pain.

Try Replyke - Now With Less Friction

Whether you’re spinning up a hobby project or powering a production app, you can now use Replyke with more freedom!

Checkout the repo on GitHub

Final Thoughts

Picking a license isn’t a one-time legal chore - it’s product design. Replyke’s journey from “AGPL-everywhere” to a dual-license model shows how thoughtful licensing can protect an open-source mission and welcome the widest possible community.