http://www.dirinfo.unsl.edu.ar/jornadas/img/ebooks/prohibidopensar.pdf

Al hilo del post (aunque desde otra perspectiva, mas ligada al desarrollo de software) aquí dejo un link de un interesante libro en formato pdf titulado “PROHIBIDO PENSAR, PROPIEDAD PRIVADA”.

Algunos párrafos interesantes del mismo:

“La existencia de software provoca inevitablemente que nos preguntemos sobre
qué decisiones concernientes a él deberían tomarse. Por ejemplo, supongamos una
persona que teniendo una copia de un programa se encuentra con otra que desearía
tener una copia. La posibilidad de copiar el programa existe; ¿quién debería decidir
si esto se lleva a cabo o no? ¿las personas involucradas? ¿U otro sujeto, llamado
”dueño”?
Los desarrolladores de Software generalmente consideran estos problemas
basándose en que el criterio para resolverlos es maximizar los beneficios del
desarrollador. El poder político de la empresa ha llevado al gobierno a la adopción
de este último criterio así como el propuesto por los desarrolladores: que el programa
tiene un dueño, generalmente una compañía asociada a su desarrollo.
Me gustaría considerar el mismo problema pero usando un criterio diferente: la
prosperidad y la libertad del público en general.
La respuesta no puede provenir de la ley vigente —la ley debería amoldarse a la
ética y no al revés. Tampoco el día a día resuelve este problema, a pesar de que puede
sugerir algunas soluciones posibles. La única forma de juzgar es viendo quién se ve
ayudado y quién se ve perjudicado mediante el reconocimiento de dueños de software,
por qué, y cuánto. En otras palabras, deberíamos realizar un análisis del tipo costobeneficio
en nombre de la sociedad como un todo, teniendo en cuenta la libertad
individual así como la producción de bienes materiales.

Cómo los Dueños Justifican Su Poder

Aquellos que se benefician del sistema actual en donde los programas se entienden
como propiedad esgrimen dos argumentos en favor de su derecho de ser dueños de
programas: el argumento emocional y el argumento económico.
El argumento emocional es del tipo: ”Pongo mi cariño, mi corazón, mi alma en
este programa. Proviene de mí, es mío!”
Este argumento no necesita de una refutación seria. El sentimiento de cercanía
es uno que los programadores pueden cultivar cuando les viene bien; no es inevitable.
Considérese, por ejemplo, cuan deseosos esos mismos programadores firman y ceden
sus derechos sobre el programa a una gran compañía a cambio de recibir un salario;
el apego emocional se desvanece misteriosamente. Por el contrario, considérese a los
grandes artistas y artesanos de la época Medieval, que ni siquiera firmaban sus
trabajos. Para ellos, el nombre del artista no era importante. Lo que importaba era
que el trabajo se había hecho –y el propósito al que servía. Esta visión prevaleció
durante cientos de años.
El argumento económico es del tipo: ”Quiero ser rico (normalmente expresado de
manera poco precisa como ‘vivir de algo’), y si no me dejas llegar a rico programando,
entonces no programaré. Todo el mundo es como yo, de manera que nadie programará
jamás. ¡Y te encontrarás conque no tienes programas!” Esta amenaza suele estar
disfrazada de ‘consejo de amigo que viene de un sabio’.
Explicaré más tarde por qué esta amenaza es algo completamente absurdo.
Antes me gustaría presentar una suposición implícita que es más evidente en otra
formulación del mismo argumento.
Esta formulación empieza comparando la utilidad social del software privativo
con la utilidad sin ese software, y entonces llega a la conclusión de que el software
privativo es, en general, beneficioso, y debería ser promovido. La falacia aquí se
encuentra en comparar solamente dos posibilidades —software privativo vs. ausencia
de software— y suponiendo que no existen otras posibilidades.
Dado un sistema en el que impera la propiedad intelectual, el desarrollo del
software se encuentra generalmente vinculado a la existencia de un dueño que
controla el uso de ese software. Mientras existe este vínculo, estamos continuamente
frente a la elección entre software privativo o nada. Sin embargo, esta unión no es ni
inherente ni inevitable; es más bien una consecuencia de la decisión socio-legal
específica que estamos cuestionando: La decisión de tener dueños. Formular la elección
entre software privativo y ausencia de software está pidiendo a gritos este
planteamiento.

El Argumento en contra de Tener Dueños

La pregunta que se nos plantea es, ”¿Debería el software estar vinculado a la
existencia de dueños para, de esa manera, restringir su uso?”
Para poder resolver este problema, tenemos que juzgar el efecto en la sociedad
de cada de las dos opciones independientemente: el efecto de desarrollar el software
(sin tener en cuenta la manera en que se redistribuye), y el efecto de restringir su uso
(suponiendo que el software ha sido desarrollado). Si una de estas actividades es
beneficiosa y la otra es perjudicial, deberíamos deshacernos de la doble actividad y
usar sólo la beneficiosa.
En otras palabras, si restringir la distribución de un programa ya desarrollado es
perjudicial para la sociedad en su conjunto, entonces un desarrollador de software
que se considere ético debería rechazar esta opción.
Para determinar el efecto de restringir el poder compartir, necesitamos comparar
el valor, para la sociedad, de un programa restringido (v.g., privativo) con ese mismo
programa, pero accesible a todo el mundo. Esto nos lleva a comparar dos mundos
posibles.
Este análisis también tiene en cuenta el, a veces defendido, contra-argumento de
que ”el beneficio que se le proporciona al vecino al recibir una copia de un programa
se cancela con el perjuicio provocado al dueño.” Este contra-argumento presupone
que el perjuicio y el beneficio son iguales en magnitud. El análisis llevado a cabo
tiene en cuenta el comparar estas magnitudes, y el resultado muestra que el beneficio
es mucho mayor que el perjuicio.
Para clarificar todo esto, vamos a aplicarlo a otra área: la construcción de
carreteras.
La financiación para construir todas las carreteras podría provenir de peajes.
Como consecuencia nos encontraríamos puntos de peaje en cada esquina. Un sistema
de este tipo generaría incentivo a la hora de mejorar las carreteras. También tendría
la virtud de causar que los usuarios de una determinada carretera pagasen por ella.
Sin embargo, un punto de peaje es un obstáculo artificial para una conducción sin
cortes —artificial, porque no es una consecuencia derivada de cómo los coches o las
carreteras funcionan.
Si comparamos carreteras libres y carreteras con peaje por su utilidad, encontramos
que (siendo iguales), las carreteras sin puntos de peaje son más baratas de construir,
más baratas para administrar y más eficientes.3 En un país pobre, el peaje podría
provocar que algunas carreteras estuviesen inaccesibles a muchos ciudadanos. De
manera que las carreteras sin puntos de peaje ofrecen mayor beneficio a la sociedad
a menor costo; son preferibles por la sociedad. Luego la sociedad debería elegir
financiar las carreteras de otro modo, no mediante puntos de peaje. El uso de las
carreteras, una vez construidas, debería ser libre.
Cuando los defensores de los puntos de peaje los presentan como simples
recaudadores de fondos, distorsionan la elección que de verdad existe. Los puntos de
peaje incrementan los presupuestos, pero hacen algo además de eso: De hecho,
degradan la carretera. La carretera con peajes no es tan buena como la carretera
libre; el hecho de que se nos de más carreteras o carreteras técnicamente superiores
puede muy bien no ser una mejora si ello implica sustituir carreteras libres por
carreteras de peaje.
Por supuesto, la construcción de una carretera gratuita cuesta dinero, que de
alguna manera la gente tiene que pagar. Sin embargo, esto no implica la inevitabilidad
de los puntos de peaje. Nosotros, que en ambos casos pagamos, sacaremos mayor
beneficio de nuestro dinero si compramos una carretera gratuita.
No es estoy queriendo decir que una carretera con peaje sea peor que no tener
carreteras. Eso sería verdad si el peaje fuese tan grande que casi nadie pudiese usarla
—pero no es esta la intención para un recaudador de peajes. Sin embargo, debido a
que los puntos de peaje causan pérdida de tiempo y molestia considerables, es mejor
conseguir el dinero de una manera menos obstaculizadora.
Para aplicar este mismo argumento al desarrollo del software, mostraré ahora
que el tener ”puntos de peaje” en programas útiles le cuesta a la sociedad una
barbaridad: provoca que los programas sean más caros a la hora de construirlos,
más caros para distribuir, y menos satisfactorios y eficientes al usarlos. Se seguirá
que la construcción de programas debería ser promovida de alguna otra forma. Más
tarde, continuaré explicando otros métodos que promuevan y (hasta donde sea de
verdad necesario) financien el desarrollo de software.

El Perjuicio Ocasionado por Obstaculizar el Software

Considérese por un momento que un programa ha sido desarrollado, y que
cualesquiera pagos necesarios para su desarrollo se llevaron a cabo; ahora la sociedad
debe decidir entre convertirlo en privativo o dejar que se use y comparta libremente.
Supóngase que la existencia del programa y su disponibilidad se desean.4
Las restricciones sobre la distribución y modificación del programa no pueden
facilitar su uso. Sólo pueden interferir con él. Así que el efecto solamente puede ser
negativo. ¿Pero cuánto? ¿Y de qué tipo?
Existen tres niveles diferentes de daño efectivo que provienen de esta interferencia:
• Un menor número de personas usa el programa.
• Ninguno de los usuarios puede adaptar o arreglar el programa.
• Otros desarrolladores no pueden aprender del programa, o basar un trabajo
nuevo en él.
Cada nivel de perjuicio efectivo lleva asociado un perjuicio psicológico. Me
refiero al efecto que las decisiones de la gente tiene en sus sentimientos, actitudes y
predisposiciones posteriores. Estos cambios en la manera de pensar de la gente
tendrán un efecto posterior en sus relaciones con sus vecinos, y pueden acarrear
consecuencias efectivas.
Los tres niveles de perjuicio efectivo desaprovechan parte del valor que el
programa podría proporcionar, pero no lo pueden reducir a cero. Si desaprovechan
casi todo el valor del programa, entonces el hecho de escribir el programa perjudica
a la sociedad en tanto se dedicó esfuerzo en escribir el programa. Se podría decir que
aquel programa que produce beneficios al venderse debe proporcionar algún tipo de
beneficio material directo.
Sin embargo, teniendo en cuenta el perjuicio psicológico asociado, no existe
límite al perjuicio que el desarrollo de software privativo puede llegar a ocasionar.”