Los problemas de las licencias GNU

General
1

Por qué la GPL no lo arregla todo (y qué pasa cuando el código se convierte en negocio)

La GPL (y sus variantes LGPL/AGPL) nació con una promesa noble: proteger la libertad del software, garantizando que las modificaciones sigan siendo libres. En teoría, es una herramienta impecable. Pero en la práctica del desarrollo moderno, esa misma libertad se ha convertido en un arma de doble filo: protege el código, pero deja desprotegidos a los creadores frente a la explotación económica, la pérdida de control y la insostenibilidad.

Este post no ataca la GPL ni romantiza el software libre. Expone, sin rodeos, por qué proyectos que han dedicado miles de horas terminan cambiando de licencia cuando la GPL se convierte en un obstáculo para su supervivencia.

1. La GPL cumple su objetivo… pero su objetivo no es protegerte a ti

La GPL logra lo que promete: obliga a que cualquier modificación redistribuida siga siendo libre. Eso es valioso para el ecosistema.
Sin embargo, su objetivo no es proteger al creador original. No protege contra:

  • Forks que eliminan donaciones, rebrandean y monetizan el trabajo original sin compensación.
  • Empresas que usan el código en servicios cloud (SaaS) sin aportar ni un dólar ni una línea de código, aprovechando el "agujero de la nube".
  • La pérdida de control sobre la marca y la atención: cuando un fork con mejor marketing se convierte en "el que todos usan", el creador original queda en la sombra.

La GPL garantiza libertad de código, no ingresos, ni control de mercado, ni sostenibilidad para los mantenedores. Es una herramienta filosófica, no una estrategia económica.

2. El caso Sodium: cuando la libertad se convierte en explotación directa

Sodium, el mod de rendimiento para Minecraft más usado, estaba bajo LGPL-3.0. En 2024, sus mantenedores cambiaron a PolyForm Shield 1.0.0 (una licencia source-available con restricciones comerciales).

¿Por qué sucedió esto?

  • Forks como Rubidium y Embeddium recompilaban el código, eliminaban los botones de donación y lo integraban en modpacks comerciales.
  • Los autores originales perdían visibilidad e ingresos, mientras terceros lucraban con su trabajo sin violar la LGPL.
  • La comunidad se fragmentaba, y el equipo central veía cómo su esfuerzo era capitalizado por otros.

El cambio fue pragmático: renunciar a la "pureza" de la licencia para poder seguir desarrollando sin quemarse. La cláusula de "Noncompete" de PolyForm Shield les dio el control legal que la LGPL nunca proporcionó.

Fuentes del caso:
Licencia actual (PolyForm Shield)
Discusión oficial de los desarrolladores sobre el cambio

3. No es un caso aislado: la tendencia hacia licencias con control

Varios proyectos emblemáticos han tomado decisiones similares al chocar con los límites de las licencias tradicionales. Aquí el desglose de los grandes movimientos:

🔹 HashiCorp (Terraform)

El cambio: De MPL 2.0 (copyleft débil) a BSL (Business Source License).
La razón: Proveedores cloud (como AWS) ofrecían Terraform como servicio gestionado sin contribuir al código base, compitiendo directamente con los creadores.
(Referencia: Ver el fork comunitario OpenTofu nacido de esta decisión)

🔹 Elastic (Elasticsearch)

El cambio: De Apache 2.0 (permisiva) a SSPL (Server Side Public License).
La razón: AWS tomó el código, lo ofreció como servicio "Amazon OpenSearch" y compitió agresivamente capturando a los clientes de Elastic.
(Fuente: Elastic Licensing FAQ)

🔹 MongoDB

El cambio: De AGPLv3 a SSPL.
La razón: Diseñaron la SSPL específicamente para obligar a los proveedores de nube que ofrecen "MongoDB-as-a-Service" a liberar toda su infraestructura de gestión, algo que las nubes se negaron a hacer.
(Fuente: MongoDB SSPL)

🔹 Redis

El cambio: De BSD (muy permisiva) → RSAL/SSPL → AGPLv3 (Según contexto 2025).
La razón: Un ciclo constante intentando frenar la explotación comercial por nubes gigantes. El resultado final fue la creación del fork comunitario Valkey.
(Fuente: Redis License Update Blog)

4. Los mecanismos por los que los creadores pierden poder

El “rebranding” parasitario

Un fork puede coger tu código, cambiar el nombre, hacer un marketing agresivo y convertirse en la referencia. La GPL no protege tu marca. Legalmente, el fork es legítimo; comunitariamente, puede matar tu proyecto al desviar la atención y los recursos.

4.2. El costo prohibitivo de la defensa

Demandar a una empresa por violar la GPL/AGPL requiere abogados especializados, tiempo y mucho dinero. La protección legal existe en el papel, pero para un mantenedor individual, es una batalla imposible de financiar.

5. ¿Qué herramientas reales tienen los creadores?

Si la GPL no basta, estas son las estrategias que usan los proyectos sostenibles hoy en día:

  1. CLA (Contributor License Agreement): Exige que los colaboradores firmen un acuerdo desde el día 0 que te permita relicenciar el código en el futuro. Es polémico, pero evita el bloqueo legal descrito arriba.
  2. Dual Licensing: Ofrece el código bajo GPL (gratis) para la comunidad y vende licencias comerciales propietarias a empresas que no quieran las restricciones del copyleft (Modelo MySQL/Qt).
  3. Protección de Marca (Trademark): Licencia el código, pero protege ferozmente el nombre y el logo. Nadie puede llamar a su fork "TuProyecto Oficial".
  4. Licencias Source-Available (Opción Nuclear): Usar PolyForm Shield, BSL o SSPL. Recuperas el control comercial, pero sacrificas la etiqueta "Open Source" de la OSI y alienas a los puristas.

Conclusión honesta

La GPL es una herramienta poderosa para la libertad del usuario final, pero no es un seguro de vida para los desarrolladores.

  • Protege el código, pero no protege contra forks abusivos ni contra la explotación en la nube.
  • Es ideal para bienes comunes comunitarios (Linux, compiladores), pero insuficiente para productos que compiten en el mercado moderno.

El mensaje final es simple: Si tu prioridad es la libertad absoluta, defiende la GPL. Si tu prioridad es poder pagar las facturas y mantener el proyecto a largo plazo, protege tu trabajo con estrategia (marcas, CLAs) y sé pragmático con la licencia. Elegir con los ojos abiertos es mejor que lamentarse después.

4 Me gusta
2

Mientras haya personas con moralidad dudosa que quieran aprovecharse de mala fe del trabajo de otros, no existirá licencia que resuelva este problema, siempre habrá un vacío legal, un espacio a la interpretación, o la presión por parte del billete, la plata, el efectivo, ve nada más a Redis, y como con su fork sintieron tanta presión que terminaron adoptando una licencia AGPL.

La solución a todo esto es en realidad muy simple, que la mayoría de la sociedad abrace los principios éticos bajo los que se rige el software libre, con eso hasta la GPL saldría sobrando, pues nadie se agenciaría un proyecto con licencia permisiva porque iría en contra de sus principios, y aquellos que se sirven de un proyecto cooperarían con recursos para mantener el trabajo sobre el que se sostienen… muy simple, ¿verdad?

5 Me gusta
3

Como se que es la opinión de una «inteligencia» artificial, no leeré la publicación.

4 Me gusta
4

Es por eso que mencioné antes en este mismo foro que las licencias de código abierto corrigen muchos de estos problemas.

Se planteó por acá también que el código abierto no limita al usuario para distribuir software privativo junto con el software OS.

Esto me parece también una mejora porque el software Open source no restringe su distribución junto con otros programas de diferentes licencias y le da al usuario la opción de incluir lo que desee con total libertad.

La ventaja relacionada con esta publicación está en que cualquiera puede distribuirlo y modificarlo pero dejando en claro que parte del código es de su autoría sin tomar crédito por el código que no elaboró.

El autor original también tiene el derecho de exigir que las versiones modificadas se distribuyan bajo otro nombre, sin restringir la distribución en si.

Hace un tiempo elaboré una publicación en donde hago una observación comparativa entre ambos tipos de licencias y los requerimientos que deben cumplir para ser consideradas como tales.

5 Me gusta
5

A mí personalmente esto me importa un bledo, pero me dije, porque no atacar fuego con fuego? Aquí tienes:

Analisis y refutación punto por punto — “Por qué la GPL no lo arregla todo (y qué pasa cuando el código se convierte en negocio)”

Introducción corta

El post acierta en algo importante: la GPL (y variantes) están orientadas a preservar la libertad del software y no son una panacea económica. Pero muchas de las conclusiones del autor mezclan verdades técnicas con inferencias exageradas o soluciones que ignoran alternativas y efectos colaterales. Abajo reviso cada afirmación y muestro matices, errores de generalización y contraargumentos prácticos.

-–

  1. “La GPL cumple su objetivo… pero su objetivo no es protegerte a ti”

Afirmación del post: la GPL obliga a que las modificaciones redistribuidas sigan siendo libres, pero no protege al creador frente a forks que monetizan, explotación en la nube o pérdida de control de marca.

Refutación / matices:

Verdad parcial: Es cierto y conocido que la GPL protege libertades del usuario (ej.: ejecutar, estudiar, modificar, compartir) —esa es su intención explícita. La documentación del proyecto GNU y la FSF lo deja claro: la libertad, no el precio ni la sostenibilidad financiera, es el objetivo fundamental.

Pero decir “no protege al creador” como única conclusión es simplista. La GPL sí ofrece herramientas legales y comunitarias que ayudan al creador:

Fuerza legal contra apropiaciones abusivas: la GPL impone obligaciones de distribución del código fuente a quien redistribuye binarios; las violaciones son litigables y eso desalienta ciertos abusos (aunque conllevan coste). El problema real no es la ausencia de protección técnica sino la asimetría de recursos: un mantenedor individual puede tener menor capacidad de litigar frente a una empresa grande. Eso es un problema práctico, no una falla teórica de la licencia.

Complementos eficaces: la GPL se combina bien con protección de marca, CLA, políticas de contribución y modelos comerciales (soporte, hosting, plugins). No es “o GPL pura o ruina”; es una pieza en un conjunto de estrategias.

Conclusión: la GPL no promete ingresos. El error del post es presentar eso como si la GPL fuese inútil para los autores, cuando en realidad protege libertades y puede integrarse en estrategias de sostenibilidad.

(Fuente sobre la intención de la GPL: FSF/explicaciones oficiales).

-–

  1. “El caso Sodium: cuando la libertad se convierte en explotación directa”

Afirmación del post: Sodium (antes LGPL-3.0) cambió a PolyForm Shield por forks que “recompilaban” y monetizaban, quitando botones de donaciones y capitalizando el trabajo, y por eso el equipo cambió a una licencia source-available con cláusulas comerciales.

Refutación / matices:

Hecho: Sí, el equipo de Sodium discutió y movió partes del proyecto a una licencia más restrictiva (PolyForm Shield) para recuperar control comercial y frenar aprovechamientos que debilitaban la sostenibilidad del equipo. Hay discusiones y issues públicos sobre el tema en su repositorio.

Contexto importante: el hecho de que los autores optaran por PolyForm Shield muestra que las licencias source-available son una decisión deliberada de sostenibilidad, no “la única respuesta técnica”. Sin embargo:

Costo social: cambiar a una licencia con cláusulas restrictivas rompe expectativas de la comunidad y puede provocar forks libres alternativos (y pérdida de apoyo). Eso es exactamente lo que algunos críticos prevén: se protege la monetización pero se pierde ecosistema.

Alternativas que el post apenas menciona: antes de renunciar a la etiqueta “open source”, hay medidas intermedias —CLA para permitir relicencias futuras, dual-licensing selectivo, acuerdos comerciales con integradores principales, o fortalecer la visibilidad y servicios pagos (hosting, soporte, extensiones propietarias). Esas opciones pueden mitigar el problema sin cerrar la puerta a la colaboración.

Conclusión: el caso Sodium valida la preocupación de sostenibilidad, pero no prueba que la GPL “falla” universalmente —prueba que las comunidades y mantenedores muchas veces optan por tradeoffs conscientes entre apertura y supervivencia.

(Fuente: discusiones/issue y repo de Sodium).

-–

  1. “No es un caso aislado: la tendencia hacia licencias con control” (HashiCorp, Elastic, MongoDB, Redis)

El post enumera varias empresas que cambiaron licencias para frenar el “aprovechamiento” en la nube y proteger negocio.

Refutación / matices (por caso):

HashiCorp (Terraform → BSL):

Hecho: HashiCorp anunció el cambio a Business Source License (BSL) sobre sus productos core. Muchas personas/empresas respondieron creando forks (OpenTofu/OpenTF) para preservar una variante abierta.

Matiz: El BSL permite un período de tiempo tras el cual el código queda más abierto (según la versión), y HashiCorp mantuvo MPL/otros elementos abiertos en varias piezas. El cambio es una respuesta empresarial comprensible; también mostró que la comunidad puede reaccionar con forks, lo que no es “derrota absoluta” pero sí un coste social y técnico.

Elastic (Apache → ELv2/SSPL):

Hecho: Elastic cambió el licensing (introdujo Elastic License y SSPL en partes) motivado en gran parte por prácticas de grandes proveedores que ofrecían Elasticsearch como servicio sin colaborar con Elastic.

Matiz: Elastic buscó proteger su modelo de negocio. El efecto fue polarizar: algunos usuarios se mantuvieron con versiones previas, otros migraron a forks (OpenSearch por Amazon). Esto ilustra que la reacción puede ser fragmentación del ecosistema.

MongoDB (AGPL → SSPL):

Hecho: MongoDB publicó SSPL en 2018 como intento de obligar a proveedores de nube a abrir su infraestructura si ofrecen MongoDB como servicio; SSPL no fue aprobada como “open source” por OSI y fue polémica.

Matiz: Es un ejemplo clásico de intento de balancear libertad de código con protección comercial; la comunidad y órganos de certificación reaccionaron críticamente.

Redis (BSD → licencias source-available / AGPL / forks como Valkey):

Hecho: Redis Labs cambió su estrategia de licencias en los últimos años y eso llevó a respuestas de la comunidad, incluyendo forks como Valkey. La conversación sobre licencias Redis es reciente y activa.

Síntesis: todos estos casos prueban que hay tensión real entre abrir código y proteger ingresos para los desarrolladores/empresas. Pero la lección no es “la GPL es inútil”: es que no existe una solución legal pura que garantice simultáneamente apertura absoluta y exclusividad comercial. Cada licencia es una política con efectos: algunos buscan preservar libertad, otros buscan frenar explotación comercial.

(Fuentes: HashiCorp blog, Elastic blog, MongoDB press release, blog Redis/valkey).

-–

  1. “Mecanismos por los que los creadores pierden poder” — rebranding parasitario y coste de defensa

Afirmación del post: forks que rebrandean y mejores campañas de marketing pueden dejar al autor original en la sombra; además demandar por violaciones es caro.

Refutación / matices:

Rebranding y marca: es real: los derechos de marca son separados del copyright/licencia. La GPL no impide que alguien haga un fork y lo promocione; lo que sí permite es que el código siga siendo libre. Por eso es una práctica estándar combinar GPL con protección de marca (registros de marca y políticas de uso). Si la prioridad es la visibilidad y la identidad del proyecto, proteger la marca es una solución directa. El post lo menciona, pero lo presenta como si fuera marginal; en la práctica muchos proyectos exitosos usan marcas para preservar liderazgo.

Coste de defensa: es cierto que litigar por violaciones de licencia exige recursos; sin embargo:

La existencia de demandas exitosas por violaciones GPL en el pasado demuestra que la licencia tiene dientes si se la hace valer (empresas han tenido que publicar código cuando se las demandó). El coste existe, pero la disuasión funciona.

Alternativas complementarias: alianzas con organizaciones (OSI, FSF), campañas públicas de cumplimiento, o pedir ayuda de otras entidades pueden reducir la carga de un mantenedor individual.

Conclusión: el post acierta en el riesgo, pero lo presenta como un asunto sin solución técnica; la respuesta práctica es usar herramientas legales y comunitarias combinadas (marca, acuerdos, redes de apoyo).

-–

  1. “¿Qué herramientas reales tienen los creadores?” — CLA, dual licensing, marcas, source-available

El post enumera varias estrategias y sugiere que son las que usan los proyectos sostenibles.

Análisis crítico:

CLA (Contributor License Agreement):

Pros: permite a los titulares relicenciar, lo que facilita dual-licensing comercial más tarde.

Contras: puede desalentar contribuciones (por parecer centralizador) y generar fricción comunitaria si no se comunica bien. No es “maldita” ni “mágica”: es una herramienta con costes sociales.

Dual Licensing:

Pros: modelo probado (MySQL, Qt) —permite mantener una versión libre y otra comercial.

Contras: exige control del copyright (contribuciones asignadas), lo que implica procesos más formales y, a veces, menos contribuciones voluntarias.

Protección de marca:

Pros: eficaz para evitar que un fork use el nombre oficial y confunda usuarios. Es una de las defensas más directas frente a “rebranding parasitario”.

Contras: requiere tramitar y defender la marca.

Licencias source-available (PolyForm, BSL, SSPL):

Pros: proveen control comercial inmediato y pueden proteger ingresos.

Contras: rompen la relación con “open source” y pueden provocar forks libres alternativos o pérdida de ecosistema. Además, hay debate sobre su legitimidad en comunidades y en certificados OSI.

Refutación al tono del post: el texto original presenta estas opciones como si fueran las únicas rutas viables o que implican necesariamente “vender el alma”. En realidad son tradeoffs, cada uno con efectos previsibles —y muchos proyectos combinan varias de estas medidas (p. ej., marca + GPL + servicios). No hay un camino universal; hay que diseñar la estrategia que encaje con la comunidad y la realidad económica.

-–

Conclusión práctica (qué haría / aconsejaría)

1. Separar objetivos: decidir qué prioridad tiene el proyecto: máximo crecimiento de adopción (priorizar licencias permisivas/GPL según la filosofía) vs. sostenibilidad económica (complementos comerciales). No hay “licencia perfecta”.

2. Combinar herramientas: la mayoría de proyectos sanos usan una mezcla: licencia copyleft (para proteger código), marca (para proteger identidad), CLA o acuerdos (si quieren dual-licenciar), y modelos de negocio (servicios, hosting, soporte, plugins propietarios).

3. Comunicar el tradeoff con la comunidad: cambios de licencia generan fricción; explicarlos con transparencia y planes claros para la comunidad ayuda a evitar forks motivados por desconcierto.

4. Plan B: si la comunidad reacciona con forks libres (como OpenTofu/OpenTF para Terraform o forks de Redis), prepararse para competir por calidad, comunidad y servicios (no solo por licencia).

-–

Resumen final (de una frase)

La GPL cumple su propósito: proteger la libertad del software; sin embargo, no fue diseñada para garantizar la sostenibilidad económica de mantenedores por sí sola —y por eso muchos proyectos adoptan soluciones legales y comerciales adicionales. El post acierta en el diagnóstico del conflicto, pero exagera la “ineficacia” de la GPL; la realidad es que la GPL es una herramienta útil en un conjunto más amplio de estrategias que los mantenedores deben diseñar conscientemente.

-–

Fuentes clave (seleccionadas)

Propósito de “free software” y GPL — Free Software Foundation.

Discutido cambio/licencia y issues de Sodium (CaffeineMC repo / issue sobre PolyForm Shield).

HashiCorp anuncia adopción de Business Source License.

Elastic explica su cambio de licencia (Elastic License / SSPL).

MongoDB y el SSPL (anuncio y FAQ).

4 Me gusta
6

¿Entonces por qué lo modificas y comentas?, pasa de largo por favor

7

Tu forma de hablar en contra del laissez faire, utilizando conceptos en forma marxista, como en el caso de explotación económica, con una mirada positiva al mercantilismo, el privilegio a las corporaciones, en forma de protección que dices que falta, expone tu pensamiento proteccionista y contrario al libre mercado.

La licencia GPL permite un mercado libre, sin privilegios ni protecciones innecesarias para los agentes del mercado, despejando el camino y permitiendo la libre competencia, sin privilegios legales para quienes la utilizan.

8

Buenas,

He echado en falta algún ejemplo en el lado contrario, usando GPL o AGPL que permiten pagar facturas como el núcleo de Linux, GNOME, KDE productos de RHEL, Zabbix…

Un saludo

2 Me gusta
9

Dare mi OPINIÓN y se que muchos programadores me querran matar por esto;

La programación, la musica, la escritura, todas ellas tienen algo en comun algo, son ARTE y su valor no esta ligado a un bien fisico ni un servicio, por lo tanto su valor mas que económico es moral, puedes hacer dinero de prestar el servicio de tocar musica, de escribir o de programar, pero hacer dinero de vender arte es inviable, puedes hacerlo, pero necesitarías violar a tus clientes con restricciones ilogicas, ya que el arte estando en manos de una persona corre el afortunado riesgo de ser publico, al igual que el conocimiento, una vez publicado no lo puedes privatizar, el arte se hace por amor por placer y por hobbie, puedes ofrecer tus servicios de artista, pero el material artistico en si no es un bien económico, solo se pueden vender servicios y bienes, no arte, si vendes arte yna de 3, o no es rentable, o violas tus clientes o tienes mucha suerte y la gente conciente piensa en ti y vives de donaciones.

Creo que hacer software privativo solo por sacar un provecho económico, te hace igual a los monopolios que explotan a sus clientes y trabajadores.

1 me gusta
10

Estoy en desacuerdo, primero estaría bien aclarar que es el arte para ti, en mi caso sigo la teoría del arte de el artista SOLITARIO dado que no e estudiado otras más, pero bueno eso daría para una discucion aparte, siguiendo mi pensamiento sobre lo que es el arte, el arte es toda obra intelectual que plasma ideas culla fuente son los sentimientos y se hace de manera intencionnal y coherente, una obra de programación solo sería la obra no el arte, el arte es un concepto abstracto, es decir abstraemos la idea de lo material, en este caso la obra de arte

Por lo que un programador no necesariamente es un artista, ni que aga el código con licencia GPL o lo que sea, desde mi opinión eso no tiene nada que ver

Si vamos a debatir lo que es el arte estaría mejor hacer una nueva conversación aparte para no llenar este post con ese tema

1 me gusta
11

Bueno… soy un queso tocando cualquier instrumento, no se me da bien el dibujo, a veces me expreso de forma abrupta, y programo, no, definitivamente no es un arte

2 Me gusta
12

No, no, falto aclarar que no hablo de arte a nivel moral o calificativo como “esto es digno de ser arte” hablo de arte a efectos prácticos, representando todo material generalmente no tangible que en potencia puede ser arte, aunque no necesariamente lo sea, como si lo fuese. a eso me refiero con arte en este caso, porque mi definición de lo que es “digno” de ser arte tambien es mucho mas compleja, por otro lado un programa si puede ser arte, una clara demostración es GNU que nacio del Sentimiento de frustración de Richard Stallman y su deseo de libertad, siendo mas alla de un sistema portable un manifiesto simbolico de libertad, y de hecho esos programas son los mejores, los que la gente hace por amor, por funcionalidad o por una causa externa al dinero.

1 me gusta
13

Te entiendo en ese caso, pero sigo en desacuerdo en que tenga que ser arte necesariamente, supongo que a lo que te refieres es tratar el código como una responsabilidad moral, si me permiten usar esa palabra sin saber muy bien que es

El software libre es mejor en todos los sentidos por infinitas razones, y si alguien dedica su vida a ellos nada le impide a cobrar por este mismo, pero el echo de vivir como un bohemio escribiendo código no lo convierte en un artista ni tiene que serlo

Lo que si tiene que ser es una persona conciente y responsable con el software que genere y utilize en la medida de lo posible

1 me gusta
14

Claro, absolutamente, pero si alguien vive del software libre, en realidad no esta viviendo de vender “propiedad intelectual” esta viviendo de Prestar el servicio de programar, y respeto al arte, deberia haber una palabra que defina las cosas que pueden ser arte bajo ciertas circunstancias pero que no son arte necesariamente, porque claramente si todo es arte nada lo es, una palabra que englobe cosas como la musica, la escritura, la programación etc, que una vez se publican pasan a ser conocimiento general de dominio publico, y se convierten en un bien no económico. En cierto modo.

1 me gusta
15

A los que me refiero es que el material potencialmente artístico, mas haya de un valor económico, tiene un valor moral, a la hora de compartirse debe respetarse una responsabilidad moral por parte de quien las crea o comparte, que de no cumplirse afectara la propiedad privada y libertad de quien las recibe.

1 me gusta
16

En ese caso toda obra creada por una inteligencia conciente tiene un valor potencialmente artístico, abría que debatir más el asusto de si toda obra echa concientemente por una inteligencia tenga que estar ligada si o si a la moral, yo personalmente no lo creo al 100% dado que la moral se suele servir de lo que la sociedad dice que es moral, y no hay nada más que ver la sociedad en el estado en que está actualmente lara rectificar que algunas veces es contraproducente

1 me gusta
17

no dije que toda obra creada por conciencia tenga un valor potencialmente artistico, y basicamente casi cualquier cosa puede estar ligada a la moral, y no me refiero a la moral social de que hablas, hablo de principios universales que garantizan los derechos humanos, por ejemplo en este caso la libertad y propiedad privada, no cualquier mmda que se invente la sociedad xd.

1 me gusta
18

Lo que tu llamas licencias con control, son licencias para violar la libertad de los usuarios.

2 Me gusta
19

Como programador, si bien mi carrera ahora la tengo enfocada en administración de sistemas operativos y redes, programando ahora “poco”; no estoy de acuerdo contigo en que programar sea arte.

Si me lo permites, primero te voy a contrargumentar, con toda consideración, varios puntos:

  • La programación no tiene dimensión moral. Como ser tecnológico, es por definición amoral.
  • Hacer dinero haciendo arte o programando no sólo es viable, sino casi obligatorio. La experiencia misma de la historia lo atestigua en gran parte de los casos. De hecho, no sometes al cliente sino le sirves a él como artista; también como programador.
  • El arte nace del alma o del ser trascendente, pero no siempre se hace por amor o placer.
  • Hay otros elementos sobre el valor económico en los que no me interesa entrar.

Dicho esto, el arte, para ser tal debe ser un elemento de trascendencia del hombre, una elevación mediante la estética: esencia de la belleza; estética de la carece un programa per se, que son instrucciones abstractas que producen oscilaciones eléctricas en un procesador. Al respecto, recomiendo el libro Esculpir el tiempo de Andréi Tarkovski, el mayor cineasta, a nivel artístico, de todos los tiempos.

Por otro lado, una acepción más corriente, con menos pretensión filosófica, es la que comparte etimología con artesanía. Elemento que requiere de la habilidad y técnica, cuyo resultado final depende en gran medida del artesano; como el armero, herrero, peletero o alfarero. Muchos querrán ver en el programador una suerte de artesano, sobretodo en un buen programador; sin embargo la esencia de la programación no es sino la antagónica a la de la artesanía; siendo hija de la revolución industrial. Aquí entrarían artesanos famosos como Jean Tijou, la familia Helmschmid o Shoji Hamada.

Y, finalmente, en cuanto al trabajo “por amor al arte” es bastante alejado a la realidad histórica. Una cosa es el artista indie, de bajos recursos, con poca formación; y otra el artista clásico. Asemejado más bien a un arquitecto o un científico (en la naturaleza científica clásica, sobretodo renacentista). Los mayores artistas de la historia trabajaban bajo encargo, bajo el servicio a un cliente o mecenas. Miguel Ángel, da Vinci o Buonarroti dependían económicamente de sus mecenas Medici y/o el papa Julio II. Caravaggio tuvo como mecenas al cardenal Francesco Maria del Monte, Mozart era prácticamente explotado por su padre para el servicio a la aristocracia y la corte imperial en Viena, así como Velázquez fue pintor oficial de la corte del rey Felipe IV de España. Distintas órdenes monacales fueron clientes de Murillo. Y un largo etcétera.

Con estos planteamientos, y con experiencia como programador, concluyo que la programación no es un arte. Sí es una disciplina intelectual, pero no estética. Sí se le puede sacar contenido filosófico, tanto desde un punto de vista clásico como vulgar, este foro es prueba de ello, pero no tiene profundidad teleológica, elevación del espíritu ni dimensión moral.

3 Me gusta
20

Los programas, son obras útiles, creadas para ser utilizadas por la computadora. No son obras artísticas, las obras artísticas están creadas sin un propósito excepto el de ser admiradas, si una obra de arte es útil, entonces no es una. Piensa en el software como un manual de instrucciones, es una obra escrita y es útil para un propósito específico.

2 Me gusta