Propiedad intelectual y software libre

📐 Fundamento

Copyright en software:

El código está automáticamente protegido por copyright al escribirse. No necesitás registrarlo (en la mayoría de jurisdicciones). El autor (o su empleador, si es work-for-hire) tiene derechos exclusivos:

• Copiar.
• Modificar.
• Distribuir.
• Presentar públicamente.

Sin licencia explícita, NADIE puede usar tu código legalmente. El default es "todos los derechos reservados" — incluso si lo subís a GitHub.

Patentes de software — controvertido:

Permiten patentar algoritmos y métodos. Críticos:

• Algunas son obvias (Amazon's "1-click" patent).
• Generan "patent trolls" (empresas que solo cobran licencias sin producir nada).
• Software libre los considera amenaza.

El estado depende del país: USA y Japón permiten ampliamente; UE más restrictivo.

📐 Fundamento

Software Libre (FSF, Stallman, 1983):

4 libertades fundamentales:

0. Ejecutar el programa para cualquier propósito.
1. Estudiar cómo funciona y modificarlo (acceso al código fuente).
2. Redistribuir copias.
3. Distribuir versiones modificadas.

Open Source (OSI, 1998): mismo software técnicamente, marketing diferente para empresas.

Open Source ≠ Gratuito:

• "Free as in freedom, not as in beer."
• Podés vender software open source (Red Hat lo hace).
• Podés cobrar por soporte, certificación, hosting.

Tipos de licencias:

Más permisiva ─────────────────────────── Más restrictiva
Public Domain → MIT → Apache → MPL → LGPL → GPL → AGPL

Copyleft: "si usás mi código y modificás, tu modificación también debe ser libre" — protege la libertad propagándola.

Permisivo: "usalo como quieras, incluso en código propietario" — maximiza adopción.

Ejemplos reales:

• MIT: React, Vue, Angular, Node.js, Rails.
• Apache 2.0: Kubernetes, Hadoop, Spark, Android (mostly).
• GPL: Linux kernel, MySQL, GIMP.
• LGPL: glibc, GTK.
• AGPL: MongoDB (antes), Mastodon, Nextcloud.

MIT License — la más popular y simple:

MIT License

Copyright (c) [year] [fullname]

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED [...]

Cómo licenciar tu proyecto:

1. Elegir licencia (choosealicense.com ayuda).
2. Crear archivo LICENSE en la raíz del repo.
3. Copiar el texto completo de la licencia, ajustando año y nombre.
4. Mencionar la licencia en el README.

Sin LICENSE = todos los derechos reservados. Aunque sea público en GitHub, legalmente nadie puede usarlo (excepto bajo fair use limitado).

📐 Fundamento

Combinar código bajo licencias distintas puede ser problemático.

Reglas básicas:

Permisivo en permisivo:        ✓ (MIT en proyecto Apache OK)
Permisivo en copyleft:         ✓ (MIT en GPL OK, pero todo se vuelve GPL)
Copyleft en permisivo:         ✗ (no podés meter GPL en un MIT)
GPL v2 en GPL v3:              ✗ (incompatibles entre versiones GPL)

Problemas comunes:

• GPL contagia: si tu app usa una librería GPL, tu app debe ser GPL (al distribuirla).
• AGPL extiende GPL al uso por red: no podés evitar el copyleft solo ofreciendo SaaS.
• Dual licensing: algunos proyectos ofrecen GPL gratis + comercial pagado (MongoDB, MySQL antes).

Caso real — Linux y GPL:

Linux es GPLv2. Toda contribución al kernel debe ser GPLv2-compatible. Por eso muchos drivers comerciales son problemáticos.

Caso real — Android y Apache:

Android es Apache 2.0 (en su mayoría). Por eso los OEMs (Samsung, etc.) pueden agregar customizaciones propietarias.

Verificación de licencias:

# Auditar dependencias de tu proyecto
npm install -g license-checker
license-checker --summary

# Para Python
pip-licenses

# Detectar incompatibilidades en monorepos
fossa-cli analyze

📐 Fundamento

Plagio: usar código de otro sin atribución.

Tipos de plagio:
- Copy-paste literal sin atribución.
- Reescribir traduciendo a otro lenguaje sin atribución.
- Tomar idea/algoritmo sin acreditar.
- Usar código generado por IA y no declararlo (controversial).

Cómo evitarlo:

✓ Si copiás código MIT/BSD/Apache: incluir el copyright header en tu archivo.
✓ Si te inspirás en un algoritmo de un paper: citar el paper.
✓ Si usás StackOverflow snippet: técnicamente CC BY-SA (atribuir).
✓ Si fork-eás un proyecto: mantener el LICENSE original.
✓ Si re-implementás de scratch: sin obligación legal pero buena práctica acreditar inspiración.

Stack Overflow controvertido:

Hasta 2018: código en SO era CC BY-SA (copyleft con atribución). Después: MIT (más permisivo). Pero contenido viejo sigue bajo CC BY-SA.

Estrictamente, copiar de SO requiere atribución. En la práctica casi nadie lo hace.

Código generado por IA (Copilot, ChatGPT, Claude):

Tema legal en evolución. Cuestiones:

• ¿El código generado está protegido por copyright? (US Copyright Office: NO si solo es IA).
• ¿Si la IA fue entrenada con código GPL, el output es GPL?
• ¿Hay que declarar qué código fue generado por IA?

Buenas prácticas actuales:

• Revisá lo que la IA genera (puede tener copia literal de código).
• Documentá el uso de IA en tu proyecto.
• No asumas que es seguro relicensiar código generado.

📐 Fundamento

Argumentos a favor del software libre:

1. Libertad del usuario: controla tu propia tecnología.
2. Auditoría de seguridad: muchos ojos detectan más bugs.
3. No vendor lock-in: si la empresa muere, el código sobrevive.
4. Educativo: estudiantes pueden aprender de código real.
5. Innovación colectiva: Linux, Wikipedia, etc.

Argumentos a favor del software propietario:

1. Modelo de negocio sustentable: código privado permite vender licencias.
2. Control de calidad: un equipo dedicado vs voluntarios.
3. Soporte garantizado: SLA contractual.
4. Protección de IP: fundamental en algunos sectores (defensa, farma).

Modelos híbridos:

• Open core: core open source, features avanzadas comerciales (GitLab, Elastic).
• Dual license: GPL para uso libre + comercial para uso propietario (MySQL).
• Source-available: código visible pero no libre (BSL — Business Source License de HashiCorp).
• SaaS open source: WordPress.com (hosted) vs WordPress (self-hosted).

El SaaS loophole:

GPL requiere distribuir código si distribuís el binario. Pero si solo ofrecés el software como servicio (no distribuís binario), podés modificar GPL sin compartir.

AGPL cierra este hueco: cubre uso por red. Por eso MongoDB cambió a AGPL en 2018, y luego a SSPL (Server Side Public License) en 2019.

El cambio de licencias controvertido (2023-2024):

• HashiCorp: Terraform de MPL a BSL (más restrictiva). Resultado: comunidad creó OpenTofu.
• Redis: de BSD a SSPL/AGPL. Resultado: AWS y Linux Foundation crearon Valkey.
• Elastic: de Apache 2.0 a SSPL en 2021, vuelta a OSI-approved en 2024.

Razón: empresas open source se sienten "explotadas" por hyperscalers (AWS) que ofrecen su software como servicio sin contribuir.

Implicaciones éticas:

• ¿Es ético que AWS ofrezca Elastic sin contribuir? Legalmente sí. Éticamente debatible.
• ¿Es ético que Elastic cambie la licencia después de años? Legalmente sí. Éticamente debatible.

No hay respuesta única.