Open source license strategy¶

Análisis de licencias para el engine: Apache 2.0, MIT, BSL (Business Source License), SSPL, AGPL. Recomendación: Apache 2.0 para el core + opcional commercial license para enterprise features.

Por qué importa elegir bien¶

La licencia no es legal nitpicking; define: - Quién puede usarlo y bajo qué condiciones. - Si un cloud provider puede ofrecerlo como servicio compitiendo contra vos. - Si grandes corporaciones lo van a adoptar (legal teams allergic a algunas licencias). - Si la comunidad va a contribuir (algunas licencias matan contribution).

Camunda 7 era Apache 2.0. Camunda 8 (Zeebe) cambió a Source Available (Camunda Platform License). Esto bloqueó adopción en algunos sectores.

Las opciones¶

Apache 2.0 (defacto OSS permissive)¶

✅ Cualquiera puede usar, modificar, distribuir.
✅ Compatible con uso comercial.
✅ Patent grant.
✅ Inclusive (big corp tier 1 legal approval).
❌ AWS / GCP pueden ofrecerlo como managed service compitiendo.
❌ Sin garantías de contribución back.

Usuarios: Kubernetes, Spark, Kafka, Elasticsearch (hasta 2021), Cassandra.

MIT (similar a Apache)¶

Casi idéntico a Apache 2.0 pero sin patent grant explicit.
Más corta y simple.
Misma desventaja de cloud reselling.

BSD-3-Clause¶

Permissive, similar a MIT.
Permite uso comercial.
Patent grant ambiguo.

LGPL (copyleft débil)¶

Modificaciones a la library deben ser open source.
Linking permitido sin contagio.
Complicado para mobile / static linking.

Adopción: bajaron uso porque ambiguity.

AGPL (copyleft fuerte)¶

Si lo usás como servicio (network), DEBES open-source tu modificación.
✅ Bloquea cloud reselling.
❌ Big corps allergic; legal NO va a aprobar.
❌ Bloquea integración en SaaS propio (incluso si no modificás).

Usuarios: MongoDB (hasta 2018), Grafana (después de bumpear desde Apache).

SSPL (Server Side Public License — MongoDB)¶

"Si lo ofrecés como service, ALL the supporting code (k8s configs, etc.) debe ser open source".
Diseñada para bloquear AWS / cloud providers.
❌ OSI no la reconoce como open source.
❌ Big corps avoid.
❌ Comunidad Linux distros refuse to package.

Usuarios: MongoDB, Elastic (cambió en 2021).

BSL (Business Source License — MariaDB)¶

Source disponible.
Restricciones uso comercial por N años (típico 3-4).
Después de N años: auto-converts a Apache 2.0.
✅ Bloquea cloud reselling temporalmente.
✅ Permite "look at source" para enterprise.
❌ NO es open source mientras vigente.
⚠️ Adoption barrier.

Usuarios: MariaDB MaxScale, CockroachDB, Sentry, HashiCorp Terraform (2023), Camunda (BSL para Camunda 8 core).

Camunda Platform License (CPL — propietario "source available")¶

Source available para inspect.
Uso restringido a uso "interno" (no SaaS).
Camunda gana al ofrecer Camunda Cloud SaaS.
❌ Mucha gente lo considera "not open source" → friction.

Decision framework¶

Quién es el "user" tipo?¶

Si: - Mostly end-users en empresas: Apache 2.0 OK; minimiza friction. - Mostly otros vendors / cloud providers: BSL / SSPL para protegerte.

Nuestra hipótesis: usuarios = empresas que quieren engine de workflow para sus propias apps. Cloud providers (Camunda Cloud, AWS Step Functions, GCP Workflows) ya existen; competir con ellos directamente con Apache 2.0 podría dar AWS un boost si decide ofrecer "Amazon Workflow Engine" basado en el nuestro.

Trade-off: max adopción (Apache 2.0) vs commercial protection (BSL).

Modelo de negocio sustainable¶

Open core: core open, enterprise features privadas.
Hosted service: nosotros también ofrecemos managed; competir en UX/integración.
Support / consulting: revenue secundario.
Compete on innovation: liberar antes que cualquier fork.

Recomendación: Apache 2.0 + Open Core¶

Estructura¶

Repo: workflow-engine/
├── core/         ← Apache 2.0 (BPMN parser, engine, REST API, SDKs)
├── webapps/
│   ├── tasklist/ ← Apache 2.0
│   └── operate/  ← Apache 2.0
├── operator/     ← Apache 2.0
└── enterprise/   ← Commercial license (separado o privado)
    ├── advanced-rbac/
    ├── audit-tamper-protection/
    ├── multi-cluster-mesh/
    └── premium-support-features/

Beneficios¶

Maximizar adopción: Apache 2.0 = "yes go ahead" para 99% de legal teams.
Comunidad genuina: pull requests, plugins, integraciones.
Trust signal: "open source" más fuerte que "source available".
OSI approved: meta listings, OSS Capital, Linux Foundation friendly.

Mitigaciones contra cloud reselling¶

Trademark: el nombre del producto es protegido. AWS no puede vender "AWS Workflow Engine" — sería "AWS Engine compatible with X".
Brand: somos el creador; comunidad confía más en nuestra versión.
Velocity: features new salen primero en nuestra distro.
Hosted offering nuestro: directo "the upstream creators host it" wins.
Enterprise tier: features avanzadas requieren licencia paga.

Riesgos¶

AWS ofrece "managed workflow engine compatible with X" → impacta SaaS revenue.
Comunidad fork si decisiones nuestras no gustan.

Mitigación AWS-risk¶

Si AWS lanza managed service: - Liberar nuevas features rápido. - Foco en UX / DX (donde AWS típicamente es flojo). - Compatibility / migration tooling de la nuestra hacia ellos: que sea "fácil mover, fácil volver".

Si la AWS adoption es masiva: - Considerar bump de licencia core a BSL para nuevas major versions (M5+). - Las versions ya released con Apache stay Apache (no retroactivo). - Comunicar transparente: "BSL solo aplica si ofrecés como SaaS".

Contributor License Agreement (CLA)¶

Para mantener flexibilidad legal futuro (incluyendo posible re-license):

DCO (Developer Certificate of Origin): cada commit signed-off (git commit -s). Más liviano que CLA.
CLA: contributors sign legal doc. Más fricción pero más flexibilidad.

Recomendación: DCO. Similar a Linux kernel. Comunidad-friendly.

# Contributor flow
git commit -s -m "fix: handle nil case in timer scheduler"

Signed-off-by: Jane Dev <jane@example.com>

CI verifies cada commit tenga signoff.

Trademark policy¶

Documento separado en TRADEMARK.md:

The name "WorkflowEngine™" and the logo are trademarks of <org>.
You can use them to:
  - Refer to the project ("WorkflowEngine is great")
  - Describe compatibility ("Compatible with WorkflowEngine")
You cannot use them to:
  - Brand your fork ("Acme WorkflowEngine Edition") — needs permission
  - Suggest endorsement ("Powered by WorkflowEngine" → OK if true)
  - Confuse users about source ("This is the official WorkflowEngine")

Dependencies license audit¶

Cada release: licensee o scancode audit de todas las deps.

go-licenses report ./... --template templates/licenses.tmpl > LICENSES_THIRD_PARTY.md

CI bloquea PR que introduzca dep con licencia incompatible.

Documentación / contribución guidelines¶

CONTRIBUTING.md: cómo hacer PR, code style, tests.
CODE_OF_CONDUCT.md: Contributor Covenant 2.1 standard.
LICENSE: full Apache 2.0 text.
LICENSES_THIRD_PARTY.md: generated.
NOTICE: required por Apache 2.0; lista de copyrights.

Governance¶

Open project necesita governance clara:

BDFL (Benevolent Dictator) inicial.
En 1-2 años: Steering Committee con representación de major contributors.
Decisión técnica: RFCs públicos.
Decisión comercial: equipo founders.

Roadmap pública¶

github.com/example/workflow-engine/projects/roadmap

Issues / discussions for community input.

Release cadence pública¶

Patch: weekly.
Minor: mensual.
Major: trimestral o por necesidad.
Pre-release notes 2 weeks ahead.

Comparison table for stakeholders¶

License	Adopción esperada	Cloud reselling	Comunidad	Recomendación
Apache 2.0	Máxima	Sin protección	Activa	✅ Recomendado M1
BSL	Media-alta	Bloqueado N años	Friction	Considerar M5+ si AWS amenaza
AGPL	Baja-media	Bloqueado	Limitada (big corp avoid)	❌
SSPL	Baja	Bloqueado	Hostil	❌
Source Available (CPL-like)	Baja	Bloqueado	Frustrada	❌

Roadmap¶

M1-M4: Apache 2.0 estricto.
M5+: Evaluación de re-license para new MAJOR si threat de cloud reselling materializes. Decisión data-driven (revenue impact, customer feedback).
Always: enterprise features bajo commercial license, separados del core.