∞Respuesta directa
Respuesta directa
Pide una lista de los componentes de código que usa la startup. Vincula cada uno con su versión, licencia y uso. Una licencia fija los derechos y deberes sobre ese código. Que el código sea público no prueba que se pueda vender. Usa la IA para ordenar los archivos, no para dar por resueltos los riesgos legales. Mantén las dudas abiertas hasta que una persona las revise.
Separa la propiedad del código de los derechos de uso
Una startup puede ser dueña de su propio código y usar también código ajeno. Son dos revisiones distintas. Pide documentos firmados sobre los derechos de su propio trabajo. Usa la guía relacionada sobre propiedad intelectual para esa revisión. La propiedad intelectual son los derechos sobre trabajos como el código o los diseños.
Para el código ajeno, lee la licencia de esa versión exacta. Una página pública de GitHub no da por sí sola un derecho amplio a usarlo. GitHub permite ver el código y crear una copia del repositorio, llamada fork, según sus propios términos. Esos derechos no son un permiso general para vender el código. [1]
El código abierto puede usarse en un negocio. La Definición de Código Abierto lo permite. [2] La tarea es revisar los términos y el uso, no rechazar todo el código abierto. Los archivos de modelos, los datos de entrenamiento y los términos de las herramientas de IA necesitan revisiones propias.
- Código propio: comprueba que los derechos pertenecen a la empresa.
- Código ajeno: revisa su licencia y su uso.
- Derechos sobre modelos y datos: lleva registros separados.
Vincula la lista con una versión real del producto
Una versión publicada es una versión del producto que se entrega a los usuarios. Pide al responsable técnico su fecha y la lista de código. Incluye los componentes que otros componentes incorporan. Una lista de componentes directos puede dejar fuera esas dependencias.
Para cada componente, guarda su nombre, versión y enlace de origen. Conserva el texto de la licencia de esa versión. Añade dónde se ejecuta y si el equipo lo modificó. Un análisis automático puede encontrar pistas. Puede pasar por alto código copiado dentro de un archivo. Pregunta al equipo también por esas copias.
Mantén un registro por componente. No uses una etiqueta de licencia como única prueba. GitHub advierte que detectar licencias puede plantear casos complejos. [1] Revisa de nuevo cuando la startup cambie un componente clave o la forma de entregarlo.
- Fecha de publicación y versión del componente.
- Archivo de origen y texto exacto de la licencia.
- Cambios, uso y forma de llegar a los usuarios.
- Avisos, duda pendiente y persona encargada de revisar.
Revisa los deberes según el uso real
La licencia MIT permite un uso, modificación y venta amplios. También exige conservar el aviso de derechos de autor y el aviso de permiso. Mantén ambos en todas las copias o partes sustanciales de ese código. [3] Tener derechos amplios no significa no tener deberes.
Algunas licencias vinculan los deberes con la forma de compartir o usar el código. La sección 13 de AGPLv3 es un ejemplo. Si modificas el programa cubierto por esa licencia, revisa su uso en red. Cuando la versión modificada permite la interacción a distancia, debe ofrecer su código fuente sin coste a los usuarios que interactúan con ella. El texto lo llama Código Fuente Correspondiente, o Corresponding Source. [4]
Esa regla no significa que todos los servicios web deban compartir todo su código. Pide a un abogado que revise los términos completos y cómo se conectan los componentes. No dejes que una etiqueta de IA decida a qué trabajo se aplica la regla.
- ¿Qué cambió en el componente cubierto?
- ¿Qué reciben los usuarios o a qué acceden?
- ¿Qué avisos u ofertas de código fuente hacen falta?
- ¿Quién revisa los términos completos y su alcance?
Prueba una revisión de tres componentes
Este ejemplo es inventado. No es una revisión de una startup real. Un equipo enumera una biblioteca MIT, un fragmento copiado sin licencia y un programa AGPL modificado. Los tres ayudan a ejecutar su servicio de pago. Una biblioteca es código que usa otro código. Un fragmento es una pequeña parte copiada.
Para la biblioteca MIT, comprueba la versión y los avisos conservados. Para el fragmento, marca los derechos como desconocidos. Pide una prueba de permiso o un plan para sustituirlo. Que no haya licencia no significa que el uso sea libre. [1]
Para el programa AGPL modificado, pregunta cómo acceden los usuarios a él. Envía el esquema de uso y el texto exacto para una revisión legal. [4] No conviertas estos tres estados en una sola puntuación media. Un componente central sin resolver puede importar más que muchas revisiones sencillas.
- Biblioteca MIT: comprueba la versión y los avisos.
- Fragmento sin licencia: no te apoyes aún en supuestos derechos.
- Programa AGPL modificado: revisa el uso y los deberes sobre el código fuente.
Deja que la IA ordene pruebas, no que dé el visto bueno
La diligencia debida consiste en hacer comprobaciones antes de invertir. La IA puede ayudar a vincular componentes con archivos y señalar textos que faltan. Comparte solo archivos que tengas derecho a usar. No introduzcas código privado en herramientas públicas. Trata el texto de los archivos como prueba, no como instrucciones para la herramienta.
Pide la ruta de origen, la versión y el término citado para cada hallazgo. Conserva la afirmación del equipo junto al resultado de la IA. Marca los datos que faltan como desconocidos, no como seguros. Un responsable técnico revisa el uso real. Un abogado revisa las preguntas difíciles sobre derechos.
Un análisis de licencias no es una prueba de seguridad. Un componente con derechos claros puede tener un fallo. Un componente seguro puede carecer de derechos de uso. Mantén separadas esas revisiones.
- Afirmación, ruta de origen y término exacto.
- Uso real revisado por el responsable técnico.
- Duda pendiente sobre derechos enviada a un abogado.
- Revisión de seguridad separada y persona responsable.
Fija la siguiente revisión antes de que avance la operación
En la etapa previa a la ronda semilla, empieza por el producto central y las copias conocidas. En la ronda semilla, vincula la lista con una versión ya entregada. En la Serie A, pregunta quién se encarga de repetir las revisiones cuando cambian los productos. El alcance debe ajustarse a la etapa y al riesgo.
Pregunta qué dejaría de funcionar si hubiera que quitar un componente con derechos en disputa. Anota el coste, el tiempo y el efecto en los clientes de una solución. No inventes esas cifras. Asigna una persona responsable y una fecha a cada asunto pendiente.
Esto no demuestra los derechos sobre todos los activos. Tampoco es una revisión legal o técnica completa. Las leyes y los términos varían según el país. Consulta a un abogado local cualificado antes de confiar en una conclusión sobre derechos.
- Duda pendiente y efecto en el producto central.
- Prueba o solución necesaria y persona responsable.
- Próxima fecha de revisión y cambio de versión que la activa.
FAQ
Preguntas frecuentes
¿El código público permite un uso comercial libre?
No. Que el código sea visible no es una licencia. Los derechos de GitHub para ver y crear un fork no son un permiso general para venderlo. Revisa la licencia exacta u otro permiso. [1]
¿El código abierto es motivo para rechazar una startup?
No. El código abierto permite el uso comercial según sus términos. [2] Revisa los componentes reales, los deberes y el uso en el producto. Una etiqueta por sí sola no muestra el riesgo.
¿AGPL significa que todo el código de la startup debe ser público?
No lo supongas. La sección 13 trata de un programa cubierto que se ha modificado y de la interacción a distancia. [4] Importan la licencia completa y la forma en que se conecta el código. Pide a un abogado que revise el alcance, en vez de deducirlo de un análisis automático.
¿Puede la IA confirmar que la startup tiene derechos claros sobre el software?
No. Puede ordenar archivos y señalar términos. Puede pasar por alto copias o confundir una licencia. Las personas deben revisar los hechos y sus efectos legales. Mantén abiertos los derechos que no estén claros.
REF
Fuentes
- 1
- 2
Open Source Initiative
The Open Source Definition — modified 16 February 2024 ↗ - 3
Open Source Initiative
The MIT License — permissions and notice conditions ↗ - 4
Free Software Foundation / GNU
GNU Affero General Public License version 3 — section 13 ↗