¿Qué tan exitoso es GPL en alcanzar sus objetivos? [cerrado]


16

En términos generales, hay dos tipos de licencias FOSS cuando se relaciona con el uso comercial del código, digamos el tipo GPL y el tipo BSD. El primero es, en términos generales, restrictivo sobre el uso comercial (por uso también me refiero a la modificación y redistribución, así como a la creación de trabajos derivados, etc.) del código bajo la licencia, y el segundo es mucho más permisivo.

Según tengo entendido, la idea detrás de las licencias de tipo GPL es alentar a las personas a abandonar el modelo de software propietario y, en su lugar, convertirse al código FOSS, y la licencia es el instrumento para atraerlos a hacerlo, es decir, "puede usar este software agradable , pero solo si acepta venir a nuestro campamento y jugar según nuestras reglas ".

Lo que quiero preguntar es: ¿fue exitosa esta estrategia hasta ahora? Es decir, ¿hay logros importantes en la forma de algún gran proyecto que vaya de cerrado a abierto debido a GPL o algún software que se desarrolle en abierto solo porque GPL lo hizo así? ¿Qué tan grande es el impacto de esta estrategia, en comparación, por ejemplo, con el mundo donde todos tendrían licencias de tipo BSD o liberarían todo el código abierto bajo dominio público?

Tenga en cuenta que no estoy preguntando si el modelo FOSS es exitoso; esto está fuera de toda duda. Lo que pregunto es si la forma específica de atraer a la gente para que se convierta de propiedad a FOSS utilizada por el tipo GPL y no utilizada por las licencias tipo BSD fue exitosa. Tampoco pregunto sobre los méritos de GPL como licencia, solo sobre el hecho de su efectividad.


44
La GPL no establece restricciones de uso. Es solo en la distribución que impone restricciones.
whatsisname

1
El contraste debe ser con software propietario, no comercial. Hay mucho comercio con software libre.
Lars Wirzenius

2
˙sı ʇı ʇɐɥʍ uo ɹǝƃuıɟ ʎɯ ʇnd ǝʇınb ʇ, uɐɔ ı ʇnq 'uǝʇʇıɹʍ sɐʍ ן dƃ ǝɥʇ uǝɥʍ ɯoɹɟ ʇuǝɹǝɟɟıp sɯǝǝs p ןɹ oʍ ǝɥʇ ʇnoqɐ ƃuıɥʇǝɯos
Tim Post

Respuestas:


10

Primero, hay una subjetividad inherente en la pregunta: no hay forma de saberlo con certeza, y la historia se puede interpretar de cualquier manera. Este es un viejo debate, y uno de los temas centrales en el debate de código abierto vs software libre. También debe definir lo que quiere decir al alcanzar sus objetivos. Es difícil argumentar que GPL y la FSF no han contribuido a hacer del código abierto un movimiento significativo de las últimas 2-3 décadas. Sin embargo, no ha alcanzado sus objetivos de que todo el código sea software libre.

El modelo de los softwares GPL son, por supuesto, Linux y todo lo que proviene de la FSF (gcc, etc.). Curiosamente, para Linux, la GPL no fue elegida por su postura política, sino por la idea de reciprocidad, como lo dijo Linus Torvald varias veces. Te doy mi código, pero tienes que darme el tuyo a cambio si usas el mío.

En lo que respecta a Linux, creo que la GPL ha sido muy valiosa: un ejemplo reciente es BTRFS, el nuevo fs desarrollado dentro de Oracle. El escritor principal de BTRFS ha declarado que la única razón por la que Oracle acordó en primer lugar usar GPL es porque no tenía otra opción. La pregunta más importante es si Linux mismo tuvo éxito debido o a pesar de la GPL. Varios factores como el liderazgo increíble de Linus, los problemas de derechos de autor para el proyecto * BSD en ese momento, etc., hacen que la hipótesis sea imposible de probar / refutar.

Para gcc, Stallman ha escrito varias veces por qué la GPL salvó el proyecto contra la "propietarización".


3
Stallman ha escrito varias cosas que son brillantes. También ha escrito varias cosas que tienen una conexión dudosa con la realidad. Él afirmando que la GPL salvó a gcc contra la "propiedad" no necesariamente lo hace.
SOLO MI OPINIÓN correcta

claro, pero esto es cierto para cualquier reclamo que haga sobre este tema; eventualmente, dependerá de su propia opinión al respecto. No creo que pueda haber una respuesta definitiva, especialmente porque las ramificaciones de las preguntas son de naturaleza ideológica (tanto para licencias GPL como BSD / MIT).
David Cournapeau

El ejemplo de Oracle es válido, gracias. En cuanto al éxito de Linux, tengo mis dudas de que GPL importara mucho, ya que hay ejemplos obvios de sistemas operativos con licencia BSD. Son algo menos populares, pero dudo mucho que GPL sea la razón. En cuanto a gcc, no estoy seguro de qué significa exactamente 'propiedad' aquí, pero Intel tiene sus propios compiladores propietarios (mejor que gcc), por lo que si Stallman quería evitar este escenario, fracasó.
StasM

Quise decir que si gcc fuera, por ejemplo, BSD, las personas podrían agregar sus mejoras sin devolver el código a la comunidad. GCC está (fue) escrito de una manera tal que extenderlo sin integrarlo con una API privada fue difícil de evitar ( gcc.gnu.org/wiki/GCC_Plugins ).
David Cournapeau

18

Diría que las licencias no restrictivas como las licencias BSD, MIT y Apache han hecho mucho más para promover FOSS que la GPL.

Ejemplos:

  • Proyecto Castillo
  • jQuery,
  • SQLite,
  • Apache,
  • Hibernate y nHibernate,
  • ASP.NET MVC,
  • JSON.ORG,

y muchos otros.

La mayoría de las empresas desconfían demasiado de la GPL para permitir que el código de la GPL se acerque a su esfuerzo de desarrollo, a menos que la empresa en sí misma trabaje realmente bajo el modelo de GPL / servicios de valor agregado.


55
No podría estar más de acuerdo.
configurador

1
También mencionaría la licencia LGPL, que aborda algunos de los problemas con la GPL estándar: en.wikipedia.org/wiki/LGPL
andre

¿Cómo promueve algo de lo anterior la adopción de licencias FOSS?
Mark H

13
No entiendo esta respuesta: ¿por qué una lista de un par de proyectos demuestra que BSD / MIT ha hecho más que GPL para el código abierto? Puede obtener una lista similar para proyectos GPL (linux, gcc, gnome, kde, qt, mysql, emacs, etc ...), y tampoco probaría nada con GPL.
David Cournapeau

1
@George: sí, QT es LGPL, no GPL, perdón por la confusión. Sin embargo, no creo que cambie mi punto de vista.
David Cournapeau

8

La GNU GPL ha tenido éxito a pesar de su aplicación de software libre, no por ello. La mayoría de las empresas están contribuyendo voluntariamente y liberando código bajo la GPL. No hay algoritmos y bibliotecas importantes cubiertos por él, lo que obligaría a los desarrolladores comerciales a desproporcionarse.

Apple hace un buen ejemplo. Han adoptado KHTML y lo han incorporado a WebKit. Y lanzaron el código nuevamente a la comunidad de código abierto. Si bien uno podría suponer que esto se debe a que fueron forzados por la LGPL, parece poco probable. Para Darwin y el usuario BSD, publican el código de manera muy voluntaria. Y con LLVM incluso comenzaron un nuevo proyecto FLOSS. Sin embargo, obviamente Apple sigue siendo en gran medida un proveedor de software propietario.

Android es similar Por supuesto, el soporte de hardware juega un papel importante aquí, pero Google podría haber adoptado una base de código BSD y tomarla como propiedad. Pero escogieron Linux. Por lo tanto, voluntariamente contribuyen de nuevo, no porque no haya una alternativa que no sea de GPL.

Openoffice es una historia más interesante, porque en realidad fue patentada en un punto. Pero nuevamente, la conversión de LGPL fue voluntaria, no necesaria. Sin embargo, la licencia de tipo * GPL lo hizo posible en este caso. Una licencia académica de tipo BSD no hubiera sido suficiente para que Sun lanzara Openoffice, porque alguien más podría haber patentado el código en ese momento. Y a este respecto, la GNU * GPL ha tenido éxito.

La cláusula recíproca / viral no conduce directamente a más código fuente abierto. Pero los proveedores de software lo utilizan para su ventaja cuando lo desean y, por lo tanto, contribuyen al grupo FLOSS. Sin embargo, la mayoría de los vendedores hacen eso de manera no solicitada. Veo poca diferencia entre las licencias de estilo BSD y GPL en lo que respecta a fomentar más contribuciones de código.
En conclusión, la GNU GPL ha tenido éxito, pero también impulsó las licencias de estilo BSD / MIT donde son más apropiadas. Pero también puede simplemente medir el éxito en la "cantidad de código", que creo que es la métrica FSF real.


55
Es curioso que mencione Android, ya que salió de su camino para encontrar deliberadamente una laguna en la GPL que les permitió lanzar una plataforma no modificable. (Algo que las versiones posteriores de la GPL restringen). Google no comparte absolutamente los mismos ideales que la FSF, y el hecho de que Android sea software FOSS es en gran medida irrelevante, porque nadie tiene los recursos para competir con Google en su propia plataforma (si tuvieran que preocuparse por la competencia, lo harían ' He elegido una solución alternativa). Además, Apple no inició LLVM.
Mark H

@sparkie: Eso es interesante. Ayer mismo, leí un artículo en el que un desarrollador de Google criticó a los proveedores de teléfonos por bloquear móviles contra firmas de Android de terceros. (Aunque no tengo dudas de que los esfuerzos de código abierto de Google son principalmente de presentación.)
Mario

No olvidemos uno de los mayores proyectos de GPL, Linux. Ninguno de los grandes proveedores que le agregaron su código (IBM, Oracle, etc.) tenía una opción para bifurcar y apropiarse de un 'núcleo de nivel empresarial mejorado', tenían que hacerlo público. Pero probablemente esas piezas de infraestructura universal se refieren a toda el área donde GPL es más útil que las licencias de estilo BSD.
9000

3

Mirando el Manifiesto GNU , no está claro que convencer a las corporaciones de lanzar el software FOSS era uno de los objetivos. Aquí hay una cita:

Para poder seguir usando computadoras sin deshonor, he decidido reunir un cuerpo suficiente de software libre para poder llevarme bien sin ningún software que no sea gratuito.

Si solo miramos ese objetivo, entonces el proyecto GNU ha tenido un gran éxito. Tenemos un sistema operativo GPL, una suite ofimática, bases de datos y muchas otras aplicaciones que se pueden modificar y redistribuir libremente.


Según tengo entendido, el objetivo final es hacer que la mayor cantidad de software posible sea libre, y dado que gran parte del software está escrito por entidades comerciales, es un objetivo secundario importante hacerlo también gratuito. Si el objetivo fuera solo escribir un cuerpo de software para ser utilizado sin necesidad de software no libre, ¿por qué no ponerlo en dominio público? Obviamente, la naturaleza viral de GPL tiene algunos objetivos que no pueden alcanzarse con PD o incluso con licencia BSD. ¿Cuáles crees que son estos objetivos?
StasM

La GPL evita la estrategia de "aceptar y extender", de modo que alguien no pueda tomar, por ejemplo, Emacs, agregar extensiones que se vuelvan tan populares que no se puedan vivir sin ellas, y liberar todo bajo una licencia patentada. Dicho esto, el manifiesto GNU establece con bastante claridad cuál era el objetivo de la GPL, al menos originalmente.
Larry Coleman

1

Creo que ambas (licencias tipo GPL y BSD) son importantes para el mundo FOSS. Veo el uso de la GPL en dos grupos. Uno es el grupo de partidarios de código abierto muy comprometidos. Creen que la posibilidad de convertir Open-Source nuevamente en trabajo propietario dañará el mundo OSS. Personalmente, creo que ese no es el gran problema. PC-BSD (una variante patentada de BSD) no daña la comunidad BSD. El segundo grupo que adopta la GPL son las grandes empresas. Utilizan la licencia para mantener un mayor control sobre el producto (para respaldar su modelo de negocio, por ejemplo). La competencia tendrá problemas, para ganar dinero con alguien más producto de software con licencia GPL. Por lo tanto, la empresa puede adelantarse a la competencia y, al mismo tiempo, obtener un buen karma para el producto de código abierto.


2
olvidas el tercer campo, que creo que es bastante significativo: la reciprocidad. Es decir, no le importa el software propietario, pero no desea que su código lanzado como código abierto se use en propiedad. GPL te da eso, BSD no. Ese es el campamento en el que estoy, al menos.
David Cournapeau

0

Mi perspectiva personal es la de un desarrollador individual, no empleado por algún tiempo debido a una discapacidad, y esperando (o soñando) poder volver a vivir de la única habilidad valiosa que tengo.

GPL se utiliza para proyectos comerciales todo el tiempo. El problema es lo que a veces se denomina su naturaleza "viral", lo que significa que si usa algún código GPL en un proyecto, probablemente necesite GPL todo el código para ese proyecto. Algunos reclaman una exclusión para la vinculación dinámica. Las preguntas frecuentes de GPL afirman que la vinculación dinámica a los complementos está prohibida debido a las estructuras de datos compartidos: http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins. Esto parece extraño, ya que todas las aplicaciones de Windows se vinculan dinámicamente con los componentes de Windows y comparten estructuras de datos con Windows (una aplicación es, en muchos sentidos, un complemento del sistema operativo), sin embargo, hay aplicaciones de Windows GPL, incluidas muchas lanzadas por GNU. Tal vez esto signifique disfrazar punteros como identificadores y hacer que la mayoría de los accesos a través de funciones no cuente como compartir estructuras de datos, lo que sería un vacío legal que cualquier API de plugin especialmente diseñada o biblioteca vinculada dinámicamente podría explotar, pero obviamente un desarrollador individual tiene que ir a lo seguro sobre tales problemas.

De todos modos, hay buenas razones para la naturaleza "viral" de la GPL, pero para un desarrollador pequeño con una necesidad desesperada de ganarse la vida, esto parece sospechosamente como regalar su trabajo por nada. No todos podemos ganar dinero cobrando por el soporte o vendiendo efectivamente los libros manuales, ya que, entre otros problemas, no todos tenemos las habilidades relevantes. Además, si su producto tiene un manual gratuito inadecuado, el manual del mundo real probablemente terminará siendo Stack Overflow o Superuser o lo que sea, no su manual pagado. Y eso supone que alguien se moleste en resolverlo.

Desde ese punto de vista, las licencias de estilo BSD son muy atractivas. Admito que es hipócrita explotar otro trabajo de código abierto pero mantener cerrados los productos resultantes, pero eso tiene que equilibrarse con otros problemas.

OTOH, nunca he lanzado nada, abierto o cerrado, al menos no desde un montón de complementos que básicamente hice de dominio público hace unos diez años (y como los años adicionales de experiencia me enseñaron, no estaban tan bien escritos ) Así que todo es académico para mí, al menos por el momento.

Aún así, cada vez que miro una biblioteca con una licencia de estilo GPL, mi primer pensamiento es "si me vuelvo dependiente de esto, limito mis opciones".


Las bibliotecas principales de Windows no están bajo la GPL, por lo que no tiene que GPL su aplicación si se vincula a ellas. No estoy seguro de qué licencia tienen, pero no dice "Su aplicación debe ser de código cerrado si se vincula a esto". El problema es solo cuando se vincula a una biblioteca GPL. Las bibliotecas de Windows no son GPL.
jsternberg

Mi punto es que la aplicación (efectivamente un complemento del sistema operativo) está bajo la GPL. Si está prohibido escribir un complemento GPL para Photoshop sin GPL (porque no puede liberar la fuente de Photoshop), ¿por qué no está prohibido escribir un "complemento" GPL para Windows sin GPL? Por ejemplo, cualquier aplicación de línea de comandos que se ejecute en enlaces dinámicos de Windows a archivos DLL como user32.dll y comparta estructuras de datos (como mínimo, cadenas) con las API de E / S de la consola. Este acceso puede hacerse indirectamente, a través de API de biblioteca estándar, pero también hay implementaciones de biblioteca estándar distribuidas bajo licencias GNU.
Steve314

En realidad, creo que hay bibliotecas estándar bajo licencias GNU, pero no estoy seguro de que eso signifique GPL.
Steve314

1
@ Steve314: Lea la GPL con más cuidado. Puede vincular a componentes estándar del sistema, aunque no recuerdo el idioma exacto. La GPL fue cuidadosamente diseñada para la practicidad: practicidad en la promoción de una cierta visión ideológica, pero no obstante la practicidad.
David Thornley

1
@steve: olvídate de los enlaces, etc. La GPL nunca se refiere a esto (la LGPL sí lo hace). GPL dice que un software derivado debe lanzarse bajo la GPL, donde el derivado se deja indefinidamente a propósito, aunque la idea es que si un software no puede funcionar sin el original sin ser alterado significativamente, es derivado. Si crea una aplicación sobre un sistema operativo, el sistema operativo no es un derivado de la aplicación (la relación no es reflexiva)
David Cournapeau

-2

Creo que cuando las personas piensan en GPL piensan en los ideales de GNU, en los que el software debería ser un pensamiento libre, para que las ideas se propaguen, y que las grandes empresas son las malas porque no lo permiten. El problema es que esa forma de pensar no compra muchos programadores porque solo quieren codificar sus cosas, tienen sus programas y también son dueños de la vida, eso no necesariamente involucra software, bajo esa visión BSD y las otras licencias son mucho más atractivas, en el mismo sentido que Linus es más popular que Richard Stallman para los desarrolladores, porque el primero solo quiere hacer lo suyo (como muchos de nosotros), mientras que el otro quiere tratar de cambiar el mundo entero. Entonces, al final, la GPL es como Mikhail Gorbachev, alguien que comienza la evolución pero no está destinada a verla tener éxito.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.