Added table with helper on how to choose license

Author: oskardudycz

rfc/002-License.md

@@ -20,7 +20,7 @@ Now, with contributors who've put significant work into these projects, I need t
 
 ## Background: The Pattern of Exploitation
 
-The current Open Source model assumes symmetry between all users. But as David Whitney argues, in his NDC talk ["Open-Source Exploitation"](https://www.youtube.com/watch?v=9YQgNDLFYq8), when there's a power imbalance between the largest organizations in the world and someone putting code on the internet, the organization always benefits. When the OSI insists cloud providers deserve equal treatment to individual developers, it forces projects into defensive positions.
+The current Open Source model assumes symmetry between all users. But as David Whitney argues, in his NDC talk ["Open-Source Exploitation"](https://www.youtube.com/watch?v=9YQgNDLFYq8), when there's a power imbalance between the largest organisations in the world and someone putting code on the internet, the organisation always benefits. When the OSI insists cloud providers deserve equal treatment to individual developers, it forces projects into defensive positions.
 
 The database world has experienced this firsthand:
 
@@ -50,7 +50,7 @@ The pattern becomes clear.
 
 Elastic and Redis (but not MongoDB) added AGPLv3 after their license changes. Two reasons:
 
-First, SSPL isn't recognized as open source by the OSI because it discriminates against offering software as a service. The OSI maintains that open source must treat all users equally—even when those users are trillion-dollar companies exploiting smaller projects.
+First, SSPL isn't recognised as open source by the OSI because it discriminates against offering software as a service. The OSI maintains that open source must treat all users equally - even when those users are trillion-dollar companies exploiting smaller projects.
 
 Second, strategy. AGPLv3 allows projects to legally incorporate improvements from forks. You can't take BSD-licensed code from Valkey and add it to SSPL Redis. But between compatible copyleft licenses? That works. Yes, also if there's more than one license to the same code.
 
@@ -60,23 +60,23 @@ The dual licensing trend represents adaptation to this reality. It's not ideal,
 
 ### Permissive Licenses: The Current Problem
 
-Apache 2.0, MIT, and BSD say: take this code, do whatever you want, just give attribution. This generosity becomes vulnerability when cloud providers monetize your work without reciprocating.
+Apache 2.0, MIT, and BSD say: take this code, do whatever you want, just give attribution. This generosity becomes vulnerability when cloud providers monetise your work without reciprocating.
 
 ### AGPLv3: Network Copyleft
 
 [AGPLv3](https://www.gnu.org/licenses/agpl-3.0.html) extends GPL's copyleft to network use. If you modify AGPLv3 software and users interact with it over a network, you must provide the source code of your modifications.
 
-"Users interacting over a network" means any service where users access the functionality—web applications, APIs, any network protocol. This applies only to modifications of the licensed software itself.
+"Users interacting over a network" means any service where users access the functionality - web applications, APIs, any network protocol. This applies only to modifications of the licensed software itself.
 
 Many developers misunderstand this. They believe AGPLv3 requires open sourcing their entire application. It doesn't. If you build a banking system using Emmett, your business logic remains proprietary. Only if you modify Emmett's core event sourcing engine and expose that modified version as a service would you need to share those Emmett modifications.
 
 ### SSPL: Explicit Service Protection
 
 [SSPL](https://www.mongodb.com/legal/licensing/server-side-public-license) takes AGPLv3 and replaces Section 13. The new text:
 
-> if you make the functionality of the software available to third parties as a service, you must release the "Service Source Code"—all management software, user interfaces, APIs, automation, monitoring, backup systems, storage software, hosting software.
+> if you make the functionality of the software available to third parties as a service, you must release the "Service Source Code" - all management software, user interfaces, APIs, automation, monitoring, backup systems, storage software, hosting software.
 
-If AWS (or any other company) wants to offer "Emmett-as-a-Service," they'd need to open source their AWS infrastructure used to run it. For normal usage—building applications—SSPL behaves exactly like AGPLv3.
+If AWS (or any other company) wants to offer "Emmett-as-a-Service," they'd need to open source their AWS infrastructure used to run it. For normal usage - building applications - SSPL behaves exactly like AGPLv3.
 
 ### The Fair-Code Movement
 
@@ -96,7 +96,7 @@ Dual license Emmett and Pongo under AGPLv3 and SSPL. Users choose:
 
 **AGPLv3 if**:
 
-- Your organization requires OSI-approved licenses,
+- Your organisation requires OSI-approved licenses,
 - You understand and accept network copyleft,
 - You want maximum compatibility with OSS tooling.
 
@@ -108,6 +108,17 @@ Dual license Emmett and Pongo under AGPLv3 and SSPL. Users choose:
 
 This is explicitly pro-user. Those preferring OSI-approved licenses choose AGPLv3. Those wanting clearer terms choose SSPL. Those licences ensure that core code of Emmett and Pongo remain open.
 
+| Use Case                                                                           | AGPLv3                                                                    | SSPL                                                               |
+| ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------ |
+| Use Emmett or Pongo as a dependency in an internal system (no modification)        | ✅ No obligations                                                         | ✅ No obligations                                                  |
+| Modify Emmett or Pongo for internal use only                                       | ✅ Must release modifications if accessed over a network                  | ✅ Must release modifications                                      |
+| Use unmodified Emmett or Pongo in a public-facing service (e.g., API, SaaS)        | ✅ No obligation to release code                                          | ✅ No obligation to release code                                   |
+| Modify Emmett or Pongo and expose it in a public-facing service                    | ✅ Must release modified source                                           | ✅ Must release modified source **and** all service infrastructure |
+| Offer Emmett or Pongo as a managed service (e.g., “Emmett-as-a-Service”)           | ✅ If unmodified, no obligation - if modified, must release modifications | ✅ Must release modifications and service stack                    |
+| Distribute an app embedding unmodified Emmett or Pongo                             | ✅ No obligations                                                         | ✅ No obligations                                                  |
+| Build and distribute proprietary plugins/modules using public APIs                 | ✅ Allowed if not modifying core                                          | ✅ Allowed if not modifying core                                   |
+| Embed Emmett or Pongo into a closed-source commercial product (with modifications) | ✅ Must release modifications                                             | ❌ Not allowed without releasing entire service stack              |
+
 ## Implementation
 
 ### License Files
@@ -120,16 +131,14 @@ There will be added License files explaining the licensing.
 
 ### Contributor License Agreement
 
-Contributor License Agreement (CLA) Summary
-
 To contribute code to Emmett or Pongo, people will need to sign a Contributor License Agreement. This ensures legal clarity and protects both contributors and maintainers. The key terms of the CLA are:
 
-1. **Rights Granted** - contibutors grant the project a license to use, modify, and distribute your contributions under both AGPLv3 and SSPL. This allows users to choose either license, and ensures consistency across the codebase.
-2. **Copyright** - Contibutors retain full copyright over their contributions. The project does not take ownership of your work. Attribution will be maintained as required by both licenses.
+1. **Rights Granted** - Contributors grant the project a license to use, modify, and distribute your contributions under both AGPLv3 and SSPL. This allows users to choose either license, and ensures consistency across the codebase.
+2. **Copyright** - Contributors retain full copyright over their contributions. The project does not take ownership of your work. Attribution will be maintained as required by both licenses.
 3. **Future License Options** - Contributors allow the project to add additional licenses in the future, provided your contribution remains available under AGPLv3 and SSPL. This flexibility enables adaptation to changing legal or strategic needs while preserving existing license paths.
 4. **Contributor Protection** - The CLA does not allow the project to relicense your work under more permissive or proprietary terms unless explicitly stated and agreed upon. The CLA applies only to the specific contributions you submit to this project.
 
-Why the CLA Is Needed?
+**Why the CLA Is Needed?**
 
 - It ensures clear legal rights for all users of the code under both licenses.
 - It protects contributors from unintended license violations or uncertainty.
@@ -148,7 +157,7 @@ Emmett and Pongo core remains free under AGPLv3/SSPL. No gatekeeping for regular
 To fund development and make Emmett and Pongo sustainable, I plan to provide additional paid products and services. For instance:
 
 - Advanced tooling for observability, troubleshooting and monitoring,
-- Web UI for project documentation, messages visualization,
+- Web UI for project documentation, messages visualisation,
 - Advanced multitenancy, security and other enterpise features,
 - Additional integrations with Cloud/AI/ML tooling.
 
@@ -160,23 +169,23 @@ I also want to offer support services and paid features prioritisation. But that
 
 I maintained Marten for years. Despite adoption and success, I couldn't make it sustainable. Good intentions don't pay bills.
 
-With Emmett and Pongo, I've been transparent from the start: these need to be sustainable for me to focus on them. Keeping Emmett unlicensed was deliberate—avoiding the permissive-to-restrictive transition that breaks trust.
+With Emmett and Pongo, I've been transparent from the start: these need to be sustainable for me to focus on them. Keeping Emmett unlicensed was deliberate - avoiding the permissive-to-restrictive transition that breaks trust.
 
 Now, with meaningful community contributions, I'm formalizing what I've always intended: a structure that's fair to contributors while enabling sustainable development.
 
 ## Risks and Trade-offs
 
-### Fork Risk
+### Fork Risk and External Managed service without contributing back
 
-Cloud providers may fork rather than negotiate. Valkey shows this is real. But maintaining forks requires resources, and I'd rather have a sustainable project than one exploited by cloud providers.
+Cloud providers may fork rather than negotiate. Valkey, Open Search, and DocumentDB show this is real. There's still a risk that someone will just run managed service on unmodified Pongo and Emmett using AGPLv3 without contributing back. Still, they will need to make it a publicly available open source. Thanks to that we can get the improvements back. Also, all of that requires resources and community work and getting a buy-in from users. On the bright side, having this risk should be a trigger for me to plan better core project work and productize additional features.
 
 ### Adoption Barriers
 
-Some organizations prohibit AGPL or SSPL. The dual approach maximizes compatibility, but some potential users will be lost. Better sustainable development with narrower adoption than broad adoption of an abandoned project.
+Some organisati ons prohibit AGPL or SSPL. The dual approach maximises compatibility, but some potential users will be lost. Better sustainable development with narrower adoption than broad adoption of an abandoned project.
 
 ### Complexity
 
-Two licenses create confusion. Clear documentation and decision trees help, but it's added friction.
+Two licenses can create confusion. Clear documentation and decision trees help, but it's added friction. That's also why we're doing it transparently as an RFC.
 
 ### Trust
 
@@ -188,7 +197,7 @@ This dual licensing addresses goals I've had from the beginning: creating sustai
 
 Will it work? MongoDB protected itself but faces ongoing community friction. Elastic and Redis found a middle path but spawned major forks. Projects staying permissively licensed often struggle with sustainability or watch cloud providers profit from their work.
 
-I'm choosing to formalize now what I've always planned, with community input. The alternative—continuing without proper licensing or choosing permissive licenses—guarantees either abandonment or exploitation.
+I'm choosing to formalise now what I've always planned, with community input. The alternative - continuing without proper licensing or choosing permissive licenses - guarantees either abandonment or exploitation.
 
 This isn't about getting rich or rug pull. It's about creating conditions where these projects can survive in a long-term, serving users and enabling me to get the full focus on them. This is the indended win-win for both sides.
 
@@ -208,11 +217,11 @@ Yes, if your plug-ins are separate modules that use public interfaces and do not
 
 ### Why offer SSPL if AGPLv3 already provides protection?
 
-SSPL makes the service-use restrictions more explicit and comprehensive. It removes ambiguity around what counts as a modification, and helps organizations who want stronger language around SaaS offerings without worrying about copyleft infecting unrelated application code.
+SSPL makes the service-use restrictions more explicit and comprehensive. It removes ambiguity around what counts as a modification, and helps organisations who want stronger language around SaaS offerings without worrying about copyleft infecting unrelated application code.
 
 ### What does SSPL require that AGPLv3 does not?
 
-SSPL extends the copyleft obligation: if you offer Emmett or Pongo as a service to third parties, you must open source not only modifications to Emmett or Pongo, but all the infrastructure code used to run that service—monitoring, orchestration, authentication, deployment scripts, UI dashboards, etc. For internal use or building apps with Emmett/Pongo, SSPL behaves like AGPLv3.
+SSPL extends the copyleft obligation: if you offer Emmett or Pongo as a service to third parties, you must open source not only modifications to Emmett or Pongo, but all the infrastructure code used to run that service - monitoring, orchestration, authentication, deployment scripts, UI dashboards, etc. For internal use or building apps with Emmett/Pongo, SSPL behaves like AGPLv3.
 
 ### What counts as a "modification" under AGPLv3 and SSPL?