Added table with helper on how to choose license

Author: oskardudycz

rfc/002-License.md

@@ -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.
@@ -168,15 +177,15 @@ Now, with meaningful community contributions, I'm formalizing what I've always i
 
 ### Fork Risk
 
-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 shows this is real. But maintaining forks requires resources and community work. They will need at least expose it as an open source, so we could get the improvements back..
 
 ### 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.
 
 ### 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