Licencia de software libre

De Wikipedia, la enciclopedia libre
Saltar a: navegación, 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 copyright, 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 copyright 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 la ley de copyright 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. Copyleft todavía no había sido inventado, estas primeras licencias eran de tipo permisivo. A mediados de los años 80 el proyecto GNU produjo 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 ha usado para GNU Emacs en 1985,[4]​ con revisiones siguientes en el 86 87 88 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 fue pública por primera vez en 1987.[6][7]​ La licencia original BSD también es una de las primeras licencias de software libre, de 1988 en 1989 la versión 1 de la GPL se publicó. La versión 2 de la GPL, liberada en 1991, llegó a ser la licencia de software libre más ampliamente usada.[8]​ Empezando a mediados de los 90 hasta mediados de los 2000, empezó una moda donde las compañías y los proyectos escribían sus propias licencias, o adaptaban las licencias de otros añadiendo su propio nombre. Esta proliferación de licencias condujo a problemas de complejidad y compatibilidad de licencia.[9]​ Una de las licencias software libre, la GPL versión 2, se llevó a juicio, por primera vez en Alemania y más tarde en Estados Unidos. En el caso de Alemania el juez no discutió públicamente la validez de las cláusulas de la GPL pero aceptó que la GPL se había adherido a: " sí la GPL no era acordada por ambas partes, el dependiente no tendría los derechos necesarios de copia distribución y de hacer el software libre públicamente disponible". Debido a que el defensor no cumplía la GPL, tuvo que ceder el uso del software.[10]​ El caso de EEUU (MySQL contra Progress), se paró antes de que se llegara a un veredicto, pero en un principio, Judge Saris no "vio ninguna razón" por lo que la GPL no fuese legal ni de obligado cumplimiento.[11]

Definiciones[editar]

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

El grupo OSI define y mantiene una lista de licencias de código abierto aprobadas por el mismo. OSI está de acuerdo con la FSF en la mayoría de las licencias de software libre, pero difiere en algunos de la lista de la FSF. Por ejemplo, se posiciona del lado de la definición de código abierto más que de la definición de software libre. Considera que las leyes del grupo licencias de software libre permisivas son una referencia de implementación de una licencia software libre. Esto es sus requerimientos para aprobar las licencias son diferentes.

Licencias de software libre aprobadas por la FSF[editar]

La FSF, el grupo que mantiene la definición de software libre, mantiene una lista de licencias de software libre no exhaustiva.[12]​ La FSF es una organización sin ánimo de lucro cuya misión es promover la libertad de los usuarios de los ordenadores y defender los derechos de todos los usuarios del software libre.[1] Los desarrolladores de software libre garantizan que todo el mundo tenga los mismos derechos para sus programas, cualquier usuario puede estudiar el código fuente, modificarlo, y compartir el programa. Por el contrario, la mayoría del software lleva una nota qué impide a los usuarios estos derechos básicos, dejándo a los usuarios susceptibles a los deseos de sus propietarios y a la vulnerabilidad de ser vigilados. La FSF prefiere las licencias de software libre copyleft (share-alike) mejor 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 o incompatibles con el la GPL de copyleft de la FSF.

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 que 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 llevar a 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, por ejemplo las licencias de copyleft, incluyen restricciones más fuertes a propósito especialmente sobre el distribuidor de manera que se fuerce a que los proyectos derivados garanticen derechos específicos que no se pueden eliminar.

Las licencias de software libre share-alike escritas por Richard Stallman a mediados de los 80 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 "share or share alike" o "quid pro quo". Estos resultados en el nuevo software siendo también código abierto. Ya que el copyleft se asegura de que las generaciones futuras del software garanticen la libertad de modificar el código esto se llama "software libre". Las licencias que no tienen copyleft no se aseguran de que las generaciones futuras del software permanezca libres.

Los desarrolladores que usan el código GPL en sus productos deben hacer el código fuente disponible a cualquiera cuando comparten o venden el código objeto. En este caso el código fuente debe también contener cualquier cambio que los desarrolladores hayan hecho. Si el código GPL se usa pero no se comparte o vende, no se obliga a hacer el código disponible y cualquier cambio puede permanecer privado. Esto permite a los desarrolladores y organizaciones usar y modificar código GPL para usos privados es decir cuando el código del proyecto no se vende o no se comparte sin ser requerido que esos cambios se hagan disponibles al público. Los que apoyan los reclamos de la GPL piden[13]​ que se obligue a que los trabajos derivados se mantengan bajo la GPL, ya que fomenta el crecimiento del software libre y requiere participación igualitaria de todos los usuarios. Los que son contrarios a lo que reclama la GPL afirman que "ninguna licencia puede garantizar la disponibilidad del software futuro" y que las desventajas de la GPL superan[14]​ a las ventajas. Algunos también argumenta que restringir la distribución hace a las licencias menos libres. Mientras que los proponentes de la GPL argumentarían que no preservar la libertad mediante la distribución lo haría menos libre. Por ejemplo con una licencia que no sea copyleft no garantiza al autor la libertad de ver las versiones modificadas de su trabajo si este se publica mientras que una licencia copyleft sí que garantiza esa libertad.

Represalias de patentes[editar]

Durante los años 90, estas licencias de software libre empezaron a incluir cláusulas, como las represalias de patentes, para protegerse contra el patentes de software en casos legales - un problema que antes no había existido. Esta nueva amenaza era una de las razontes para escribir la versión 3 de la GPL de GNU en el 2006.[15]​ En los últimos años, un término acuñado como tivoization describe un proceso donde las restricciones hardware se usan para prevenir a los usuarios de ejecutar versiones modificadas del software en ese hardware para lo cual, el dispositivo Tivo es un ejemplo. Es visto por la FSF como una manera de transformar el software libre a no libre de manera efectiva, y es por lo que ellos han elegido prohibirlo en la GPL versión 3.[16]​ Las licencias de software libre escritas más recientemente desde los finales de los años noventa incluyen alguna forma de cláusulas de represalias contra patentes. Estas medidas estipulan que los derechos de uno bajo la licencia tales como la de la redistribución pueden ser eliminadas si una intenta intenta forzar aquello relacionado con las patentes y el software con licencia, bajo ciertas circunstancias. Como ejemplo la licencia de código abierto de Apple puede eliminar los derechos de un usuario si dice que el usuario atenta contra la legalidad de los procedimientos contra ellos debido a la legalidad de la patente. Las represalias contra las patentes surgieron después de la proliferación y abuso de las patentes de software.

Restricciones hardware[editar]

La versión 3 de la GPL de GNU de manera específica una prohibición adicional que restringe ser limitado por restricciones hardware y administración de derechos digitales (DRM), una práctica que la FSF llama Tivoization.

Atribución, renuncia y otros[editar]

La mayoría de las licencias de software libre requieren que el software modificado no afirme no haber sido modificado. Algunas licencias también exigen que los propietarios del copyright sean reconocidos. Un ejemplo de estos es la versión 2 de la GPL que exige que los programas interactivos que imprime la garantía la información de licencia no puedan eliminar estos textos de las versiones modificadas que están hechas para su distribución

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 es a menudo una compatibilidad de un solo sentido. La característica de esta compatibilidad es criticada por la Fundación Apache, que ofrece la ciencia permisiva Apache que no tiene esta característica. Las licencias que no son copyleft como la FOSS tienen menos problemas de compatibilidad. 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, estos dos paquetes serían incompatibles. Cuando hablamos de las licencias de copyleft, ellas no son necesariamente compatibles con otras licencias de copyleft, incluso la versión 2 de la GPL por sí misma no es compatible con la versión 3 de la GPL.

Propósito de uso[editar]

Restricciones sobre el uso del software no son generalmente aceptadas de acuerdo con la FSF, OSI, Debian, o las distribuciones basadas en BSD. Algunos ejemplos son prohibir el software sólo para uso privado, para propósitos militares, para comparación o marco de mercado, para un uso que conlleve cuestiones éticamente cuestionables,[17]​ o en organizaciones comerciales.[18]

Conflictos de definición[editar]

Como hay varias organizaciones que definen y grupos que publican definiciones y guías sobre las licencias FOSS, notablemente la FSF, el OSI, el proyecto Debian y los BSDs, hay a veces conflictos de opiniones 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.[19]​ 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.[20]​ 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 19 de marzo de 2015. 
  11. See 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. «Why you should use a BSD style license for your Open Source Project». Consultado el 19 de marzo de 2015. 
  15. «GPLv3 - Transcript of Richard Stallman from the fifth international GPLv3 conference, Tokyo, Japan; 2006-11-21». Consultado el 19 de marzo de 2015. 
  16. «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.» 
  17. «The HESSLA's Problems - GNU Project - Free Software Foundation». Consultado el 19 de marzo de 2015. 
  18. «GPLv3 - Transcript of Richard Stallman from the third international GPLv3 conference, Barcelona; 2006-06-22». Consultado el 19 de marzo de 2015. 
  19. «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». 
  20. «Freedom or Power? by Bradley Kuhn and Richard Stallman». 

Enlaces externos[editar]

Wikilibros