Acuerdo de Licencia y Cumplimiento de Software de Código Abierto (Open Source Compliance) para Producto Comercial
Modelo de política interna para auditar y gestionar las licencias de software de código abierto (MIT, GPL, Apache) usadas en un producto comercial, según el D.Leg. 822.
Actualizado al 6 de agosto de 2026 · Legislación peruana vigente · Licencia CC-BY-4.0
El archivo .docx se genera en tu navegador con html-docx-js, sin enviarse a nuestros servidores. Abrelo en Word, Google Docs o LibreOffice y reemplaza los campos resaltados en amarillo con tus datos.
ACUERDO DE LICENCIA Y CUMPLIMIENTO DE SOFTWARE DE CÓDIGO ABIERTO (OPEN SOURCE COMPLIANCE) PARA PRODUCTO COMERCIAL
[CIUDAD], [FECHA]
I. OBJETO
La presente Política Interna de Cumplimiento de Licencias de Software de Código Abierto (en adelante, la "Política") tiene por objeto establecer el procedimiento mediante el cual [RAZON_SOCIAL_DE_LA_EMPRESA], con RUC N° [RUC_DE_LA_EMPRESA], en adelante "LA EMPRESA", identifica, audita y gestiona el uso de componentes de software de código abierto ("open source") incorporados en el producto [NOMBRE_DEL_PRODUCTO_O_SERVICIO], a fin de garantizar el cumplimiento de las licencias de terceros bajo las cuales dichos componentes son distribuidos.
II. MARCO LEGAL
La presente Política se sustenta en el Decreto Legislativo N° 822, Ley sobre el Derecho de Autor, que reconoce al software como obra protegida y regula los derechos patrimoniales de reproducción, distribución, transformación y comunicación pública que el titular de una licencia de código abierto cede o limita mediante los términos de dicha licencia (tipo MIT, GPL, LGPL, Apache 2.0, BSD, entre otras). El incumplimiento de las condiciones de una licencia de código abierto puede constituir uso no autorizado de una obra protegida conforme al citado decreto legislativo.
Se deja constancia de que la presente Política es distinta del contrato de licencia de software a medida que LA EMPRESA suscribe con sus proveedores o clientes, el cual regula una relación bilateral de prestación de servicios; en cambio, esta Política regula el uso interno y la auditoría de componentes de terceros de acceso público incorporados al producto propio.
III. ALCANCE
Esta Política aplica a todo componente, librería, framework o módulo de software de código abierto que sea incorporado, enlazado, modificado o distribuido como parte de [NOMBRE_DEL_PRODUCTO_O_SERVICIO], sea en el código fuente, en dependencias de compilación o en dependencias de ejecución (runtime).
IV. INVENTARIO Y AUDITORÍA DE COMPONENTES
1. El equipo de [AREA_O_EQUIPO_RESPONSABLE] mantendrá un inventario actualizado ("Software Bill of Materials" o SBOM) de todos los componentes de código abierto utilizados, indicando: nombre del componente, versión, tipo de licencia, origen (repositorio) y fecha de incorporación.
2. Antes de incorporar un nuevo componente, el desarrollador deberá registrar la solicitud ante [RESPONSABLE_DE_APROBACION], indicando la licencia aplicable y el propósito técnico.
3. El inventario será auditado con periodicidad [PERIODICIDAD_DE_AUDITORIA] mediante herramientas de escaneo automatizado y revisión manual.
V. CLASIFICACIÓN DE LICENCIAS Y OBLIGACIONES
1. Licencias permisivas (MIT, BSD, Apache 2.0): requieren mantener el aviso de copyright y, en el caso de Apache 2.0, incluir notificación de cambios sustanciales.
2. Licencias con copyleft débil (LGPL): permiten el enlace dinámico sin obligar a liberar el código propietario, siempre que se respete la modularidad exigida por la licencia.
3. Licencias con copyleft fuerte (GPL): pueden generar la obligación de distribuir bajo la misma licencia el código derivado, por lo que su incorporación requiere aprobación previa de [RESPONSABLE_DE_APROBACION] y opinión legal cuando el componente se distribuya a terceros.
4. Queda prohibida la incorporación de componentes bajo licencias no identificadas o con restricciones incompatibles con el modelo de negocio de LA EMPRESA sin autorización expresa.
VI. RESPONSABLE DE CUMPLIMIENTO
Se designa a [NOMBRE_DEL_RESPONSABLE_DE_CUMPLIMIENTO], en el cargo de [CARGO_DEL_RESPONSABLE], como responsable de verificar el cumplimiento de la presente Política, resolver consultas sobre compatibilidad de licencias y mantener el registro de atribuciones que deban publicarse conforme a cada licencia (archivo de créditos o "NOTICE").
VII. INCUMPLIMIENTO
El incumplimiento de la presente Política por parte del personal de LA EMPRESA podrá dar lugar a las medidas disciplinarias internas que correspondan, sin perjuicio de la responsabilidad civil o penal derivada del uso no autorizado de obras protegidas conforme al Decreto Legislativo N° 822.
VIII. VIGENCIA
La presente Política entra en vigencia el [FECHA_DE_VIGENCIA] y será revisada con periodicidad [PERIODICIDAD_DE_REVISION] por [AREA_RESPONSABLE_DE_REVISION].
Aprobado por:
_______________________________
[NOMBRE_DEL_REPRESENTANTE_LEGAL]
Representante Legal
[RAZON_SOCIAL_DE_LA_EMPRESA]
RUC N° [RUC_DE_LA_EMPRESA]
Cuándo usar este modelo
Usa esta política cuando tu startup o empresa de tecnología incorpore librerías, frameworks o módulos de código abierto en un producto comercial y necesites documentar de forma ordenada bajo qué licencias se distribuye cada componente de terceros. El Decreto Legislativo N° 822, Ley sobre el Derecho de Autor, protege el software como obra y reconoce la validez de las licencias abiertas tipo MIT, GPL, LGPL o Apache 2.0 mediante las cuales el titular autoriza su uso bajo ciertas condiciones. Este documento es distinto del contrato de licencia de software a medida que firmas con un proveedor o cliente: aquí se trata de una política interna de auditoría de dependencias, no de un contrato bilateral de prestación de servicios.
Qué datos necesitas
- Razón social y RUC de la empresa que adopta la política.
- Nombre del producto o servicio en el que se incorporan los componentes.
- Área o equipo responsable del inventario de dependencias (SBOM).
- Nombre y cargo del responsable de aprobar nuevos componentes y de verificar el cumplimiento.
- Periodicidad de auditoría y de revisión de la política.
Paso a paso
- Identifica todos los componentes de código abierto ya incorporados en tu producto, incluidas las dependencias indirectas (transitivas).
- Clasifica cada componente según el tipo de licencia: permisiva (MIT, BSD, Apache 2.0), copyleft débil (LGPL) o copyleft fuerte (GPL, AGPL).
- Designa a un responsable de cumplimiento que apruebe la incorporación de nuevos componentes antes de que entren a producción.
- Establece el procedimiento de auditoría periódica con herramientas automatizadas de escaneo de dependencias.
- Documenta las obligaciones de atribución (avisos de copyright, archivo de créditos o "NOTICE") que exige cada licencia.
- Difunde la política entre el equipo de desarrollo y déjala firmada por el representante legal.
Errores comunes
- Confundir "gratuito" con "sin condiciones": toda licencia open source impone obligaciones, aunque no exija pago.
- Incorporar librerías con licencia GPL en un producto propietario sin evaluar el riesgo de tener que liberar el código derivado.
- No mantener un inventario actualizado de dependencias, lo que impide responder ante una auditoría de un inversionista o comprador (due diligence).
- Olvidar publicar los avisos de atribución que exigen licencias como MIT o Apache 2.0.
- Delegar la aprobación de nuevas librerías únicamente al criterio técnico del desarrollador, sin una revisión de compatibilidad de licencias.
Preguntas frecuentes
¿El uso de software open source requiere pagar regalías?
No, por definición el código abierto no exige pago, pero sí exige cumplir las condiciones de la licencia (atribución, publicación de cambios, o en algunos casos liberar el código derivado).
¿Qué diferencia hay entre esta política y un contrato de licencia de software a medida?
El contrato de licencia a medida regula la relación entre tu empresa y un proveedor o cliente sobre un desarrollo específico; esta política regula el uso interno de componentes de terceros ya publicados de forma abierta.
¿Es obligatorio tener esta política por ley?
El D.Leg. 822 no exige un documento específico, pero contar con esta política reduce el riesgo de infracción de derechos de autor y es un estándar exigido en procesos de inversión o adquisición de startups.
¿Quién debe firmar esta política?
El representante legal de la empresa, previa revisión del área técnica o legal responsable del cumplimiento de licencias.
Preguntas frecuentes sobre el modelo de acuerdo de licencia y cumplimiento de software de código abierto (open source compliance) para producto comercial
¿El modelo de acuerdo de licencia y cumplimiento de software de código abierto (open source compliance) para producto comercial es gratis?
Sí. Todos los formatos de Modelo.pe son 100% gratuitos, sin registro, sin login y con descarga ilimitada en Word (.docx). Puedes encontrar este y otros modelos en https://modelo.pe/acuerdo-de-licencia-y-cumplimiento-de-software-de-codigo-abierto-open-source-compliance-para-producto-comercial/. Licencia CC-BY-4.0 con atribución.
¿Puedo presentar este modelo de acuerdo de licencia y cumplimiento de software de código abierto (open source compliance) para producto comercial sin revisar?
No es recomendable. Es un formato referencial: cada caso tiene particularidades (fechas, montos, hechos, anexos) que requieren adaptación. Modelo.pe no brinda asesoría legal; verifica con un abogado antes de presentar cualquier documento.
Modelos relacionados
Acuerdo de Recompra de Acciones del Cofundador que Abandona la Startup antes de Cumplir el Vesting (Cláusula Good Leaver o Bad Leaver)
Acuerdo con el que la startup y los cofundadores remanentes pactan la recompra de las acciones del cofundador que abandona la empresa antes de completar su vesting, con base en la libertad contractual del Artículo 1354 del Código Civil, distinto del contrato de vesting inicial porque regula la salida anticipada.
Acuerdo de Derecho de Información y Reporte Financiero Periódico a Favor de Inversionista Minoritario
Modelo de acuerdo por el cual la startup se obliga a entregar reportes financieros periódicos a un inversionista minoritario, en desarrollo del derecho de información del accionista reconocido en el artículo 261 de la Ley General de Sociedades.
Acuerdo de Derecho de Preferencia (Pro-Rata Rights) para Inversionista en Futuras Rondas de Capital
Modelo de acuerdo que extiende contractualmente a rondas futuras el derecho de suscripción preferente del inversionista, en línea con el artículo 207 de la Ley General de Sociedades sobre suscripción preferente de acciones.
Acuerdo de Confidencialidad para Acceso a Data Room de Due Diligence en Ronda de Inversión
Modelo de acuerdo de confidencialidad para regular el acceso temporal de un potencial inversionista al data room financiero y legal de la startup durante el due diligence, sustentado en la buena fe contractual y, cuando corresponda, en la Ley 29733.
Acuerdo de Acciones Fantasma (Phantom Stock) como Incentivo sin Dilución para Ejecutivo de Startup
Modelo de acuerdo de acciones fantasma (phantom stock) que simula contractualmente el valor económico de acciones como incentivo a un ejecutivo, sin diluir el capital ni otorgar derechos societarios, al amparo de la libertad de contratar del Código Civil.
Acuerdo de Cesión de Propiedad Intelectual de Consultor o Freelancer Externo a Favor de la Startup
Modelo de acuerdo de cesión expresa de la titularidad de los derechos de autor sobre los desarrollos que un consultor o freelancer independiente realiza para la startup, conforme a la presunción de titularidad del autor regulada en el Decreto Legislativo 822.
Calculadoras legales útiles
Usa nuestras calculadoras peruanas para complementar este modelo: plazos procesales, pensión de alimentos, liquidación laboral, UIT 2026, interés BCRP e IGV 18%.
Ir a calculadoras