Licencia de software libre

De Wikipedia, la enciclopedia libre
Ir a la navegación Ir a la búsqueda

Una licencia de software libre es un impreso que otorga al receptor de una pieza de software derechos extensivos para modificar y redistribuir ese software. Estas acciones normalmente se prohíben por las leyes de derechos de autor, pero el que posee los derechos, normalmente el autor de un trozo de software, puede eliminar esas restricciones acompañando al software con una licencia de software que otorgue al receptor de estos derechos. El software que usa tales licencias se denomina software libre y esas libertades las concede el propietario del copyright. Las licencias de software libre se aplican tanto a el software en forma de código fuente o en código objeto binario, ya que las leyes de derechos de autor reconocen ambas formas.[1]

Algunas licencias de software libre incluyen copyleft y esto requiere que todas las versiones futuras sean también distribuidas con estas libertades. Otras licencias de software "permisivas" son normalmente unas pocas líneas conteniendo la cesión de derechos y una garantía de renuncia, esto también permitiendo a los distribuidores añadir restricciones para receptores futuros.

Mientras que históricamente la licencia FOSS más ampliamente usada ha sido la GPL versión 2, en 2015 y de acuerdo con Black Duck Software[2]​ y las estadísticas de GitHub,[3]​ la licencia permisiva Licencia MIT destronó a la GPLv2 al segundo lugar mientras que la licencia permisiva Apache sigue todavía en tercer lugar.

Historia[editar]

Las licencias de software libre antes de 1980 fueron generalmente estatutos informales escritos por los propios desarrolladores. En esa época de compartir el software era común en las comunidades de desarrolladores y había incluso preguntas sobre si las leyes de derechos de autor se aplicaban al software, así que las licencias no se escribían desde un punto de vista que uno tuviese que defender en un juzgado. El concepto de copyleft todavía no había sido inventado, siendo estas primeras licencias de tipo permisivo.

A mediados de los años 80 el proyecto GNU redactó licencias de software libre individuales para cada uno de sus paquetes de software. Una de las primeras de estas licencias, la GNU Emacs Copying Permission Notice, se usó para GNU Emacs en 1985,[4]​ con revisiones siguientes en los años 1986, 1987 y 1988, tomando el nombre de GNU Emacs GPL.[5]​ De manera similar, la GPL de GCC se aplicaba a la colección de compiladores de GNU, que se publicó por primera vez en 1987.[6][7]​ Finalmente, en 1989, se publicó la primera versión de la GPL, aunque fue rápidamente superada por la segunda versión en 1991. De esta forma, llegó a ser la licencia de software libre más ampliamente usada.[8]

Otra de las primeras licencias de software libre en aparecer, fue la licencia BSD. Esta fue creada para la distribución del sistema operativo BSD, desarrollado en la Universidad de Berkeley.

Posteriormente, en la década de los noventa, se popularizó la creación o adaptación de licencias por parte de compañías y proyectos para sus propios productos. Esta rápida proliferación de licencias derivó en una complicada situación, donde el exceso de opciones dificultaba la elección de una licencia por parte de los desarrolladores de software y, al mismo tiempo, generaba problemas de compatibilidad a la hora de distribuir programas con licencias distintas que podían tener términos contradictorios.[9]​ Esto llegó a desembocar en procesos judiciales, como los que afectaron a la segunda versión de la licencia GPL en Alemania y más tarde en Estados Unidos. En el caso alemán, relacionado con el programa iptables, la defensa —la empresa que había incumplido los términos de la GPL— argumentó que no había aceptado la licencia, por lo que sus cláusulas no debían aplicarse. Sin embargo, sin discutir públicamente la validez de las cláusulas de la GPL, el juez concluyó que en dicho caso se debían respetar los derechos garantizados por defecto en la ley de derechos de autor alemana, que no permite la distribución y copia del software sin permiso del autor, ya que estos se habían dado únicamente como parte de la licencia y esta misma exige el cumplimiento de todos sus puntos para acceder a tales derechos. De esta forma, el veredicto fue favorable al demandante —el desarrollador que había publicado su código bajo la licencia GPL—.[10]​ El caso de EEUU —MySQL contra Progress—, fue cerrado antes de que se llegara a un veredicto, pero, en un principio, el tribunal no vio ninguna razón por lo que la GPL no fuese legal ni de obligado cumplimiento.[11]

Definiciones[editar]

Licencias de software libre aprobadas por la FSF[editar]

La Free Software Foundation (FSF), grupo creado para impulsar el software libre y muy vinculado al proyecto GNU, mantiene una lista no exhaustiva de licencias de software libre. Estas deben ser acordes a la definición de software libre dada por la FSF, es decir, que cumpla las cuatro libertades del software libre.[12]​ La FSF recomienda el uso de las licencias de software libre copyleft —las que obligan a distribuir las obras derivadas con licencias también libres— antes que las licencias de software libre permisivas para la mayoría de los propósitos. En su lista distingue entre las licencias de software libre que son compatibles la GPL y las que no.

Licencias de código abierto aprobadas por el OSI[editar]

El grupo Open Source Initiative (OSI) mantiene una lista de licencias de código abierto aprobadas por el mismo. Esta coincide con la de la FSF en la mayoría de los casos, aunque existen puntos de vista discordantes entre ambas organizaciones. Por ejemplo, la OSI se muestra más favorable hacia las licencias de software libre permisivas.

Restricciones en las licencias de software libre[editar]

Existe un debate que todavía está en vigor en la comunidad de software libre con respecto a la fina línea entre qué restricciones se pueden aplicar y qué todavía se pueda llamar libre.

Solo las licencias del tipo de dominio público están libres de restricciones, como por ejemplo la WTFPL o la licencia CC0. Las licencias permisivas pueden conllevar pequeñas obligaciones como la atribución de la autoría, pero prácticamente permiten el uso del código en todos los casos. Ciertas licencias, como las licencias de copyleft, incluyen restricciones más fuertes forzando a que los proyectos derivados garanticen derechos específicos que no se pueden eliminar.

Las licencias de software libre compartir-igual escritas por Richard Stallman a mediados de los años ochenta comenzaron un concepto conocido como copyleft. Las licencias de copyleft afirman o imponen que cuando las versiones modificadas del software libre se distribuyen, deben ser distribuidas con los mismos términos que el software original. Por eso se suelen denominar compartir-igual (del inglés share-alike) o quid pro quo. Esto asegura que cualquier obra derivada siga siendo libre, mientras que si se usara una licencia permisiva, se podría emplear dicho software en proyectos privativos.

Los desarrolladores que usan el código GPL en sus productos deben asegurar que el código fuente esté disponible para cualquier usuario del producto, incluyendo cualquier cambio que se haya podido realizar en caso de que sea una obra derivada. Este requisito es únicamente necesario en caso de que las obras derivadas se distribuyan, por lo que no es necesario publicar los cambios realizados si se les da un uso privado. Los defensores del copyleft argumentan que esto permite asegurar la continuidad del software libre, mientras que sus detractores afirman que ninguna licencia puede garantizar la disponibilidad del software futuro y que las desventajas de la GPL superan a las ventajas.[13]​ Otro argumento muy utilizado es que el copyleft restringe la propia libertad de las licencias al imponer condiciones en la forma en la que las obras derivadas deben ser distribuidas, lo que suele ser rebatido con que el no poder preservar la libertad del software hace menos libre a la licencia.

Protección contra patentes[editar]

Durante los años noventa, estas licencias de software libre empezaron a incluir cláusulas para protegerse contra las patentes de software. Esta nueva amenaza era una de las razones para escribir la versión 3 de la GPL de GNU en el 2006.[14]​ En los últimos años, están apareciendo dispositivos específicamente diseñados para prevenir que los usuarios ejecuten versiones modificadas del software en ese hardware. Esto es visto por la FSF como una manera de transformar el software libre en no libre de manera efectiva, por lo que esta práctica es incompatible con la tercera licencia de la GPL.[15]​ Las licencias de software libre escritas recientemente incluyen alguna forma de cláusulas contra patentes. Estas medidas estipulan que los derechos de uno bajo la licencia, tales como la de la redistribución, pueden ser eliminadas si se llevan a cabo prácticas, como la anteriormente mencionada, que restringen las libertades del usuario.

Otras restricciones[editar]

Algunas licencias, como la versión 3 de la GPL, prohíben específicamente que las libertades del producto licenciado puedan ser limitadas por la gestión de derechos digitales.

La mayoría de las licencias de software libre requieren que el software modificado afirme haber sido modificado. Algunas licencias también exigen que se atribuya de forma explícita la autoría a sus autores originales o el mantenimiento de la información existente referida a la licencia.

Problemas prácticos con las licencias[editar]

Compatibilidad de licencias[editar]

Los paquetes de licencias de software que contienen explicaciones contradictorias, hacen imposible combinar el código de estos paquetes para crear nuevos paquetes de software. La compatibilidad de licencias entre una licencia copyleft y otra licencia a menudo se produce en un único sentido. Las licencias que no son copyleft tienen menos problemas de compatibilidad al ser menos restrictivas. Por ejemplo si una licencia dice que las versiones modificadas deben mencionar a los desarrolladores en cualquier material de marketing, y otra dice que las versiones modificadas no pueden contener atribución adicional, entonces si alguien combina un paquete de software que usa una licencia con un paquete de software que usa la otra entonces sería imposible satisfacer la combinación porque estos requisitos son contradictorios y no se pueden completar a la vez, luego estos dos paquetes serían incompatibles. Asimismo, una licencia copyleft no necesariamente es compatible con otra licencia copyleft. Un claro ejemplo de esto está en la incompatibilidad de la versión 2 de la GPL con la versión 3.

Propósito de uso[editar]

Restringir en la licencia los derechos sobre software según el propósito de uso que se tenga —por ejemplo, prohibir su uso para fines militares— suele ser una práctica no aceptada por la mayoría de organizaciones relacionadas con el software libre o el código abierto, entre las que se pueden contar a la FSF, la OSI, Debian, derivados de BSD,...[16]​ o en organizaciones comerciales.[17]

Conflictos de definición[editar]

Como hay varias organizaciones que definen y grupos que publican definiciones y guías sobre las licencias libres o de código abierto —notablemente la FSF, el OSI, el proyecto Debian y los derivados de BSD— hay a veces conflictos en las definiciones e interpretaciones.

Las opiniones de copyleft contra las permisivas[editar]

Muchos usuarios y desarrolladores de los sistemas operativos basados en BSD tienen diferentes opiniones a la hora de aplicar licencias. La diferencia principal es la creencia de que las licencias de copyleft, en particular la GPL, son indeseadamente complicadas o restrictivas.[18]​ La GPL exige que cualquier trabajo derivado también se libere de acuerdo con la GPL mientras que la licencia BSD no. Esencialmente la licencia BSD solo exige el conocimiento de los autores originales, y no imponer restricciones sobre cómo se tiene que usar el código fuente. De esta manera el código BSD se puede usar en software propietario que solo reconoce el trabajo de los autores. Por ejemplo el ip Stack de Microsoft Windows NT 3.1 y Mac OS X son derivados de software con licencia BSD. Los que apoyan las licencias BSD argumentan que es mucho más libre que la GPL porque concede el derecho de hacer cualquier cosa con el código fuente, siempre que el reconocimiento del autor se preserve. Por ejemplo, los usuarios pueden incorporar código licenciado con BSD en productos propietarios. Esto ha llevado a que el código BSD se use en el software privativo de manera amplia y generalizada. En respuesta a eso, los que apoyan la GPL dicen que una vez que el código se vuelve propietario, los usuarios pierden las libertades que definen al software libre.[19]​ De esta manera consideran que la licencia BSD es menos libre que la GPL, y consideran la libertad un concepto distinto visto desde el punto de vista de la falta de ninguna restricción. Ya que la licencia BSD restringe el derecho de los desarrolladores a tener que los cambios que contribuyan a la comunidad, ni la GPL es libre en el sentido de que no haya ninguna restricción.

El código licenciado bajo una licencia de software libre permisiva, tal como la licencia BSD, se puede incorporar a proyectos de copyleft. Ese código es por tanto compatible con la GPL. No es necesario asegurarse del consentimiento de los autores originales. Al contrario el código de la GPL no puede ser licenciado otra vez por las licencias BSD sin asegurarse de que el consentimiento de todos los propietarios del copyright. Estas dos licencias son compatibles, pero a menos que se consiga consentimiento la combinación de ambas como un todo se debe distribuir bajo términos de la GPL, no la licencia permisiva.

El software libre de BSD suele evitar incluir software con licencia bajo la GPL en el núcleo del sistema operativo, o el sistema base, salvo como último recurso cuando no existen alternativa como el caso de gcc. Por ejemplo, en Free BSD 10.0 gcc se reemplaza por Clang quizás principalmente por esta razón. El proyecto open BSD ha intentado eliminar las herramientas de licencia de GPL a favor de las alternativas licencias BSD como algunas escritas nuevamente y algunas adaptadas desde código antiguo.

Debian[editar]

El proyecto Debian usa el criterio que se puede encontrar en las guías al software libre Debian. El único caso notable donde Debian y la FSF discrepan es sobre la herencia artística y la licencia de documentación libre GNU. Debian acepta la licencia artística original como la licencia de software libre pero la FSF discrepa. Esto tiene muy poco impacto, sin embargo la licencia artística casi siempre se usa en una instalación de doble licencia junto con la GPL

Controversia de casos límite[editar]

La amplia mayoría del software libre usa licencias de software libre compatibles, sin embargo, ha habido muchos debates sobre si otras licencias cumplen esta definición.

Ejemplos de licencias que provocaron debate fueron las series 1.X de la licencia de código público de Apple ya que fueron aceptadas por la OSI pero no por la FSF o Debian, y la RealNetworks Public Source License, que se aceptó por la OSI y por la FSF pero no por Debian. También la FSF recomendó la licencia de documentación libre de GNU, que es incompatible con la GPL era considerada no libre por Debian sobre el 2006 y por Nathanael Nerode. La FSF argumenta que la documentación es cualitativamente diferente con respecto al software y que está sujeto a requisitos diferentes. Si bien acepto más tarde que la FDL de GNU cumple las guías de Debian, mientras que llamaron a la licencia todavía no libre de problemas cuando la controversia de la sección invariante (no poder editar ciertas secciones) se eliminó. La mayoría de la documentación de GNU incluye secciones que no se pueden editar. De manera similar los manuales de la fundación FLOSS, en la organización evitar la GFDL y en vez de eso usan la GPL para sus textos en 2007, citando la incompatibilidad entre ambas, las dificultades para implementar la GFDL, y el hecho de que la GFDL "no permite la fácil duplicación ni tampoco la fácil distribución" especialmente para un documento digital.

Véase también[editar]

Referencias[editar]

  1. Hancock, Terry (29 de agosto de 2008). «What if copyright didn't apply to binary executables?». Free Software Magazine. Consultado el 25 de enero de 2016. 
  2. «Top 20 licenses». Black Duck Software. 19 de noviembre de 2015. Consultado el 19 de noviembre de 2015. «1. MIT license 24%, 2. GNU General Public License (GPL) 2.0 23%, 3. Apache License 16%, 4. GNU General Public License (GPL) 3.0 9%, 5. BSD License 2.0 (3-clause, New or Revised) License 6%, 6. GNU Lesser General Public License (LGPL) 2.1 5%, 7. Artistic License (Perl) 4%, 8. GNU Lesser General Public License (LGPL) 3.0 2%, 9. Microsoft Public License 2%, 10. Eclipse Public License (EPL) 2%». 
  3. Balter, Ben (9 de marzo de 2015). «Open source license usage on GitHub.com». github.com. Consultado el 21 de noviembre de 2015. «"1 MIT 44.69%, 2 Other 15.68%, 3 GPLv2 12.96%, 4 Apache 11.19%, 5 GPLv3 8.88%, 6 BSD 3-clause 4.53%, 7 Unlicense 1.87%, 8 BSD 2-clause 1.70%, 9 LGPLv3 1.30%, 10 AGPLv3 1.05%». 
  4. «GNU Emacs Copying Permission Notice (1985)». Consultado el 8 de noviembre de 2015. 
  5. «Free Software - GPL Enforcement». Tech Insider. Consultado el 8 de noviembre de 2015. 
  6. «GCC Releases». Consultado el 19 de marzo de 2015. 
  7. «GPLv3 - Transcript of Richard Stallman from the second international GPLv3 conference, Porto Alegre, Brazil; 2006-04-21». Consultado el 19 de marzo de 2015. 
  8. Top 20 Most Commonly Used Licenses in Open Source Projects, Black Duck Software.
  9. Report of License Proliferation Committee and draft FAQ, Open Source Initiative 2007-12-12.
  10. «Groklaw - The German GPL Order - Translated». Consultado el 2 de febrero de 2018. 
  11. Cónfer Progress Software Corporation v. MySQL AB, 195 F. Supp. 2d 328 (D. Mass. 2002), on defendant's motion for preliminary injunction.
  12. «Various Licenses and Comments about Them - GNU Project - Free Software Foundation». Consultado el 19 de marzo de 2015. 
  13. «Why you should use a BSD style license for your Open Source Project». Consultado el 19 de marzo de 2015. 
  14. «GPLv3 - Transcript of Richard Stallman from the fifth international GPLv3 conference, Tokyo, Japan; 2006-11-21». Consultado el 19 de marzo de 2015. 
  15. «Richard Stallman discusses changes in GPLv3». «a new method of trying to deprive the users of freedom. In broad terms we refer to this as tivoisation.» 
  16. «The HESSLA's Problems - GNU Project - Free Software Foundation». Consultado el 19 de marzo de 2015. 
  17. «GPLv3 - Transcript of Richard Stallman from the third international GPLv3 conference, Barcelona; 2006-06-22». Consultado el 19 de marzo de 2015. 
  18. «OpenBSD Copyright Policy». «the restriction that source code must be distributed or made available for all works that are derivatives [...] As a consequence, software bound by the GPL terms cannot be included in the kernel or "runtime" of OpenBSD». 
  19. «Freedom or Power? by Bradley Kuhn and Richard Stallman». 

Enlaces externos[editar]