\PassOptionsToPackage{unicode=true}{hyperref} % options for packages loaded elsewhere
\PassOptionsToPackage{hyphens}{url}
%
\documentclass[10pt,twoside,spanish,a5paper,]{book}
\usepackage{lmodern}
\usepackage{amssymb,amsmath}
\usepackage{ifxetex,ifluatex}
\usepackage{fixltx2e} % provides \textsubscript
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
  \usepackage[T1]{fontenc}
  \usepackage[utf8]{inputenc}
  \usepackage{textcomp} % provides euro and other symbols
\else % if luatex or xelatex
  \usepackage{unicode-math}
  \defaultfontfeatures{Ligatures=TeX,Scale=MatchLowercase}
\fi
% use upquote if available, for straight quotes in verbatim environments
\IfFileExists{upquote.sty}{\usepackage{upquote}}{}
% use microtype if available
\IfFileExists{microtype.sty}{%
\usepackage[]{microtype}
\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
}{}
\IfFileExists{parskip.sty}{%
\usepackage{parskip}
}{% else
\setlength{\parindent}{0pt}
\setlength{\parskip}{6pt plus 2pt minus 1pt}
}
\usepackage{hyperref}
\hypersetup{
            pdftitle={Proyecto Harmony considerado dañino},
            pdfauthor={Bradley M. Kuhn},
            pdfborder={0 0 0},
            breaklinks=true}
\urlstyle{same}  % don't use monospace font for urls
\usepackage[bmargin=2.5cm,bindingoffset=0.5cm,hcentering]{geometry}
\usepackage{graphicx,grffile}
\makeatletter
\def\maxwidth{\ifdim\Gin@nat@width>\linewidth\linewidth\else\Gin@nat@width\fi}
\def\maxheight{\ifdim\Gin@nat@height>\textheight\textheight\else\Gin@nat@height\fi}
\makeatother
% Scale images if necessary, so that they will not overflow the page
% margins by default, and it is still possible to overwrite the defaults
% using explicit options in \includegraphics[width, height, ...]{}
\setkeys{Gin}{width=\maxwidth,height=\maxheight,keepaspectratio}
% Make links footnotes instead of hotlinks:
\DeclareRobustCommand{\href}[2]{#2\footnote{\url{#1}}}
\setlength{\emergencystretch}{3em}  % prevent overfull lines
\providecommand{\tightlist}{%
  \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
\setcounter{secnumdepth}{0}

% set default figure placement to htbp
\makeatletter
\def\fps@figure{htbp}
\makeatother

\usepackage{setspace}
\usepackage{fancyhdr}

\newcommand{\copyleft}{\reflectbox{©}}

\pagestyle{fancy}
\setlength{\headheight}{15.2pt}
\fancyhead[]{}
\fancyhead[LE]{\footnotesize{\leftmark}}
\fancyhead[RO]{}

\renewcommand{\chaptermark}[1]{\markboth{#1}{}}
\renewcommand{\sectionmark}[1]{\markright{#1}{}}

% Por alguna razón pandoc lo pone en 0
\setlength{\parindent}{15pt}

% Cortar por cualquier lado, lo encontré en texexchange
\expandafter\def\expandafter\UrlBreaks\expandafter{\UrlBreaks%  save the current one
\do\a\do\b\do\c\do\d\do\e\do\f\do\g\do\h\do\i\do\j%
\do\k\do\l\do\m\do\n\do\o\do\p\do\q\do\r\do\s\do\t%
\do\u\do\v\do\w\do\x\do\y\do\z\do\A\do\B\do\C\do\D%
\do\E\do\F\do\G\do\H\do\I\do\J\do\K\do\L\do\M\do\N%
\do\O\do\P\do\Q\do\R\do\S\do\T\do\U\do\V\do\W\do\X%
\do\Y\do\Z}

% No mostrar los copetes en las imágenes
\usepackage[labelformat=empty]{caption}

\usepackage{microtype}

% Poner la autora en el título
%
% Para esto el título del capítulo tiene que tener el formato "Título.
% Autora"
%
% https://stackoverflow.com/a/1507530
\usepackage{substr}
\usepackage[explicit]{titlesec}
\titleformat{\chapter}[hang]{}{}{0cm}{%
  \raggedleft
  \Huge \BeforeSubString{ --- }{#1}\\
  \IfSubStringInString{ --- }{#1}{%
  {\Large \itshape ---\BehindSubString{ --- }{#1}---}%
}}

% https://tex.stackexchange.com/a/233271
% resuelve https://github.com/jgm/pandoc/issues/1632 y además no muestra
% guiones vacíos como con el substring anterior
\titleformat{name=\chapter,numberless}[hang]{}{}{0cm}{%
  \Huge #1\markboth{#1}{#1}%
}

\raggedbottom

% eliminar numero de pagina en las paginas con figuras grandes
\usepackage{floatpag}
\floatpagestyle{empty}

% para la licencia
\usepackage{tabularx}
\renewcommand{\arraystretch}{2}
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
  \usepackage[shorthands=off,main=spanish]{babel}
\else
  % load polyglossia as late as possible as it *could* call bidi if RTL lang (e.g. Hebrew or Arabic)
  \usepackage{polyglossia}
  \setmainlanguage[]{spanish}
\fi

\title{Proyecto Harmony considerado dañino}
\author{Bradley M. Kuhn}
\date{}

\begin{document}
\maketitle

\newpage
\thispagestyle{empty}

\begin{flushleft}

\begin{tabularx}{\textwidth}{c X}
  \raisebox{-\totalheight}{\includegraphics[height=5em]{images/logo_edsl.png}} &

  \hbox{\Large{En Defensa del Software Libre}}

  En Defensa del Software Libre es una revista de teoría sobre
  Software y Cultura Libres. Se edita en papel y se distribuye
  gratuita y libremente en formato digital. \\
\end{tabularx}

\vfill
\copyleft  \the\year -- En Defensa del Software Libre.
\url{https://endefensadelsl.org}

Salvo donde se exprese lo contrario, los artículos y la edición se
liberan bajo la Licencia de Producción de Pares.

\url{https://endefensadelsl.org/ppl_deed_es.html}

\end{flushleft}
\newpage

\chapter*{Licencia de Producción de
Pares}\label{licencia-de-producciuxf3n-de-pares}

\section*{Ud. es libre de}\label{ud.-es-libre-de}

\begin{itemize}
\item
  Compartir - copiar, distribuir, ejecutar y comunicar públicamente la
  obra
\item
  Hacer obras derivadas
\end{itemize}

\section*{Bajo las condiciones
siguientes:}\label{bajo-las-condiciones-siguientes}

\begin{center}
  \begin{tabularx}{\textwidth}{c X}
    \raisebox{-\totalheight}{\includegraphics[height=3em]{images/by.png}} &

    \textbf{Atribución} -- Debe reconocer los créditos de la obra de la
    manera especificada por el autor o el licenciante (pero no de una
    manera que sugiera que tiene su apoyo o que apoyan el uso que hace
    de su obra). \\

    \raisebox{-\totalheight}{\includegraphics[height=3em]{images/sa.png}} &

    \textbf{Compartir bajo la Misma Licencia} -- Si altera o transforma
    esta obra, o genera una obra derivada, sólo puede distribuir la obra
    generada bajo una licencia idéntica a ésta. \\

    \raisebox{-\totalheight}{\includegraphics[height=3em]{images/nc.png}} &

    \textbf{No Capitalista} -- La explotación comercial de esta obra
    sólo está permitida a cooperativas, organizaciones y colectivos sin
    fines de lucro, a organizaciones de trabajadores autogestionados, y
    donde no existan relaciones de explotación. Todo excedente o
    plusvalía obtenidos por el ejercicio de los derechos concedidos por
    esta Licencia sobre la Obra deben ser distribuidos por y entre los
    trabajadores. \\

  \end{tabularx}
\end{center}

\newpage

\section*{Entendiendo que}\label{entendiendo-que}

\begin{itemize}
\item
  \textbf{Renuncia} - Alguna de estas condiciones puede no aplicarse si
  se obtiene el permiso del titular de los derechos de autor.
\item
  \textbf{Dominio Público} - Cuando la obra o alguno de sus elementos se
  halle en el dominio público según la ley vigente aplicable, esta
  situación no quedará afectada por la licencia.
\item
  \textbf{Otros derechos} - Los derechos siguientes no quedan afectados
  por la licencia de ninguna manera:

  \begin{itemize}
  \item
    Los derechos derivados de usos legítimos u otras limitaciones
    reconocidas por ley no se ven afectados por lo anterior;
  \item
    Los derechos morales del autor;
  \item
    Derechos que pueden ostentar otras personas sobre la propia obra o
    su uso, como por ejemplo derechos de imagen o de privacidad.
  \end{itemize}
\item
  \textbf{Aviso} - Al reutilizar o distribuir la obra, tiene que dejar
  muy en claro los términos de la licencia de esta obra. La mejor forma
  de hacerlo es enlazar a esta página.
\end{itemize}

{
\setcounter{tocdepth}{2}
\tableofcontents
}
\begin{quote}
Esta traducción y el artículo original se liberan bajo
\href{http://ur1.ca/2djpm}{Creative Commons Atribución
CompartirDerivadasIgual 3.0 de Argentina} y
\href{http://creativecommons.org/licenses/by-sa/3.0/us/legalcode}{Estados
Unidos} respectivamente. Traducido por fauno y mpj.
\end{quote}

Mucha publicidad se diseña para convencernos de comprar o usar algo que
no necesitamos. Cuando escucho a alguien zumbando sobre alguna cosa
nueva, maravillosa, me preocupo pensando que esos tipos están tratando
de venderme algo.

Muy pronto, es probable que vean una campaña de marketing para esta cosa
llamada Proyecto Harmony (que recientemente ha lanzado la versión 1.0 de
sus plantillas de documentos). Incluso el nombre es marketing: no es
realmente descriptivo, sino que trata de venderte una ``buena onda''
sobre el proyecto aun sin saber de qué se trata. (Además tuvo una
\href{http://www.projectharmony.com/}{seria}
\href{http://www.projectharmonynyc.org/}{colisión} de
\href{http://www.harmony-project.org/}{nombres},
\href{http://harmony.apache.org/}{incluso} con otro proyecto de software
libre.)

El Proyecto Harmony se vende a sí mismo como reparación de algo que
nuestra comunidad realmente no considera roto. El Proyecto Harmony es un
juego de plantillas de documentos, principalmente promulgadas y
diseñadas por abogados corporativos, que intentan seducir a los
desarrolladores a entregar el control de su trabajo a las compañías.

Mi análisis a continuación trata principalmente sobre cómo estos
acuerdos son problemáticos para los desarrolladores individuales. Un
análisis de los acuerdos a la luz de las compañías u organizaciones que
los usen entre sí puede o no tener las mismas conclusiones, pero no
puedo asegurarlo todavía.

{[} A propósito, soy conciente que he fallado en proveer una versión
TL;DR de este artículo. Intenté hacerlo dos veces y finalmente decidí
que no puedo. Estos problemas son complejos y tenía que tomar una década
de licenciamiento de software libre, políticas y conocimiento
organizacional para articular completamente qué es lo que está mal con
los acuerdos del Proyecto Harmony. Me doy cuenta de que suena a ``fue
difícil de escribir, debería ser difícil de leer'', pero no sé cómo
resumir estos problemas gordianos. No obstante espero que los
desarrolladores se tomen el tiempo de leer esto antes de firmar un
acuerdo del Proyecto Harmony, o, de hecho, cualquier CLA o ©AA. {]}

\hypertarget{una-cesiuxf3n-de-copyright-que-carece-de-garantuxedas-reales}{%
\section{Una cesión de copyright que carece de garantías
reales}\label{una-cesiuxf3n-de-copyright-que-carece-de-garantuxedas-reales}}

Antes que nada, casi la mitad del Proyecto Harmony se trata de acuerdos
de asignación de copyright (©AA por sus siglas en inglés). La asignación
de copyright cede completamente el trabajo a alguien más. Una vez que el
©AA está firmado, el trabajo deja de pertenecer al asignante. Es como si
el trabajo en realidad hubiera sido hecho por el asignado. Admitido, hay
algún valor en la asignación de copyright, particularmente cuando los
desarrolladores quieren asegurarse que la GPL u otra forma de copyleft
es debidamente protegida en su trabajo pero no tienen el tiempo de
hacerlo ellos mismos. (Aunque los desarrolladores también pueden
designar un agente de ejecución que lo haga en su nombre sin tener que
asignar el copyright, así que esa necesidad es limitada.)

Uno debe tener una confianza inmensa en la organización asignada.
Personalmente, yo sólo he asignado algunos de mis copyright a una sola
organización en toda mi vida: la \href{http://fsf.org}{Free Software
Foundation}, porque la FSF es la única organización que he encontrado
que está institucionalmente comprometida a hacer lo correcto con los
copyrights de forma similar a mis creencias morales personales.

En primer lugar,
\href{http://ebb.org/bkuhn/blog/2010/02/01/copyright-not-all-equal.html}{como
he escrito antes}, los ©AA de la FSF hacen toda suerte de promesas al
asignante. En segundo, la FSF está institucionalmente comprometida con
\href{http://www.gnu.org/licenses/gpl.html}{la GPL} y en hacer cumplir
la GPL de forma de avanzar la militancia sin fines de lucro de la FSF
por la libertad del software. Toda esta actividad está contenida en mis
principios morales, por lo que no he tenido problema en firmar los ©AA
de la FSF.

Aún así, he conocido \emph{muchos} desarrolladores que se niegan a
firmar los ©AA de la FSF. Mientras muchos de ellos aprueban la GPL, no
necesariamente acuerdan con las posiciones morales de la FSF. En efecto,
en muchos casos, estos desarrolladores se oponen completamente a asignar
el copyright a nadie, sea la FSF o cualquier otro. Por ejemplo,
\href{http://groups.google.com/group/fa.linux.kernel/msg/b0587ac4dcb7a79b}{Linus
Torvalds}, fundador de Linux, ha declarado repetidas veces que ``nunca
quis{[}o{]} hacer asignaciones de copyright, por varias razones:
personalmente piens{[}a{]} que son sucias y erróneas, odiaría hacer todo
el papeleo y piens{[}a{]} que actuaría como detractor del modelo de
desarrollo''.

Obviamente, mi posición no es tan radical como la de Linus; pienso que
los ©AA pueden ser apropiados en ciertas ocasiones. Pero también creo
que los desarrolladores nunca deberían asignar su copyright a una
compañía u organización cuya filosofía moral no cabe en la suya propia.

La FSF, por su parte, se expide sobre su posición moral en sus ©AA
mismos. Como
\href{http://ebb.org/bkuhn/blog/2010/02/01/copyright-not-all-equal.html}{mencioné
en otra parte}, y como
\href{http://www.groklaw.net/articlebasic.php?story=20110524120303815}{Groklaw}
recientemente cubrió en detalle, los ©AA de la FSF realizan varias
promesas con validez legal a los desarrolladores que las firman.
Mientras, los ©AA del Proyecto Harmony ponen unas pocas opciones que
parecen vagamente aceptables (aunque tienen problemas propios que
discuto más abajo), no las hacen obligatorias. Yo mismo he señalado en
varias ocasiones a los que escribieron los borradores de Harmony que
\href{http://www.fsf.org/blogs/rms/assigning-copyright}{los términos}
que la FSF ha propuesto deberían ser obligatorios en cualquier ©AA de
una compañía con fines de lucro, pero se han negado a incorporar estas
garantías como un requisito de sus acuerdos. (Noten que tales garantías
también deben incluirse en las opciones de los CLA; ver debajo para más
detalles.)

Por último me gustaría señalar que la FSF \textbf{no} requieren ©AAs
para todos los \href{http://www.gnu.org/help/evaluation.html}{paquetes
GNU}. Esta confusión es tan común que me gustaría llamar la atención
sobre ella, aunque sea un punto tangencial a este contexto. Los ©AA de
la FSF son obligatorios, según mi conocimiento, si los paquetes GNU
fueron (a) desarrollados por empleados de la FSF en sus primeras
versiones o (b) los desarrolladores originales le \emph{pidieron} a la
FSF que realice una asignación de copyright cuando su proyecto se unió a
GNU. En todos los demás casos, la asignación a la FSF es opcional.
Algunos proyectos GNU, como
\href{http://live.gnome.org/CopyrightAssignment}{GNOME}, tienen sus
propias posiciones sobre los ©AAs que difieren radicalmente de las de la
FSF. Dudo seriamente que las compañías que adopten los acuerdos del
Proyecto Harmony lleguen a ser tan flexibles en cuanto a la asignación
de copyright como lo es la FSF, o que alguna de las opciones posibles
que el Proyecto Harmony provea sean aceptables para la política actual
de GNOME.

\hypertarget{regalar-tus-derechos-para-que-las-compauxf1uxedas-sientan-mariposas-en-la-panza}{%
\section{¿Regalar tus derechos para que las compañías sientan mariposas
en la
panza?}\label{regalar-tus-derechos-para-que-las-compauxf1uxedas-sientan-mariposas-en-la-panza}}

El Proyecto Harmony, sin embargo, proclama que la parte importante no
son los ©AAs, sino los Acuerdos de Licencia del Contribuidor (CLA por
sus siglas en inglés). Para considerar brevemente la historia de los
CLAs de Software Libre, hay que notar que
\href{http://www.apache.org/licenses/icla.txt}{el CLA de Apache} fue
probablemente el primer CLA usado en la comunidad del Software Libre. La
Apache Software Foundation siempre ha estado fuertemente influenciada
por IBM y otras compañías, y tales compañías generalmente han sentido
``mariposas en la panza'' al lograr que cada contribuidor asienta a
firmar un documento legal complejo que afirma varias garantías respecto
al código y da ciertos poderes a la compañía.

El punto principal de un CLA (y hasta cierto punto válido) es asegurar
que los desarrolladores han verificado su derecho a contribuir código
bajo la licencia de copyright del proyecto. Tanto el CLA de Apache como
los CLA del Proyecto Harmony llegan a extremos de longitud y verborragia
para requerir que los desarrolladores acuerden que saben que la
contribución es suya. De hecho, si un desarrollador firma uno de estos
CLAs, realiza un contrato formal con la entidad (usualmente una compañía
con fines de lucro) en el que reconoce que la contribución se licencia
bajo la licencia del proyecto. ¡Y entonces el desarrollador asume toda
responsabilidad si ese hecho es incorrecto o se pone en disputa!

Por supuesto, mover toda la responsabilidad sobre los orígenes del
código produce muchas ``mariposas en la panza'' a los abogados de la
compañía. Esos abogados saben que ahora pueden fácilmente
\textbf{demandar a un desarrollador individual} por incumplimiento de
contrato si el desarrollador se equivocó en el código. Si la compañía
distribuye el código de un desarrollador y termina recibiendo una
demanda por infracción por la que paga millones de dólares, pueden
fácilmente darse vuelta y demandar al desarrollador.\footnote{Los
  defensores del Proyecto Harmony reclamarán que su sección 5,
  ``Renuncia consecuencial de daño'', protege adecuadamente a los
  desarrolladores. Noto que deja afuera explícitamente a, por ejemplo,
  los daños estatutarios de la infracción de copyright. Además, no puede
  renunciarse a algunos tipos de daños (y es por eso que esa sección le
  grita al lector ``EN LA MEDIDA EN QUE LA LEY LO PERMITA''). Noten mi
  discusión sobre las jurisdicciones en el texto principal de este
  artículo, y consideren el hecho que el receptor de un CLA obviamente
  seleccionará la jurisdicción donde se pueda renunciar a la menor
  cantidad de daños. Finalmente, noten que la parte ``O NOSOTROS'' de
  esa sección 5 está disponible opcionalmente, y seguramente los
  abogados corporativos la usarán, lo que significa que si ellos violan
  el acuerdo, básicamente no tenés forma de recibir alguna renuncia de
  daño de parte de ellos, aun si prometieron mantener el código bajo
  copyleft.} La compañía argumentará en la corte que el desarrollador
rompió el contrato. Si este desenlace posible no te preocupa
\emph{inmediatamente} en tanto desarrollador individual cuando firmás un
CLA del Proyecto Harmony por tu contribución libre, debería.

\hypertarget{la-elecciuxf3n-de-ley-y-los-arreglos-contractuales-embarran-los-reclamos-de-copyright}{%
\section{La ``Elección de Ley'' y los Arreglos Contractuales embarran
los reclamos de
copyright}\label{la-elecciuxf3n-de-ley-y-los-arreglos-contractuales-embarran-los-reclamos-de-copyright}}

El CLA de Apache no posee una cláusula de elección de ley, lo que es
preferible en mi opinión. La mayoría de los abogados \emph{aman} una
cláusula de ``elección de ley'' (``choice of law'' en inglés) por varias
razones. La más grande es que significa que las reglas que se aplican
sobre el acuerdo son las más familiares a los abogados y la jurisdicción
para las disputas será la jurisdicción local de la compañía, no la del
desarrollador. Adicionalmente, los abogados a menudo eligen
jurisdicciones particulares que son muy favorables a su cliente pero no
lo son para los otros firmantes.

Desafortunadamente, \emph{todos} los borradores del Proyecto Harmony
incluyen una cláusula de ``elección de ley''.\footnote{\emph{Nota:}
  Versiones tempranas de este artículo mezclaron ``elección de sede''
  con ``elección de ley''. El fraseo ha sido aclarado para solucionar
  este problema. Por favor envíenme comentarios o correo si creen que no
  ha sido corregido adecuadamente.} Espero que los que escriben los
borradores argumentarán en respuesta que la jurisdicción es una variable
de configuración. No obstante, el problema es que la \emph{compañía} es
la que decide el valor de esa variable, que casi siempre será la que no
prefiera el desarrollador individual. Probablemente el término no sea
negociable en ese punto, aunque haya podido configurarse en la
plantilla.

Y no sólo eso, imaginá un escenario mucho más probable para ese CLA: la
compañía falla en usar la licencia saliente que prometieron. Por
ejemplo, supongan que prometieron a los desarrolladores que sería AGPL
para siempre (¡aunque ninguna opción como esta existe en el Proyecto
Harmony, vean más abajo!), pero entonces la compañía lanza versiones
propietarias. Los desarrolladores que firmaron el CLA todavía detentan
copyright, por lo que pueden ejercer sus derechos bajo la ley de
copyright que, por sí misma, puede lograr que los desarrolladores hagan
cumplir la licencia bajo la ley en cualquier jurisdicción que les
parezca (asumiendo que la infracción sucede en esa, por supuesto).

Sin embargo, al firmar un CLA con la clásula de ``elección de ley'', los
desarrolladores acordaron mantenerse bajo la jurisdicción establecida en
el CLA. El CLA convierte lo que de otra forma hubiera sido una demanda
de infracción de copyright mundana operando solamente bajo la
reglamentación de copyright local al desarrollador en una disputa
contractual entre los desarrolladores y la compañía bajo las leyes de la
jurisdicción elegida. Obviamente ese acuerdo incluiría la AGPL y/o GPL
por referencia, pero el reclamo por infracción de copyright hecho por
violación de la GPL está ahora embarrado por el contrato CLA que los
desarrolladores firmaron, y donde cedieron algunos derechos y permisos a
la compañía que van más allá de la GPL.

Aún peor, si el desarrollador realiza la demanda en su propia
jurisdicción, esa jurisdicción se ve forzada a interpretar las leyes de
otro lugar. Esto lleva a resultados altamente variables y confusos.

\hypertarget{problemas-para-hacer-cumplir-el-copyright-individualmente-contra-terceras-partes}{%
\section{Problemas para hacer cumplir el copyright individualmente
contra terceras
partes}\label{problemas-para-hacer-cumplir-el-copyright-individualmente-contra-terceras-partes}}

Además, aún cuando los desarrolladores individuales retienen sus
copyrights, los CLAs del Proyecto Harmony garantizan muchos derechos y
permisos transferibles al receptor del CLA (otra vez, usualmente a una
compañía). Aún \emph{si} las razones para requerirlos fuesen nobles,
introducen un manojo de permisos extra que pueden ser pasados a otras
entidades.

De repente, lo que una vez fuera una simple demanda para hacer cumplir
el copyright hecha por un desarrollador que descubre una violación del
copyleft se convierte en una pregunta: ``¿Recibió de alguna manera esa
entidad violatoria permisos especiales de esta otra entidad colectora
del CLA?'' Los violadores van a moverse rápidamente a este tipo de
defensa. Aunque la defensa pueda no tener mérito (por ejemplo, el
receptor del CLA ni siquiera conoce al violador), introduce confusión.
La mayoría de los procedimientos legales que involucran software ya son
suficientemente confusos para las cortes debido a la compleja tecnología
involucrada. Agregar algo como esto sólo causará problemas y demoras,
agregando más peso a nuestros mínimamente financiados esfuerzos por
hacer cumplir el copyleft de la comunidad.

\includegraphics{images/harmony.png}

\hypertarget{entrantesaliente-es-todo-lo-que-necesituxe1s}{%
\section{Entrante=Saliente es todo lo que
necesitás}\label{entrantesaliente-es-todo-lo-que-necesituxe1s}}

Mientras tanto, la pregunta sobre el CLA es esta única consideración
fundamental: ¿Necesitamos esto? La respuesta del Proyecto Harmony es
clara: sus defensores claman que existe una confusión masiva sobre los
CLAs y ninguna estandarización, por lo que el Proyecto Harmony debe
proveer un set estándar de acuerdos que encarnen todas las opciones
usadas típicamente.

Aun más, el Proyecto Harmony ha rechazado a propósito ofrecer la opción
más simple y popular de todas, que mi colega Richard Fontana (un abogado
de Red Hat que
\href{http://opensource.com/law/11/7/trouble-harmony-part-1}{también se
opone} al Proyecto Harmony)
\href{http://identi.ca/conversation/45589896}{ha llamado}
\href{http://ref.fedorapeople.org/fontana-linuxcon.html}{el año pasado
``entrante=saliente''}. Específicamente, el acuerdo por defecto en la
abrumadora mayoría de los proyectos FLOSS es simplemente esta: cada
contribuidor acuerda licenciar cada contribución bajo la licencia de
copyright específica del proyecto (o una licencia compatible).

No importa de qué lado mires al Proyecto Harmony, los otros problemas
contractuales descritos arriba vuelven imposible un verdadero
entrante=saliente porque el receptor del CLA nunca está legalmente
obligado por la licencia del proyecto. Mientras tanto, y aún bajo su
mejor configuración, el Proyecto Harmony no puede aproximarse
adecuadamente a entrante=saliente. Específicamente, el Proyecto Harmony
intenta limitar el licenciamiento de saliente en su sección 2.3 (llamada
``Licencia saliente''). Sin embargo, todas las versiones copyleft de
esta plantilla incluyen una cláusula que dice: ``Nosotros {[}los
receptores del CLA{]} acordamos licenciar la Contribución {[}\ldots{}{]}
bajo los términos de las {[}\ldots{}{]} licencias que Nosotros estemos
utilizando a la Fecha de Envío del Material''. Pero \emph{no hay forma}
de que el contribuyente verifique con seguridad cuáles licencias usa en
privado la entidad que recibe el CLA. Si esa entidad ya tiene un modelo
de negocio de
\href{http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html}{relicenciamiento
propietario} a la Fecha de Envío, entonces el contribuyente concede su
permiso para tal relicenciamiento en esa contribución nueva, aún si el
resto de la sección 2.3 le promete copyleft. Esto no es hipotético: ha
habido muchos casos donde no está claro si la compañía estaba o no
estaba involucrada en relicenciamiento propietario, para más tarde
descubrir que lo habían estado haciendo en privado durante años. Tal
como está escrita, por lo tanto, \textbf{cualquier configuración de la
sección 2.3 del Proyecto Harmony es inútil para prevenir la apropiación
propietaria}.

Aunque ese bug sea arreglado, lo más cercano que el Proyecto Harmony va
a estar de entrante=saliente es restringiendo sus CLA a ``la lista de la
FSF de licencias copyleft recomendadas''. Sin embargo, esta categoría no
hace ninguna distinción entre la
\href{http://www.gnu.org/licenses/agpl.html}{AGPL} y la GPL, y en última
instancia le permite a la FSF el poder de relicenciar (ya que la FSF
\href{http://www.gnu.org/licenses/recommended-copylefts.html}{puede
cambiar} su lista de copyleft recomendadas a voluntad). Si los
contribuyentes son serios sobre la AGPL, entonces el Proyecto Harmony
\textbf{no} puede asegurar que sus cambios permanezcan bajo esta
licencia. Aún más, los contribuyentes \emph{deben} confiar en la FSF a
perpetuidad, aún \emph{más de lo que actualmente necesitan} en las
opciones ``\ldots{} o subsiguientes'' de las licencias de la FSF en
existencia. Estoy de acuerdo en confiar en la FSF en la mayoría de los
casos. Sin embargo, ya que prefiero sólo AGPLv3 o subsiguientes para mi
código, el Proyecto Harmony es completamente incapaz de acomodarse a mis
preferencias y aproximarse a un entrante=saliente que sea AGPL (aún si
ignoro los numerosos problemas ya discutidos).

Mientras tanto, la normal, mundana y extendida práctica
entrante=saliente es simple, efectiva y no mezcla sus complicadas
disputas contractuales y estructuras de control con la gobernanza del
proyecto. En esencia, para la mayoría de los proyectos FLOSS, la
licencia de copyright del proyecto sirve como su Constitución y no le
mezcla ninguna otra complicación. El Proyecto Harmony busca darle
maripositas a los abogados a expensas de tirarles el fardo legal y
molesto a los desarrolladores.

\hypertarget{los-hackers-de-linux-han-fijado-ingeniosamente-entrantesaliente}{%
\section{Los Hackers de Linux han fijado ingeniosamente
entrante=saliente}\label{los-hackers-de-linux-han-fijado-ingeniosamente-entrantesaliente}}

Hace casi 10 años atrás, recuerdo haber asistido a un sesión del
\href{http://www.usenix.org/event/usenix01/bofschedule.html}{USENIX 2001
Linux BoF}. En esa sesión, \href{http://thunk.org/tytso}{Ted T'so} y yo
tuvimos un acalorado debate; yo afirmé que el ©AA de la FSF aseguraba
certeza legal sobre el código GNU, pero que Linux no poseía tal seguro.
(Por cierto, incluso \emph{yo} estaba confundido en esos días y pensaba
que todos los paquetes de GNU requerían un ©AA de la FSF.) Ted explicó,
en la manera clara y brillante habitual, que tales métodos duros no eran
necesarios para darle certeza legal a la GPL y que la comunidad de Linux
quería encontrar una alternativa.

Me fui sacudiendo la cabeza escépticamente. Recuerdo haber pensado:
``Ted no entiende''. Pero estaba equivocado; él \emph{sí} entendía. De
hecho, muchos de los desarrolladores clave de Linux lo hacían. Tres años
después de esa conversación pública con Ted, el
\href{http://permalink.gmane.org/gmane.linux.kernel.commits.head/33254}{Certificado
de Origen del Desarrollador} (DCO por sus siglas en inglés) se convirtió
en la forma oficial de manejar el ``problema de los CLA'' en Linux y
sigue siendo
\href{http://www.kernel.org/doc/Documentation/SubmittingPatches}{la
política oficial} al día de hoy. (Ver el item 12 en el archivo
Documentation/SubmittingPatches de Linux.)

El DCO, en efecto, ¡es el único CLA que necesita cualquier proyecto
FLOSS! Implementa entrante=saliente en una forma simple y directa, sin
darle poderes especiales a ninguna compañía o entidad en particular. Los
desarrolladores mantienen su propio copyright y unilateralmente
atestiguan su derecho a contribuir y la licencia de su contribución.
(Además pueden firmar un ©AA con alguna otra entidad, como la FSF, si
quieren.) El DCO también provee una metodología simple (es decir, la
etiqueta Signed-off-by:) para realizar ese atestiguamiento.

Debo admitir que me he burlado de la simplicidad (que consideraba naïve)
del DCO en comparación al ©AA de la FSF. Desde entonces me he convencido
que el DCO de Linux cumple claramente con su trabajo principal a la vez
que se ajusta a la forma de trabajo preferida por muchos
desarrolladores. Los ©AA tienen su lugar, particularmente cuando los
desarrolladores encuentran una organización confiable que se alinea con
su código moral personal y se encargarán de defender el copyleft por
ellos. No obstante, para los CLAs, el DCO de Linux cumple con este
importante trabajo y deja de lado el costado pro-corporativo inútil.

Francamente, si tengo que elegir entre hacer las cosas fáciles para los
desarrolladores o hacerlas fáciles para los abogados corporativos, voy a
elegir lo primero en todos los casos: los desarrolladores escriben el
código; mientras que la mayor parte del tiempo, los departamentos
legales de una compañía sólo se meten en el medio. La comunidad de FLOSS
necesita cubrirse el culo lo suficiente como para zafar; el DCO muestra
lo que es realmente \emph{necesario}, en oposición a lo que los abogados
corporativos \emph{desean} que hagan sus desarrolladores.

\hypertarget{quuxe9-pasa-con-el-relicenciamiento}{%
\section{¿Qué pasa con el
relicenciamiento?}\label{quuxe9-pasa-con-el-relicenciamiento}}

El DCO de Linux no permite que una sola entidad relicencie el código;
esta es la razón por la que el cambio a GPLv3 en Linux será una ardua
tarea de procesos públicos por conseguir el permiso para el cambio. Sin
embargo, hay que notar que la cultura linuxera \emph{cree} que la GPLv2
es el fundamento moral y el principio de su comunidad. No es un
principio con el que concuerdo; la mayoría de mis lectores saben que mi
\href{http://ebb.org/bkuhn/blog/2011/05/26/choose.html}{licencia
preferida} es la AGPLv3 o superior. Pero este es el punto:
entrante=saliente es \emph{la} forma en que una comunidad FLOSS
implementa su moralidad; el Proyecto Harmony busca remover las
decisiones comunitarias sobre el licenciamiento de casi todos los
proyectos.

Estoy a favor de permitir el relicenciamiento ``o superior''; la GPL, la
LGPL y la AGPL han dejado la opción a la comunidad ya que la
\href{http://www.gnu.org/licenses/gpl-1.0.txt}{GPLv1} fue publicada a
finales de los '80. Los proyectos se declaran ``GPLv2 o superior'' o
``LGPL o superior'', o incluso
\href{http://dev.perl.org/licenses/}{``GPLv1 o superior o Artística''}
(como Perl 5) para identificar su cultura y permisos de
relicenciamiento. Aunque a veces sería bueno tener una autoridad en
relicenciamiento, el precio es muy caro: el abandono de una claridad
comunitaria con respecto a los términos en que se define su cultura de
desarrollo.

\hypertarget{una-parcialidad-anti-copyleft-fuerte}{%
\section{¿Una parcialidad anti copyleft
fuerte?}\label{una-parcialidad-anti-copyleft-fuerte}}

Lo que es aun peor, es que el Proyecto Harmony se mantiene parcial
contra algunas de las más afinadas versiones de la cultura copyleft. Por
ejemplo,
\href{http://ebb.org/bkuhn/blog/2011/06/26/identica-weekly.html}{Allison
Randal}, quien está muy involucrada en el Proyecto Harmony, argumentó en
el \href{http://linuxoutlaws.com/podcast/ogg/204}{episodio 204} de Linux
Outlaws que ``la mayoría de los desarrolladores que contribuyen bajo una
licencia copyleft, estarían contentos de hacerlo bajo cualquier otra,
sea AGPL, GPL o LGPL''. Sin embargo existen varias
\href{http://www.gnu.org/philosophy/why-not-lgpl.html}{razones bien
definidas} de por qué los desarrolladores eligirían la GPL antes que la
LGPL. Por eso, entregarle a una compañía con fines de lucro (o una sin
fines de lucro que no necesariamente comparta los valores de los
desarrolladores) el poder unilateral de tomar decisiones de
relicenciamiento y convertir un proyecto bajo GPL en LGPL o cualquier
otra licencia de copyleft débil es ridículo.

En su lanzamiento 1.0, el Proyecto Harmony intentó agregar una opción de
``sólo copyleft fuerte''. Por supuesto que no funciona, por las razones
discutidas más arriba. Pero aun así, esta solución es sólo una de las
muchas y no es requerida por defecto cuando un proyecto ya es copyleft.

Por último, es importante notar que las
\href{http://www.gnu.org/licenses/gpl.html\#section14}{GPLv3, AGPLv3 y
LGPLv3} ya ofrecen una ``opción de apoderado (proxy)''; los proyectos
pueden nombrar a alguien para decidir cambiar a ``o superior'' más
tarde. Por eso, para aquellos proyectos que estén usando cualquiera del
grupo ``sólo LGPLv3'', ``sólo AGPLv3'', ``sólo GPLv3'', ``GPLv2 o
superior'', ``GPLv1 o superior'' o ``LGPLv2.1 o superior'', sus
desarrolladores \emph{ya poseen} mecanismos para moverse a versiones
superiores de la licencia con facilidad al especificar un apoderado. No
hay necesidad de un CLA para cumplir tal tarea en la familia de
licencias GPL, a menos que el objetivo sea erosionar los copylefts
fuertes para convertirlos en copylefts débiles.

\hypertarget{esto-no-es-creative-commons-pero-si-lo-fuera-vale-la-pena-emularlo}{%
\section{Esto no es Creative Commons, pero si lo fuera, ¿vale la pena
emularlo?}\label{esto-no-es-creative-commons-pero-si-lo-fuera-vale-la-pena-emularlo}}

Los defensores del Proyecto Harmony aman compararlo con
\href{http://creativecommons.org/}{Creative Commons}, pero la
comparación no es particularmente apta. Aún más, no estoy convencido de
la que la comunidad FLOSS deba emular al grupo de licencias de CC del
todo, ya que algunos aspectos de la estructura de CC son problemáticos
al migrarlos al licenciamiento FLOSS.

En primer lugar,
\href{http://en.wikipedia.org/wiki/Lawrence_Lessig}{Larry Lessig} (quien
es ampliamente considerado como un visionario) inició el licenciamiento
CC para capturar un movimiento por la Cultura Libre que se estaba
moldeando a semejanza del movimiento del Software Libre (la cual pasó
una década estudiando). Sin embargo, Lessig realizó varios compromisos
morales en su intento de construir un puente a la mentalidad ``algunos
derechos reservados''. Así, muchas de las licencias CC -notablemente las
que incluyen las cláusulas NoComercial (NC) o SinDerivadas (ND)- son
consideradas demasiado restrictivas y son por lo tanto rechazadas tanto
por \href{http://blog.ninapaley.com/2011/07/04/rantifesto/}{activistas
de la Cultura Libre} como por
\href{http://en.wikipedia.org/wiki/Creative_Commons\#Other_criticism_of_the_non-commercial_license}{militantes
del Software Libre}.

Después de una década, esos militantes empezaron lentamente a convencer
a los titulares de copyright de evitar las opciones NC y ND de CC, pero
la promulgación continua de estas opciones por parte de CC deslegitiman
esos intentos. Así, CC y el Proyecto Harmony cometen el mismo error:
actúan amoralmente en su intento de construir una estructura de
licencias/acuerdos que trata de aunar entendimiento entre una comunidad
FaiF (``libre como en libertad'', en inglés ``Free as in Freedom'') y
aquellos que recién están comenzando a conocerla. Elegí la palabra
amoral, como
\href{http://ebb.org/bkuhn/blog/2010/06/23/open-source.html\#footnote-amoral-word-choice}{usualmente
hago}, para denotar una situación donde existen importantes principios
morales, pero sus actores principales buscan remover la moralidad de
consideración con la excusa de dejar el poder de decisión ``a la magia
del mercado''. El Proyecto Harmony repite el error de las licencias CC
que la comunidad de la Cultura Libre ha pasado una década (y contando)
de limpiar.

\hypertarget{conclusiones}{%
\section{Conclusiones}\label{conclusiones}}

Por favor noten que no soy un abogado y que esto no es un aviso legal.
Sólo soy un desarrollador tanto individual como comunitario enfocado en
políticas de software libre que tiene serias preocupaciones por la forma
en que operan los acuerdos del Proyecto Harmony. No puedo proveer un
análisis legal refinado, porque francamente soy un amateur cuando se
trata de leyes, pero \emph{soy} un experto en políticas de libertad del
software. En esa vena -sin tener en cuenta el apoyo de los abogados
corporativos- mi opinión es que el Proyecto Harmony debe abandonarse por
completo.

De hecho, la distinción entre experticia política y legal muestra la
raíz del problema del Proyecto Harmony. Es un sistema de documentos
diseñados por un comité compuesto principalmente por abogados
corporativos, aun cuando se muestra como un consenso de desarrolladores
FLOSS. En efecto, el Proyecto Harmony fue iniciado por
\href{http://www.linkedin.com/pub/dir/Amanda/Brock}{Amanda Brock}, una
abogada corporativa con fines de lucro de Canonical, Ltd, que aun
trabaja en los borradores. Más tarde,
\href{http://identi.ca/notice/74444380}{Canonical, Ltd.} contrató a Mark
Radcliffe (un abogado que
\href{http://www.archive.org/download/gov.uscourts.nysd.327540/gov.uscourts.nysd.327540.3.0.pdf}{ha
defendido}
\href{http://sec.gov/Archives/edgar/data/1375365/000119312509084731/filename1.htm}{violadores
de la GPL}) para escribir el borrador de las versiones alpha del
documento, y aun continúa haciéndolo. Aún más, el proceso primario de
escritura de esos borradores se hizo en secreto en reuniones cerradas
dominadas por abogados corporativos hasta que los documentos estuvieron
casi completos; el proceso no se hizo público a la comunidad hasta abril
del 2011. La versión 1.0 de los documentos poco difiere de los
borradores que se lanzaron en abril, y por lo tanto se mantienen como
documentos que fueron principalmente redactados en secreto por abogados
corporativos que sólo tienen una lejana familiaridad con la cultura del
software libre.

\href{http://identi.ca/conversation/74175630\#notice-76902928}{He
preguntado} muchas veces a los defensores del Proyecto Harmony quién
está a cargo del mismo hoy, y nadie puede darme una respuesta directa.
Uno se pregunta quién toma las decisiones finales y cuál es el proceso
que existe para incluir o excluir texto en los borradores. El proceso
que una vez fue secreto ahora parece ser caótico porque fue abierto
mucho más tarde de lo necesario para resolver sus problemas
fundamentales.

Sólo unos pocos desarrolladores están involucrados en el proyecto. Pero
el Proyecto Harmony no es algo que los desarrolladores hayan pedido; fue
iniciado por compañías que \emph{quisieran} convencerlos de adoptar
pasivamente estos extralimitados CLAs y ©AAs. Para mí, el proceso
completo del Proyecto Harmony se siente como una guerra de desgaste para
convencer a los desarrolladores de aceptar algo que no necesariamente
quieren con un mínimo de disenso. En definitiva, la necesidad del
Proyecto Harmony no se ha articulado para los desarrolladores.

Por último, pregunto, ¿qué es lo que está realmente roto? La industria
ha estado adoptando GNU y Linux durante años de manera continua. GNU,
por su parte, tiene las asignaciones de la FSF para muchos de sus
proyectos tempranos, pero los últimos proyectos
(\href{http://live.gnome.org/CopyrightAssignment/Guidelines}{GNOME} en
particular) han sido absolutamente contrarios tanto al uso de ©AAs como
de CLAs, o se han mostrado indiferentes y han usado entrante=saliente.
Linux, por su lado, usa el DCO, que realiza el trabajo de manejar las
partes más urgentes e importantes de un CLA sin ponerse en el camino de
los desarrolladores y sin forzarles riesgos legales extra y entregarle
las decisiones de licenciamiento (incluyendo las debilitantes del
copyleft) a una única entidad (usualmente con fines de lucro).

En definitiva, el Proyecto Harmony es una solución mal diseñada buscando
un problema.

\hypertarget{vuxe9ase-tambiuxe9n-en-ingluxe9s}{%
\section{Véase también (en
inglés)}\label{vuxe9ase-tambiuxe9n-en-ingluxe9s}}

\begin{itemize}
\item
  \href{http://opensource.com/law/11/7/trouble-harmony-part-1}{El
  problema con Harmony, Parte I} de Richard Fontana
\item
  \href{http://blogs.gnome.org/bolsh/2011/07/06/harmony-agreements-reach-1-0/}{Los
  acuerdos Harmony 1.0} de Dave Neary
\item
  \href{http://people.gnome.org/~michael/blog/copyright-assignment.html}{Algunos
  pensamientos sobre la asignación de copyright} de Michael Meek
\item
  \href{http://blogs.gnome.org/bolsh/2009/04/08/copyright-assignment-and-other-barriers-to-entry/}{La
  asignación de copyright y otras barreras para ingresar} de Dave Neary
\item
  \href{http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html}{El
  relicenciamiento propietario es el nuevo shareware} por mí mismo
\item
  \href{http://www.fsf.org/blogs/rms/assigning-copyright/}{Cuando una
  compañía te pide tu copyright} de RMS
\item
  \href{http://www.fsf.org/blogs/licensing/project-harmony}{La FSF y el
  Proyecto Harmony} de Brett Smith
\item
  \href{http://identi.ca/conversation/60847947}{Hay}
  \href{http://identi.ca/conversation/60848873}{varios}
  \href{http://identi.ca/conversation/61240820}{hilos}
  \href{http://identi.ca/conversation/68596018}{diferentes}
  \href{http://identi.ca/conversation/68858735}{que}
  \href{http://identi.ca/conversation/68886640}{pueden}
  \href{http://identi.ca/conversation/68887235}{encontrarse}
  \href{http://identi.ca/conversation/69308469}{en}
  \href{http://identi.ca/conversation/70389379}{identi.ca}
  \href{http://identi.ca/conversation/70648339}{donde}
  \href{http://identi.ca/conversation/71854529}{se}
  \href{http://identi.ca/conversation/72024908}{discuten}
  \href{http://identi.ca/conversation/73129548}{los}
  \href{http://identi.ca/conversation/73225057}{acuerdos}
  \href{http://identi.ca/conversation/73225057}{del}
  \href{http://identi.ca/conversation/74175630}{Proyecto}
  \href{http://identi.ca/conversation/74979814}{Harmony}. El hashtag
  \href{http://identi.ca/tag/harmony}{``\#Harmony''} se usa a menudo. El
  hashtag \href{http://identi.ca/tag/cla}{``\#CLA''} también puede ser
  de interés.
\item
  \href{http://www.linuxuser.co.uk/news/the-issue-of-bringing-harmony-to-copyright-assignment/}{El
  problema de traer armonía a la asignación de copyright} de Jos
  Poortvliet
\item
  \href{http://opensource.com/life/11/4/balancing-transparency-and-privacy}{Balanceando
  transparencia y privacidad} de Simon Phipp
\item
  \href{http://live.gnome.org/CopyrightAssignment}{Política de
  asignación de copyright de GNOME}
\item
  \href{http://live.gnome.org/CopyrightAssignment/Guidelines}{Los
  lineamientos de la Fundación GNOME sobre la asignación de copyright}
\item
  \href{http://opensource.com/law/10/6/project-harmony-looks-improve-contribution-agreements-0}{El
  Proyecto Harmony busca mejorar los acuerdos de contribución} de Amanda
  Brock
\item
  \href{http://lists.harmonyagreements.org/mailman/listinfo}{Los
  archivos de la lista de correo del Proyecto Harmony}
\item
  \href{http://harmonyagreements.org/agreements.html}{Los borradores de
  los Acuerdos Harmony}
\item
  \href{http://ref.fedorapeople.org/fontana-linuxcon.html}{Políticas de
  contribución de proyectos de código abierto} diapositivas de la charla
  de Richard Fontana.
\end{itemize}

\end{document}
