Monetizar open source es viable con cuatro modelos probados: dual licensing (AGPL gratis y licencia comercial de pago), open core con funciones premium, soporte y hosting gestionado, y patrocinios tipo GitHub Sponsors cobrados por tu LLC. La licencia decide el modelo: MIT facilita la adopción pero no obliga a pagar; AGPL empuja a las empresas hacia tu licencia comercial.
Tu repositorio tiene estrellas, issues abiertos por empresas que facturan millones y un bote de donaciones que no paga ni el café. El código libre genera valor todos los días; el problema es que nadie está obligado a devolvértelo.
La salida no es cerrar el código: es estructurar cómo cobras por permisos, certeza o conveniencia. Y hacerlo con una entidad que firme contratos y reciba pagos sin enredar tus finanzas personales.
¿Por qué los proyectos con miles de usuarios no facturan?
Porque la licencia libre regala el uso, y el uso gratuito no se convierte en ingreso por gratitud. Las empresas pagan por tres cosas: permisos que la licencia no da, garantías que el repositorio no ofrece y trabajo que nadie más sabe hacer.
Todo modelo serio de monetización ataca una de esas tres palancas. Lo demás, esperar donaciones espontáneas, es lotería con mal premio.
¿Qué modelos reales existen para monetizar open source?
El menú es corto y está probado por proyectos que ya viven de esto:
- Dual licensing: el mismo código bajo licencia libre y bajo licencia comercial.
- Open core: núcleo abierto y módulos premium cerrados.
- Soporte con tiempos de respuesta, consultoría e implementación.
- Hosting gestionado: cobras por operar tu propio proyecto.
- Patrocinios y sponsors corporativos con contraprestaciones.
Los creadores de contenido recorrieron antes este camino: cobrar audiencias globales con estructura, como quienes deciden monetizar un canal de YouTube mediante una empresa americana. El software repite la jugada con más palancas.
Dual licensing: el mismo código, dos permisos distintos
Publicas bajo una licencia copyleft fuerte como AGPL: quien la usa y modifica sobre una red debe liberar su propio código. Las empresas que no quieren abrir el suyo compran tu licencia comercial.
El requisito legal: controlar el copyright completo. Pide a cada contribuidor un acuerdo de cesión (CLA) antes de integrar su código, o el relicenciamiento se vuelve imposible.
Open core: núcleo libre, funciones de pago
El proyecto base resuelve el problema completo para individuos; las funciones de empresa viven en módulos de pago: SSO, auditoría, permisos granulares, alta disponibilidad.
La línea se traza con un criterio: gratis lo que adopta, de pago lo que administra. Si capas el valor esencial, la comunidad se va; si lo regalas todo, no hay negocio.
Soporte y hosting: cobrar por certeza, no por código
El código es gratis; tu tiempo y tu garantía, no. Contratos de soporte con SLA, versiones con mantenimiento extendido y consultoría de implementación son ingreso recurrente clásico.
Formalizarlo pide una entidad que firme: así opera cualquier negocio de soporte técnico que factura a empresas de USA con contrato y ACH.
El hosting gestionado sube la apuesta: el cliente paga suscripción por usar tu proyecto sin operarlo. Es la vía con mejor recurrencia y la que más infraestructura exige.
GitHub Sponsors y patrocinios: que cobre la empresa
Los sponsors funcionan cuando dejan de ser propina y se vuelven factura: paquetes con logo en el README, canal prioritario de soporte y voz en el roadmap.
Cobra esos patrocinios con tu LLC y no a título personal: contratos claros, ingresos separados y gastos deducibles ordenados.
Como dueño extranjero firmas la W-8BEN, y con un treaty claim puedes reducir la retención del 30% que pesa sobre ciertos ingresos de plataformas de USA. Cada tratado es distinto; valida el de tu país antes de asumir el número.
¿MIT o AGPL? La licencia que habilita o mata cada modelo
Antes de vender nada, revisa qué permite tu licencia actual. Esta tabla resume el mapa:
| Licencia | Qué permite al usuario | Modelo que habilita |
|---|---|---|
| MIT / Apache 2.0 | Usar y cerrar casi sin condiciones | Open core, soporte, hosting, sponsors |
| GPL | Copyleft al distribuir binarios | Dual licensing en software distribuido |
| AGPL | Copyleft incluso en uso por red | Dual licensing en SaaS y servicios |
| Licencia comercial propia | Lo que tu contrato diga | La mitad de pago del dual licensing |
Con MIT no puedes vender permisos: ya los regalaste. Vendes entonces conveniencia y certeza. Con AGPL conservas la palanca de permisos, a costa de fricción en la adopción corporativa.
El circuito del dinero: cuenta, pasarela y suscripciones
Licencias, sponsors y hosting necesitan aterrizar en una cuenta empresarial de USA. Abrirla sin vivir allá es rutina: mira cómo abrir cuenta sin SSN usando tu LLC y su EIN.
Con la cuenta lista conectas Stripe para cobrar licencias y suscripciones. Los requisitos de la cuenta comercial son papeles que ya tienes: documentos de formación, EIN y pasaporte.
¿Tu proyecto también vive en las tiendas de aplicaciones?
Si el modelo incluye una app de pago, entra la capa de las stores: la cuenta de organización de Apple exige número DUNS, y la comisión del 30% baja al 15% con el Small Business Program por debajo de $1 millón.
Google Play cobra 15% en el primer millón. Los detalles de publicar con tu LLC merecen capítulo aparte, incluidos los enlaces a compra externa que Apple debe permitir en USA desde 2025.
Impuestos del proyecto libre: lo que el IRS espera igual
Aunque tu código sea libre, tu LLC no queda libre de formularios: una single-member de dueño extranjero presenta cada año el 1120 pro forma con la Forma 5472, venza el 15 de abril o lo prorrogues a octubre.
Omitirla cuesta $25,000, como detalla esta guía sobre la multa de la 5472. Registra aportes y retiros con fecha, monto y concepto desde el primer sponsor.
Y cuando muevas utilidades a tu país, compara las comisiones reales de cada riel: en un proyecto de margen ajustado, el costo de transferir es parte del modelo.
De repositorio a negocio: el arranque concreto
La secuencia sana: elige tu modelo, alinea la licencia, exige CLA a los contribuidores y monta la entidad que cobra. En American Prana hemos formado más de 2,800 LLCs para fundadores hispanos, muchos de ellos developers que cobraban como personas físicas.
Puedes crear tu LLC en minutos y dedicar el resto del trimestre a lo verdaderamente difícil: que tu proyecto valga lo que cobras por él.
Preguntas frecuentes
¿Puedo cobrar por software publicado con licencia MIT?
Por el código en sí, no: la licencia MIT ya concede uso comercial gratuito a cualquiera. Lo que vendes alrededor es soporte con tiempos de respuesta, hosting gestionado, funciones premium cerradas bajo el modelo open core y patrocinios corporativos. Si tu plan es vender permisos de uso, necesitas una licencia copyleft como AGPL más una licencia comercial paralela.
¿Qué es el dual licensing y qué necesito para aplicarlo?
Es ofrecer el mismo código bajo dos licencias: una libre tipo AGPL, que obliga a compartir modificaciones, y una comercial de pago que libera de esa obligación. Para aplicarlo debes controlar el copyright completo del proyecto, así que cada contribuidor firma un acuerdo de cesión antes de que integres su código. Sin esa cadena de cesiones no puedes relicenciar.
¿GitHub Sponsors se cobra a nombre personal o de la LLC?
Estructúralo hacia la empresa: los patrocinadores corporativos serios prefieren factura y contrato con una entidad, y tu contabilidad queda separada de tus finanzas personales. Como dueño extranjero certificas tu condición con la W-8BEN, y un treaty claim puede reducir la retención del 30% sobre ciertos ingresos de plataformas de USA, según el tratado de tu país.
¿Mi LLC declara impuestos aunque el proyecto apenas facture?
Sí. Una single-member LLC de dueño extranjero presenta cada año el 1120 pro forma con la Forma 5472, con vencimiento el 15 de abril y prórroga posible hasta el 15 de octubre; omitirla se sanciona con $25,000. Si vendes remoto y sin presencia en USA, el income tax normalmente se paga en tu país de residencia, no en Estados Unidos.
