El lunes subes tu repositorio a GitHub para atraer colaboradores y, esa misma semana, un inversor pregunta qué tecnología puedes proteger. También reutilizas una librería open source, valoras ofrecer un SaaS y dudas sobre si todavía puedes patentar el núcleo de la solución. Una decisión tomada para ganar visibilidad puede cerrar opciones de protección si se publica antes de tiempo.
Qué pasa si combinas open source y patentes en un proyecto tecnológico: es posible, pero debes separar qué proteges. El código cuenta con copyright, una invención técnica puede patentarse y cierta información puede mantenerse como secreto empresarial. Publicar no elimina siempre una patente, aunque la licencia elegida puede conceder derechos sobre ella; en España y la UE, también importan los límites de patentabilidad del software.
Puedes abrir código y conservar una invención patentable
Puedes publicar parte de tu proyecto y proteger una invención técnica, siempre que presentes la solicitud antes de divulgar lo que hace nueva a esa invención. Piensa en una cafetera: el manual de montaje puede ser público, pero el mecanismo interno que regula la presión puede protegerse si cumple los requisitos de patente.
Una patente no protege el código fuente como tal. Protege una solución técnica descrita mediante reivindicaciones , que son las frases legales que delimitan qué puede impedirse a terceros. Si otra empresa programa desde cero la misma solución técnica reivindicada, podría haber infracción de patente aunque no haya copiado una línea de código.
El error más frecuente en este punto es creer que una solicitud de patente convierte todo el proyecto en propiedad exclusiva. No es así: el nombre comercial exige una marca, el código exige una licencia y una buena gestión de autoría, y los datos internos exigen confidencialidad.
El código abierto no cede todo el proyecto
Una licencia de software de código abierto concede permisos para usar, estudiar, modificar y redistribuir código bajo condiciones concretas. No suele transferir la titularidad de toda tu tecnología ni autoriza sin límites las patentes que puedas tener fuera del alcance del código licenciado.
Usar una dependencia abierta tampoco convierte por sí mismo toda tu aplicación en abierta. La respuesta cambia si distribuyes un programa combinado, si modificas una librería con copyleft o si tu servicio incorpora AGPL. La arquitectura y la licencia concreta importan más que la etiqueta genérica de “open source”.
La patente exige una aportación técnica
En España y en la Unión Europea, el software “como tal” queda fuera de la patente. La Ley 24/2015, de Patentes, y el Convenio sobre la Patente Europea permiten proteger una invención implementada por ordenador cuando el programa aporta una solución técnica a un problema técnico.
Un método de reservar mesas o una idea de negocio no se vuelve patentable por ejecutarse en una app. En cambio, un sistema que reduce de forma medible el consumo de batería de sensores IoT, mejora la transmisión de datos o controla un proceso industrial puede superar ese primer filtro si también es nuevo y no evidente.
La decisión segura es esta: identifica la parte técnica que crea valor, solicita la patente antes de hacerla pública y decide después qué módulos abrir. El repositorio puede enseñar cómo programas; la patente debe cubrir qué solución técnica impides copiar.
✉
¿Necesitas más información? Escríbenos y te orientamos
Patente, copyright, secreto y marca no son lo mismo
Un proyecto tecnológico suele necesitar entre dos y cuatro capas de protección: derechos de autor para el código, patente para la solución técnica, secreto empresarial para información no publicada y marca para el nombre comercial. Cada capa protege un activo distinto, como una casa donde la cerradura, el plano, la receta y el rótulo requieren medidas diferentes.
La Oficina Española de Patentes y Marcas tramita patentes y marcas en España, pero no registra automáticamente el copyright del software ni verifica que todas las licencias de tu repositorio sean compatibles. La titularidad del código nace con su creación, aunque conviene dejar pruebas y contratos claros.
Con más de 15 años de experiencia asesorando a empresas y emprendedores en patentes y marcas, este autor ha visto un problema repetido: un fundador cree que la marca de su SaaS cubre el algoritmo y descubre, al negociar inversión, que no tiene ni cesión escrita del desarrollador externo ni control sobre el repositorio.
La consecuencia verificable es que la marca solo cubre el signo comercial, no el código ni la invención.
Copyright: protege la expresión del código
Los derechos de autor protegen el código fuente y el código objeto desde que se crean. La Directiva 2009/24/CE trata los programas de ordenador como obras protegidas, pero no concede un monopolio sobre la idea, la función o el algoritmo abstracto.
Una licencia MIT, GPL o Apache 2.0 es el permiso que das a terceros sobre ese código. Sigues siendo titular salvo que firmes una cesión de derechos, pero ya no puedes ignorar los permisos que has concedido al publicar.
Las licencias Creative Commons suelen encajar mejor en documentación, vídeos o diseños gráficos. Para software ejecutable, es más prudente usar una licencia pensada para código y reconocida por la Open Source Initiative (OSI).
Secreto y marca protegen otros valores
El secreto empresarial protege información que no es pública, tiene valor por permanecer reservada y cuenta con medidas razonables de protección. Puede incluir datos de entrenamiento, reglas antifraude, precios internos, claves, procesos de fabricación o documentación técnica no publicada.
La marca registrada protege el nombre, logotipo o signo que permite al cliente identificar tu producto. Registrar “NubeFácil” no impide que otro cree una plataforma parecida; impide que use un signo confundible para servicios iguales o relacionados.
Mantener una parte como secreto funciona bien cuando es difícil descubrirla desde fuera. No funciona si la solución queda expuesta en un dispositivo vendido, en una API que revela su lógica o en un repositorio público.
Publicar antes de solicitar puede cerrar la patente europea
Publicar código, una demo detallada, una presentación técnica o documentación que permita reproducir la solución puede destruir la novedad de una patente en Europa. La novedad es absoluta: si la información fue accesible al público antes de la fecha de solicitud, aunque solo la vieran pocas personas, puede convertirse en estado de la técnica .
La Oficina Europea de Patentes, con sede en Múnich, aplica este criterio con rigor. Las excepciones por divulgación abusiva o por determinadas exposiciones oficiales son estrechas, normalmente dentro de un periodo de seis meses, y no son un plan de publicación seguro.
Una revisión inicial de patentabilidad y de libertad de operación suele requerir entre 2 y 6 semanas, según el campo técnico y los países revisados. Es menos tiempo que corregir una publicación precipitada, porque una divulgación pública no se puede retirar de la memoria de Internet ni de quien la descargó.
Qué puede contar como divulgación pública
Un repositorio de GitHub, una charla grabada, una página web, un vídeo de YouTube, una feria, un artículo técnico o un PDF enviado sin confidencialidad pueden contar como divulgación. No hace falta que el documento diga “patente” ni que explique cada detalle con lenguaje jurídico.
La pregunta práctica es si una persona experta en ese campo podría reproducir la solución a partir de lo publicado y de sus conocimientos normales. Una diapositiva comercial vaga puede no bastar, pero una demo con arquitectura, código y resultados técnicos suele ser peligrosa.
Un caso habitual es este: una startup publica una prueba de concepto para captar usuarios y presenta la solicitud ocho meses después. Si el repositorio explicaba el elemento técnico diferencial, la patente europea puede quedar comprometida, aunque el producto aún no tuviera clientes.
Qué hacer si ya enseñaste la tecnología
Documenta de inmediato qué se publicó, en qué fecha, dónde y con qué detalle. Guarda capturas, enlaces, archivos, listas de asistentes y acuerdos de confidencialidad, porque esa cronología permitirá valorar qué parte puede seguir siendo nueva.
Detén nuevas publicaciones técnicas hasta revisar el caso. Una solicitud puede conservar opciones para mejoras no divulgadas, para implementaciones concretas o para elementos técnicos que la demo no revelaba.
No copies la estrategia de Estados Unidos sin analizarla. Allí existe una ventana de gracia limitada para ciertas divulgaciones del inventor, pero no salva automáticamente una solicitud ante la OEPM o la EPO.
✉
¿Necesitas más información? Escríbenos y te orientamos
MIT, Apache, GPL y AGPL cambian tus obligaciones
Las licencias open source permiten usos comerciales en muchos casos, pero fijan reglas distintas sobre avisos, distribución, código derivado y patentes. Elegir una librería por popularidad sin leer su licencia es como alquilar una oficina sin comprobar si permite atender clientes o hacer obras.
MIT suele imponer pocas condiciones visibles, Apache 2.0 añade una licencia expresa de patentes y GPL o AGPL pueden obligar a compartir código en situaciones concretas. Ninguna licencia elimina el riesgo de infringir patentes de terceros fuera de lo que el titular haya autorizado.
Comparando varias fuentes especializadas y los textos oficiales de las licencias, lo que se repite es que Apache 2.0 ofrece una cobertura de patente más explícita que MIT, especialmente cuando hay muchos contribuidores. Esa diferencia importa si tu proyecto incorpora aportes de empresas, universidades o desarrolladores externos.
MIT permite reutilizar con pocos requisitos
La licencia MIT permite copiar, modificar, fusionar, publicar, distribuir, sublicenciar y vender el código, siempre que se conserve el aviso de copyright y el texto de licencia. Es breve y suele facilitar la adopción de una librería.
MIT no contiene una concesión expresa de patente comparable a Apache 2.0. Eso no significa que toda reutilización sea ilícita, pero sí que no debes asumir una autorización de patente amplia solo por leer “MIT” en un repositorio.
Apache 2.0 incluye licencia de patente
Apache License 2.0 concede una licencia de patente de cada contribuidor para las reivindicaciones que necesariamente infringe su contribución o su combinación con la obra. También exige conservar la licencia y los avisos, incluido el archivo NOTICE cuando exista.
Apache 2.0 incorpora una cláusula de represalia de patentes . Si quien recibe el código inicia determinadas acciones alegando infracción de patente contra un contribuidor o su obra, la licencia de patente concedida por Apache puede terminar para esa persona.
Esa cláusula no te autoriza a demandar libremente a cualquier tercero ni blinda toda tu cartera. Su alcance depende de las contribuciones y de la acción concreta, por eso debe revisarse antes de lanzar una reclamación.
GPL y AGPL requieren revisar el modo de uso
GPL es una licencia de copyleft: al distribuir un trabajo derivado o combinado bajo sus condiciones, puede exigir que el código correspondiente se ofrezca también bajo GPL. La Free Software Foundation explica sus licencias, pero el análisis real depende de cómo se integran los componentes.
AGPL añade un supuesto relevante para SaaS: si modificas el programa y los usuarios interactúan con él por red, puede surgir la obligación de ofrecer el código fuente correspondiente a esos usuarios. No basta con decir “no reparto instaladores”.
La compatibilidad entre licencias debe revisarse antes de combinar componentes, no solo al publicar el producto final. Las licencias BSD de dos y tres cláusulas se parecen a MIT por su carácter permisivo, aunque la BSD de tres cláusulas añade una restricción sobre el uso del nombre de los autores para promocionar derivados. LGPL permite, en determinados supuestos, enlazar una biblioteca con software propietario, pero exige respetar las condiciones que permiten al usuario sustituir o modificar la biblioteca; MPL aplica un copyleft limitado por archivo, de modo que los archivos modificados bajo MPL deben seguir disponibles bajo esa licencia.
También importa la versión: Apache 2.0 es compatible con GPLv3, pero no suele ser compatible con proyectos declarados exclusivamente bajo GPLv2 por sus condiciones de patentes. Esta revisión de licencias de código abierto evita asumir que todo copyleft produce el mismo efecto.
Elige apertura según tu producto y cómo cobras
La estrategia correcta depende de qué distribuyes, qué parte del producto crea ventaja y cómo obtienes ingresos. Una startup SaaS, una librería para desarrolladores y un dispositivo IoT pueden usar el mismo lenguaje de programación, pero no deberían copiar la misma política de licencias.
La patente puede reforzar una posición defensiva, pero no sustituye la libertad de operación. Tener una patente propia significa que puedes excluir ciertos usos de tu invención; no significa que seas libre para vender si un tercero tiene una patente anterior necesaria para tu producto.
Proyecto Código que suele abrirse Riesgo a revisar Vía de ingreso Startup SaaS SDK, conectores o cliente AGPL en el servicio Suscripción y alojamiento Librería Núcleo o API Titularidad de aportes Doble licencia Hardware o IoT SDK y controladores Firmware y secretos Venta, soporte y nube Estándar técnico Implementación de referencia Patentes esenciales Certificación o servicios
SaaS: separa servicio y componentes
Un SaaS puede abrir SDK, ejemplos o conectores para reducir fricción de integración y mantener privado el motor que procesa datos. Si el elemento diferencial se puede observar desde la API, el secreto puede ser débil y quizá convenga valorar patente antes de mostrarlo.
Revisa entre 20 y 100 dependencias en proyectos pequeños que usan paquetes modernos, incluyendo dependencias transitivas. Una librería indirecta puede introducir GPL, AGPL o avisos que tu equipo nunca vio de forma consciente.
Librerías y doble licencia
Una librería con MIT o Apache 2.0 suele atraer más adopción empresarial porque facilita la integración en productos propietarios. Si quieres cobrar a clientes que no pueden aceptar copyleft, el doble licenciamiento puede ser útil.
El doble licenciamiento exige controlar los derechos de todo el código. Si aceptas un pull request sin acuerdo de contribución, puede que no tengas facultad para ofrecer después una licencia comercial sobre esa parte.
IoT y estándares requieren capas separadas
En hardware e IoT conviene separar firmware, esquemas, SDK, protocolos, servicio en nube y documentación. Puedes abrir el SDK para que terceros conecten dispositivos, reservar el algoritmo de control y patentar una mejora técnica de sensor, señal o energía.
Cuando una tecnología sigue un estándar, revisa si hay patentes esenciales y reglas de licencia asociadas. El Acuerdo sobre los ADPIC de la OMPI fija un marco internacional, pero la libertad de operación debe analizarse país por país.
Decisión antes de publicar
1. Identifica la mejora técnica → 2. Revisa novedad y patentes ajenas → 3. Solicita antes de divulgar → 4. Elige licencia y publica
Open core y control de aportes permiten monetizar
Open core, doble licencia, soporte, alojamiento y patentes defensivas pueden convivir si delimitas con precisión qué código es abierto, quién posee cada aporte y qué tecnología mantienes reservada. La regla útil es no prometer una apertura que tus contratos, dependencias o solicitudes de patente no permiten sostener.
Con más de 15 años de experiencia asesorando a empresas y emprendedores en patentes y marcas, este autor ha visto una consecuencia verificable al aceptar código externo sin reglas: la empresa no pudo ofrecer doble licencia porque una contribución relevante carecía de cesión o licencia suficiente. El problema aparece tarde, normalmente al cerrar una venta corporativa o una ronda de inversión.
Si vas a publicar, captar inversión o incorporar contribuciones este trimestre, conviene revisar ahora la titularidad, el inventario de licencias y la divulgación técnica. Una revisión legal previa evita que una decisión de minutos genere meses de negociación, sustitución de código o rediseño.
Open core abre una parte delimitada
El modelo open core publica una base útil y reserva funciones empresariales, módulos avanzados o servicios gestionados. Funciona cuando la frontera técnica es real: módulos separados, documentación clara y contratos que no mezclan indebidamente código abierto y propietario.
No uses open core como etiqueta para ocultar incumplimientos de copyleft. Si la funcionalidad cerrada deriva de código GPL o queda obligada por AGPL, el nombre comercial del modelo no cambia la obligación de licencia.
Un SBOM evita sorpresas al crecer
Un SBOM es un inventario de componentes de software, parecido a la lista de ingredientes de un alimento. Debe incluir dependencia, versión, origen, licencia, modificaciones, avisos y responsable interno.
Incluye paquetes directos, transitivos, fragmentos copiados de foros, contenedores y herramientas de compilación. Conserva textos de licencia, avisos de copyright y NOTICE cuando Apache 2.0 u otras licencias lo exijan.
Las contribuciones necesitan trazabilidad
Una política de contribuciones debe pedir que cada persona declare que puede aportar el código y que no incorpora material de su empleador, cliente o proyecto anterior. Para proyectos con doble licencia, un Contributor License Agreement o una cesión bien diseñada puede ser necesario.
La revisión no debe limitarse al código. También revisa patentes potenciales, documentación técnica, datos de prueba y secretos que un colaborador pueda subir al repositorio sin autorización.
Este enfoque tiene menor relevancia si tu proyecto no incorpora software ni tecnología patentable, si solo usas programas abiertos como usuario final sin redistribuirlos, o si tu solución es solo una idea de negocio o un método abstracto. En esos casos suelen pesar más la marca, los contratos, el diseño y el secreto empresarial.
✉
¿Necesitas más información? Escríbenos y te orientamos
Dudas habituales
¿Puedo patentar un software open source?
Sí, si la invención aporta una solución técnica patentable y la solicitud se presenta antes de divulgar esa solución. La patente no cubre el código fuente completo, sino las reivindicaciones técnicas concedidas.
¿Publicar en GitHub me deja sin patente?
Puede dejarte sin patente en España y Europa si el repositorio revela la invención antes de presentar la solicitud. Que el repositorio tenga pocas visitas no evita que sea una divulgación pública.
¿Apache 2.0 es igual que MIT?
No. Apache 2.0 incluye una licencia expresa de patentes y una cláusula de terminación ligada a ciertas demandas de patentes; MIT no contiene una concesión expresa equivalente.
¿La GPL obliga a abrir todo mi programa?
No siempre, pero puede obligar a ofrecer el código correspondiente cuando distribuyes un trabajo derivado o combinado bajo GPL. El resultado depende de la integración técnica, no solo de que haya una dependencia GPL.
¿AGPL afecta a mi SaaS aunque no distribuya una aplicación?
Sí, puede afectar si modificas software AGPL y usuarios interactúan con él por red. La obligación se analiza sobre el programa y la interacción remota, no solo sobre la descarga de instaladores.
¿Una patente propia evita infringir patentes de terceros?
No. Una patente propia no garantiza libertad de operación, que es la posibilidad de vender sin invadir derechos de terceros vigentes en el país donde actúas.
¿Necesito permiso para aceptar pull requests?
Sí, necesitas reglas claras sobre autoría y licencia de cada aporte. Si planeas doble licencia o venta corporativa, conviene documentar desde el inicio y con cada contribución quién concede qué derechos.
Antes de abrir el repositorio, ordena tus derechos
La combinación de código abierto y patentes funciona cuando el orden es correcto: primero identifica la mejora técnica, revisa la novedad y presenta la solicitud si procede; después decide qué publicar y bajo qué licencia. Abrir código puede impulsar adopción, pero no debe ser una renuncia accidental a una patente, a un secreto empresarial o a un modelo de ingresos.
La decisión más segura para una pyme tecnológica en España es mantener un SBOM actualizado, conservar avisos, controlar contribuciones y revisar GPL o AGPL antes de distribuir o dar acceso por red. Si el valor está en una solución técnica visible, protege antes de enseñar; si el valor está en información interna difícil de descubrir, protege el secreto con contratos y controles.
