Ver código fuente

== Copyright como derecho de explotación ==

El copyright y la [http://nosolosoftware.com/wiki/Eligiendo_licencia_para_el_código licencia de un programa] son cosas distintas. La '''licencia''' es el mecanismo legal mediante el que el autor declara qué derechos sobre el programa proporciona al usuario. Sin embargo, el '''copyright''' es el mecanismo legal mediante el cual se indica a quien pertenecen los derechos de explotación del código.

Las principales implicaciones de tener o no el copyright son:

* Decidir sobre los cambios/asignación de la licencia.
* Mantener los derechos de explotación del software. Es decir, las posibles ganancias por la venta de licencias del programa repercutirán sobre los agentes que mantengan el copyright.

 A efectos legales, se puede decir que mantener el copyright del código significa ser el propietario del mismo.

Existen proyectos y comunidades de software libre, que a la hora de participar, exigen a sus colaboradores que se les ceda el copyright. Éste es el caso, por ejemplo, del proyecto Apache, de la Free Software Foundation y de MySQL.

== Implicaciones legales: la Fundación Apache y la FSF==

 Desde el punto de vista legal, que el copyright sea de un único agente simplifica el proceso de relicenciamentos futuros,
 facilitando asimismo afrontar procesos legales, ya que grandes instituciones pueden tener más recursos económicos.

Éste es el caso de la Apache Foundation y la Free Software Foundation, que exigen a sus colaboradores que les ceda el copyright antes de aceptar sus aportaciones. Según el [http://www.apache.org/licenses/#clas Contributor License Agreement] de la Apache Software Foundation:

: The purpose of this agreement is to clearly define the terms under which intellectual property has been contributed to the ASF and thereby allow us to defend the project should there be a legal dispute regarding the software at some future time.

así como la [http://www.gnu.org/licenses/why-assign.html Free Software Foundation]:

: In order to make sure that all of our copyrights can meet the recordkeeping and other requirements of registration, and in order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment

=== Lecciones aprendidas: Mozilla y KDE ===

A diferencia de las anteriores entidades, Mozilla y KDE no pedían cederles el copyright para contribuir. Cuando ambos proyectos tuvieron que enfrentarse a procesos de [http://nosolosoftware.com/wiki/Eligiendo_licencia_para_el_c%C3%B3digo#Relicenciamiento relicenciamiento] sufrieron las consecuencias de que el copyright estuviese distribuido entre todos los colaboradores.

La complejidad de este proceso radica en que para hacer el cambio de licencia es necesario que todos y cada uno de los detentores del copyright estén de acuerdo, y no siempre es fácil encontrar a alguien que ha colaborado con el proyecto años atrás y ahora no está de ningún modo involucrado. En esos casos la única solución es escribir esa parte del programa desde cero.

* [http://www-archive.mozilla.org/MPL/relicensing-faq.html Proceso de relicenciamiento de Mozilla]
* [http://techbase.kde.org/Projects/KDE_Relicensing Proceso de relicenciamiento de KDE]

== Implicaciones económicas: el caso MySQL ==

 Desde el punto de vista económico, se puede decir que la cesión del copyright sustenta una de las formas en que una compañía puede ganar dinero 
 con software libre: el [http://nosolosoftware.com/wiki/Eligiendo_licencia_para_el_c%C3%B3digo#Licenciamiento_dual licenciamento dual].

El ejemplo más conocido -aunque no el primero- de este modelo fue quizás la empresa MySQL AB. MySQL AB era una empresa finlandesa que desarrollaba la base de datos MySQL. Esta base de datos tiene la licencia GPL, es decir, se puede usar y modificar libremente, pero no se pueden realizar productos cerrados a partir del código GPL. Pero MySQL AB entendía que existían ciertos agentes que deseaban realizar productos propietarios a partir de su base de datos. Es por ello, que además de licenciarla con la GPL, también lo hacían con la [http://www.mysql.com/about/legal/licensing/oem/ MySQL Comercial License].

[http://forge.mysql.com/wiki/ContributingFAQ Tal y como lo explicaban desde MySQL]:

: MySQL is the owner and copyright holder of the entire MySQL product, whereas Linux does not have one single entity as a copyright holder. This makes the MySQL Dual Licensing model possible.

:The MySQL users benefit from this in the form of further product development financed by MySQL (with currently over 80 developers on MySQL’s payroll). While MySQL has developed most of the MySQL database itself, and continues to do so, MySQL also wants to simplify the processes for contributors to MySQL.

El licenciamento dual de MySQL no sería posible (o sería muy complejo de implementar) si [http://forge.mysql.com/wiki/ComContribution_Process los participantes de la comunidad no cediesen su copyright a la empresa].

== Implicaciones sociales: el caso GNOME y KDE ==

 Que el copyright pertenezca a autores individuales, a una Fundación (organización sin ánimo de lucro) o a una empresa
 puede variar también el índice de participación de los distintos agentes.

Esto se puede comprobar estudiando el copyright de los proyectos [http://www.gnome.org GNOME] y [http:www.kde.org KDE] (los dos principales escritorios en software libre), podemos observar distintos patrones de participación en las 2 comunidades.

En la siguiente figura se muestra el porcentaje de líneas de código asociadas a cada tipo de participante: desarrollador particular, universidad, empresa, fundación o grupo de desarrollo.

[[Imagen:copyright_GNOME_VS_KDE.png|thumb|center|Copyrigh: GNOME VS KDE]]

La diferencia más reseñable entre ambos proyectos es que:

:el porcentaje de código debido a las empresas es 3 veces mayor en GNOME que en KDE

Esto puede ser debido a que las librerías principales de KDE ([http://qt.nokia.com/ Qt]) tenían el copyright de la empresa Trolltech (comprada por Nokia), mientras que las de GNOME ([http://www.gtk.org/ GTK]) tienen el copyright de la [http://foundation.gnome.org/ Fundación GNOME] y de los desarrolladores individuales. Esta característica puede ser la razón principal de la reticencia de participación de otras empresas en el proyecto KDE.