El perdón accidental llega a GPLv2

Hace años, mientras todavía se estaba editando la GPLv3, tuve la oportunidad de asistir a una presentación de Richard Stallman. Realizó toda su rutina como San IGNUcio, y por fin dijo que respondería a las preguntas en una habitación aparte. Cuando los nerds más causales salieron de la sala de exposición, fui junto con un pequeño grupo de fanáticos del software libre que siguieron a nuestro patrón al santuario interior.

Cuando fue mi turno de dirigirme al maestro del software libre, me pregunté qué beneficios tendría la GPLv3 para un hacker humilde como yo. Estaba familiarizado con la cláusula de “Tivoización”, la idea de que cualquier dispositivo que use el código GPLv3 del fabricante permitiría al usuario instalar su propio programa en él, pero eso no parecía el tipo de cosas que la mayoría de la gente alguna vez lo hizo.Tendría que preocuparse. ¿Había algo en la nueva versión de la GPL que debería adoptarse en proyectos personales o de pasatiempos?

Sí, realmente se viste así.

Curiosamente, unos años después, un fabricante eligió mi programa GPLv2 y lo incluyó en uno de sus productos (nunca los subestime, amigos). Entonces, la cláusula de Tivo era válida para mí después de todo, pero ese no es el propósito de esta historia.

El Sr. Stallman respondió que creía que la mayor mejora realizada por GPLv3 sobre la v2 para el desarrollador aficionado era la idea del “perdón” bajo licencia. En lugar de adoptar un enfoque difícil como la versión existente de la GPL, la nueva versión tendría períodos de gracia para cumplir con una licencia. Por lo tanto, los errores legales o malentendidos de los requisitos de la GPL podrían resolverse más fácilmente.

Por eso, cuando leí el reciente anuncio de Red Hat de que respetarían el período de gracia para los proyectos GPLv2, me interesé de inmediato. ¿Seguirá el resto de la comunidad el ejemplo de Red Hat? ¿Cambiará esto la opinión de alguien al decidir entre la GPL v2 y v3? ¿Es eso incluso una buena idea? Únase a mí a continuación mientras analizo estas preguntas.

Definiendo el perdón

El título del anuncio de Red Hat es “Brindar una oportunidad justa para corregir errores”, que es básicamente la manera perfecta de resumir el período de gracia agregado a la GPLv3. Pero para nuestros propósitos, veamos el texto completo, tomado de la cláusula “Fin” de la GPLv3:

No puede distribuir ni modificar ningún trabajo cubierto, excepto según lo dispuesto expresamente en esta Licencia. Cualquier intento de divulgarlo o modificarlo es nulo y automáticamente terminará sus derechos bajo esta Licencia (incluyendo cualquier licencia de patente otorgada bajo el tercer párrafo de la sección 11).

Sin embargo, si rescinde cualquier infracción de esta Licencia, entonces su licencia a un titular de derechos de autor en particular se restablece (a) temporalmente, a menos que y hasta que el titular de los derechos de autor rescinda explícita y eventualmente su licencia, y (b) permanentemente si el titular de los derechos de autor falla. notificarle de la violación por cualquier medio razonable 60 días después del cese.

Además, su licencia a un titular de derechos de autor en particular se restaura permanentemente si el titular de los derechos de autor le notifica la infracción por cualquier medio razonable, esta es la primera vez que recibe un aviso de infracción de esta Licencia (para cualquier trabajo) por parte de ese titular de derechos de autor. y subsana la infracción 30 días después de recibir la notificación.

Bien, entonces, ¿qué significa eso?

Básicamente, el primer párrafo dice que si distribuye un trabajo cubierto por la GPLv3 y viola cualquiera de los términos de la licencia, pierde su licencia y, por lo tanto, el derecho a distribuir el trabajo. Bajo la GPLv2, este sería el final del camino. Rompiste la licencia, ahora manejalo.

Pero los siguientes párrafos te devuelven. Dice que si dejas de violar la licencia y el licenciatario original (en general, el desarrollador original) no quiere promover el problema, se restablecen tus derechos. Además, si repara la violación de su licencia de manera oportuna (30 días) después de que el desarrollador original le haya notificado, y suponiendo que no lo repita, entonces también está libre.

Es importante tener en cuenta que esta cláusula lo protege ya sea que el titular de la licencia se comunique con usted acerca de la violación o no. Si te equivocas y lo arreglas tú mismo, estás cubierto. Si ellos faru contactarte, solo necesitas resolver el problema en un tiempo razonable.

GLP: TL; DR

Puede que esto no parezca tan importante al principio. Después de todo, ¿qué tan difícil es seguir los términos de la licencia, verdad? Bueno, si tuviéramos que hablar de algo tan simple como la licencia BSD de 3 cláusulas, entonces no hay problema. Pero la GPL es una licencia mucho más prolija que otras y también requiere más del usuario.

¿Incluyó una copia completa de la licencia con el programa? ¿Cada archivo de código fuente del programa contiene un título que dice que tiene licencia GPL? ¿Se aseguró de que todos los archivos modificados por la versión original contengan comentarios con fecha que resalten los cambios que realizó? Si está distribuyendo solo un binario, ¿se ha asegurado de que la fuente esté alojada en algún lugar donde el usuario pueda encontrarla de manera razonable?

Estos son solo algunos de los requisitos contenidos en la GPLv2 de ~ 2500 palabras. Es fácil ver cómo alguien que no esté bien versado en la licencia podría pasar por alto algunos de los requisitos más esotéricos, especialmente en la era del clic y la bifurcación de GitHub. Cada uno de estos delitos podría (al menos teóricamente) conducir a la pérdida de sus derechos bajo la licencia.

Pero con las cláusulas agregadas a la GPLv3, estos problemas se pueden resolver con un simple correo electrónico o Tweet. Informe al desarrollador que cometió un error, déle 30 días para solucionarlo y el problema desaparecerá. Es una forma mucho más amigable de lidiar con los errores de licencia, que es posible en parte gracias a la facilidad de comunicación que ahora disfrutamos; una situación que difícilmente podría haber sido imaginada hace 30 años cuando se escribió la GPLv2.

¿Se embarcarán todos?

Los nuevos mecanismos para manejar los problemas de licencias introducidos en GPLv3 son una ventaja para los desarrolladores y un poco tenso para usar GPL, y honrarlos retroactivamente para versiones anteriores de GPL es definitivamente una gran cosa para la comunidad. ¿Pero se quedará?

Google, IBM y Facebook han anunciado que se unirán a Red Hat para honrar el período de gracia para las obras cubiertas por GPLv2, e incluso los desarrolladores centrales de Linux están adoptando un enfoque similar, pero eso aún deja a muchas empresas y desarrolladores sin saberlo. hacer cualquier cosa fuera de lo que dice la licencia. Afortunadamente, cada vez más empresas adoptarán esta postura para admitir la GPLv2 y, con el tiempo, tal vez incluso los desarrolladores individuales lo hagan; pero ciertamente no todos.

Dicho esto, la situación se vuelve borrosa cuando hay algunos subconjuntos de la comunidad en el espíritu de la ley y otros en la letra. Permitir que unos cuantos pesos pesados ​​de la industria básicamente agreguen términos a una licencia existente (incluso si tienen las mejores intenciones) podría verse como una pendiente resbaladiza.

Al final, si le gustan las cláusulas agregadas en la última versión de GPL, probablemente solo tenga que usar la última versión de la GPL, en lugar de depender de la industria para elegir qué partes honrarán o no. Pero si no puede o no quiere, al menos existe la posibilidad de que obtenga un pase; dependiendo de con quién esté tratando.

  • Ostraco dice:

    Suena como la diferencia entre la “gracia” otorgada de manera informal y la gracia otorgada de manera formal. Como el titular original de los derechos de autor, uno tiene algo de tiempo libre.

    Estaba familiarizado con la cláusula de “Tivoización”, la idea de que cualquier dispositivo que use el código GPLv3 del fabricante le permite al usuario instalar su propio programa en él, pero esto no parecía lo más importante. preocuparse “.

    También existe el sigilo de “Internet” y no entremos en patentes.

    • daid303 dice:

      Las patentes están cubiertas por GPLv3. La caché de “Internet” se maneja en AGPL.

  • nsayer dice:

    En última instancia, los términos de la licencia no significan casi nada en ausencia de aplicación. Y la coerción no es necesaria en absoluto cuando un delincuente es un actor genuino que está dispuesto a hacer lo correcto.

  • tomás zerolo dice:

    Gracia

    Tenga en cuenta que la motivación de la FSF siempre ha sido cometer infractores, para nuestro beneficio común, no para extraer dinero de los extranjeros.

    Ha habido casos reales de personas (mal) que utilizan la GPLV2 para extraer dinero de los infractores (incluso engañándolos para que firmen contratos y luego extraigan más dinero de ellos en un plan que solo puede llamarse trolling de derechos de autor).

    Un caso conocido es el de Patrick McHardy:

    https://lwn.net/Articles/694890/
    https://opensource.com/article/17/8/patrick-mchardy-and-copyright-profiteering
    https://lwn.net/Articles/731941/

    No hace falta decir que esto desacredita todo el movimiento del software libre.

    La GPLV3, con sus elegantes cláusulas, dificulta estos engaños. El kernel de Linux (en el que se desarrolló el drama anterior), por desgracia, es solo V2

    • rubypanther dice:

      No puede desacreditar a todo el movimiento porque hay gente que está de acuerdo con él.

      ¡Ciertamente ningún hombre puede hablar por todo un movimiento!

  • Luego dice:

    O simplemente podemos usar la licencia MIT y continuar con la parte divertida: escribir código.

    • Alphatek dice:

      BSD, MIT o cualquier CC. GPL y RMS son extremadamente dañinos para el código abierto.

      • tomás zerolo dice:

        > GPL y RMS son extremadamente dañinos para el código abierto.

        [citation needed]

        Por el contrario, creo que el “código abierto”, como usted lo llama, ni siquiera existiría sin la GPL y GNU.

        Como ilustración (tenga cuidado, podría citar muchos más casos), tomemos Linux. GCC (con todas las ventajas como ensamblador, enlace, libc y amigos), las carpetas GNU y los textiles, la mayor parte del espacio de usuario (X11, que es MIT pero junto con … lo adivinaste) estaban en su lugar y esperaron cuando un estudiante de Finlandia comenzó a piratear el kernel de un sistema operativo, que se convirtió en … Linux.

        Todos los demás compiladores de C viables eran demasiado pequeños en ese momento o estaban encantados con operaciones propietarias.

        Este es solo un pequeño ejemplo.

        Estoy convencido de que * necesitamos * varias licencias gratuitas que hagan todo lo posible para coexistir pacíficamente. También estoy convencido de que las licencias copyleft ocupan una posición clave para mantener sano el ecosistema libre / abierto (aunque creo que no es necesario que sean las únicas, mucho).

        Transmitir el FUD favorito de Microsoft (y Apple) (como lo hace usted) no ayuda a nadie más que a ellos.

        • Miroslav dice:

          Bien dicho.

        • Alphatek dice:

          Lo que dices refuerza mi punto de vista. La GPL y todos sus problemas son también sinónimos de código abierto.

          Los BSD son un ejemplo mucho mejor que Linux.

          • Bestia nominal dice:

            La realidad supera a la teoría, siempre.

            BSD es asombroso en teoría, al igual que el socialismo o el comunismo o una economía en auge o cualquier otra utopía.

            Prácticamente, cosas como los derivados comerciales de código cerrado causan muchas mejoras y correcciones atascadas en los proyectos propietarios, y muchos desarrolladores eventualmente hacen la transición a esos proyectos propietarios (como el trabajo remunerado, porque todos tienen que ganarse la vida de alguna manera).

            El resultado final es que la parte desarrollada abiertamente sigue siendo una semilla, que produce muchos proyectos separados, con poca o ninguna reacción de los proyectos de propiedad hacia la semilla original. Evolutivamente es un callejón sin salida.

            Puede ver esto especialmente bien en los proyectos FreeBSD y OpenBSD. No hay tanta innovación allí, solo una buena ingeniería realizada por un grupo de desarrollo central diligente. Otros proyectos populares que utilizan licencias similares, como el servidor Apache (que, por cierto, obtuvo sus propios derivados, debido a la robustez de la ingeniería pura, en lugar de la innovación), parecen tener características similares.

            (Sin embargo, hay muchos proyectos GPL con características similares: GNU m4, make, etc. Sospecho que estos proyectos no se verían perjudicados por una licencia bajo BSD o licencias similares).

            Sin embargo, cuando miramos proyectos con muchas innovaciones (como en experimentación, cantidad de características agregadas o cantidad de código reemplazado con el tiempo), tienden a estar autorizados bajo la GPL. No tengo pruebas de que esto se deba a la licencia – una correlación no causa – pero conozco a muchos desarrolladores que eligen GPL, explícitamente porque quieren poder incluir mejoras desarrolladas en derivados.

            Esto no tiene nada que ver con sentirse “posesión” del código. Personalmente publico MUCHOS fragmentos de muestra como CC0 (aunque generalmente no me importa especificar la licencia a menos que alguien me lo pida), pero para proyectos más grandes, definitivamente prefiero GPL3. (Hay algunas bibliotecas que desarrollo que tengo la intención de publicar usando una licencia CC o BSD, pero implementan un formato específico, y no hay mucho potencial “evolutivo” en ellas; aunque ciertamente se beneficiarían de una mejor ingeniería y múltiples puntos de vista de los desarrolladores para hacerlos mejores / más robustos).

            La elección de GPL por mi parte, y muchos de mis desarrolladores están de acuerdo, se basa en el deseo de preservar ese “potencial de desarrollo” para el proyecto. La mayoría de los proponentes de BSD creen que tener derivados de código cerrado no daña el proyecto original en absoluto, pero yo y muchos otros no estamos de acuerdo: el “potencial de desarrollo”, la capacidad de reintegrar nuevos conocimientos y características y soluciones desarrolladas en los derivados, es extremadamente valioso. ., y se pierde si los derivados son de fuente cerrada.

            Finalmente, el número de p. Ej. Los desarrolladores activos del núcleo de Linux pagados por varias empresas por su trabajo, en comparación con, p. Ej. OpenBSD, OpenSSH o cualquier otro proyecto con licencia BSD, en sí mismo es una realidad muy memorable. Con GPL, estas empresas se dan cuenta de que no se están beneficiando de intentar cerrar la fuente (y de que estos programadores capaces trabajen solo en los derivados internos). Con BSD, es normal e incuestionable buscar desarrolladores desde proyectos de código abierto hasta el desarrollo derivado de código cerrado interno.

        • Greenaum dice:

          Dios, es más fácil simplemente iniciar Windows.

      • q2dg dice:

        Eres ignorante

        • Blecky dice:

          ¡Sin desviación!

      • bruceperens dice:

        De hecho, algunas de las licencias CC son más restrictivas que la GPL, así que creo que estás confundido. Las empresas con mucho gusto se harían cargo de la GPL sobre Creative Commons Attribution-Noncommercial-NoDerivs, por ejemplo.

        BSD o MIT tiene la función de bienestar corporativo. Es un regalo para una empresa realmente grande, a menudo hecho por un individuo, y la gran empresa puede tratar al individuo como su empleado no remunerado. Existen razones comerciales prácticas para usar BSD o MIT cuando desea que todos, incluidas las grandes empresas, utilicen algo por encima de todos los demás objetivos. Por ejemplo, cuando publica una implementación de referencia para utilizar un servicio en línea que proporciona. Pero sin una buena razón comercial como que las personas simplemente pongan todo su trabajo bajo BSD o MIT, un poco de auto-gana. El trabajo que sometí a la GPL se ha ampliado enormemente gracias a las contribuciones de las empresas. El hecho de que las grandes empresas tengan que cumplir con la licencia molesta a los ricos que prefieren hacerles regalos. Pero toda niña pequeña quiere un pony.

        • Ostraco dice:

          “Por ejemplo, cuando publica una implementación de referencia para utilizar un servicio en línea que proporciona. “

          O intentar difundir un estándar lo más rápido y amplio posible. p.ej. pila neta, etc.

      • daid303 dice:

        CC es malo para el código porque no apunta al código en absoluto.

        BSD o MIT le da al código la mayor libertad.
        La GPL brinda al usuario final la mayor libertad. (Y con el usuario final me refiero al usuario del software, no al ingeniero de software)

        Dependiendo de su apariencia al mundo, ambos pueden ser dañinos. Como miras desde diferentes perspectivas.

        • Dan dice:

          CC es bastante malo para todo (excepto CC0).
          P.ej Para las imágenes: dado que la mayoría de las asignaciones de proyectos son, en el mejor de los casos, molestas y feas, es más fácil ir a un sitio web de valores y comprar imágenes.
          CC requiere una tarea muy sobresaliente que simplemente no funcionará para la mayoría de los proyectos. Regálalo gratis (CC0) o véndelo.

          • Zengar dice:

            Creative Commons funciona de maravilla en entornos como podcasts y radio por Internet, por lo que formatos en los que la atribución no solo no es intrusiva, sino que incluso es algo que el consumidor final suele querer. Está diseñado para uso de revistas / programas de variedades, no código ni componentes.

    • mmiscool dice:

      La única licencia que utilizo voluntariamente es la licencia del MIT.

      La GPL es consistente y simplemente un mal manifiesto.

      MIT es simple. Haz lo que quieras con el código. Sin estafa.

    • rubypanther dice:

      Si realmente quisiera escribir código y no preocuparse por los detalles de la licencia y los campos de licencia y todo lo que usaría la licencia de Apache 2, entonces todos los campos diferentes pueden usar su código y usted puede simplemente codificar o lo que sea.

      No aboga por la escritura de código, está abogando por una licencia de equipo MIT.

  • bruceperens dice:

    El 27 de noviembre, Red Hat, IBM, Google y Facebook anunciaron que darían a los infractores de su software GPL hasta un período de 30 días durante el cual un infractor acusado podría curar una infracción de GPL después de ser alertados. del titular de los derechos de autor, y una “receta” de 60 días para una infracción ya curada cuando el titular de los derechos de autor nunca informó al infractor de la infracción. En cualquier caso, no habría castigo: sin daños, sin honorarios, probablemente sin juicios; para el delincuente que sana de inmediato su transgresión. Discutiré esto en un estilo de preguntas y respuestas:

    P: ¿Cambia esto algún caso judicial sobre GPL que esté progresando? R: No. Red Hat, IBM, Google y Facebook no saben que están involucrados en casos recientes de hacer cumplir sus derechos de autor sobre cualquier software bajo la licencia GPL. Red Hat sugirió una vez que podría hacer cumplir la GPL contra los infractores de patentes, pero no conozco ningún caso que hayan hecho.

    P: ¿Cambia esto la forma en que se implementará una licencia GPL en Linux o cualquier programa abierto? R: Eso es poco probable. A estas cuatro empresas no les conviene en el futuro comprometerse con el cumplimiento de la licencia GPL. Por lo tanto, su promesa de permitir que un delincuente cure su delito dentro de ciertos límites de tiempo no tiene sentido. Red Hat e IBM preferirían vender sistemas Linux que asustar a sus clientes con el procesamiento. Google y Facebook tienen peces más grandes para freír.

    P: ¿Alguien más tiene que dar los mismos límites de tiempo? R: No. Las empresas involucradas en el anuncio no son las entidades que procesan las demandas de GPL. Hay miles de titulares de derechos de autor en el kernel de Linux que teóricamente podrían presentar una demanda, y quizás cien mil autores de software habilitado para GPL además de Linux (pero que podrían incluirse como parte de un sistema Linux típico). Ninguna de esas partes está obligada por el anuncio de hoy. Pero, en general, esas partes esperaron voluntariamente mucho más tiempo para que las violaciones sanasen sin castigo.

    P: ¿Su anuncio se ajusta a los Principios de implementación de GPL orientados a la comunidad redactados por Freedom Conservancy Software? Una especie de. Obviamente, está inspirado en ellos y en un anuncio previo del equipo central, que también inspira los principios de SFC pero no los menciona. La comunidad de desarrolladores de código abierto generalmente no solo espera 30 días para que un infractor resuelva su infracción sin ninguna sanción. Históricamente, han esperado mucho más y los principios comunitarios no especifican una duración en particular. Las violaciones de algunos de mis clientes ejecutivos serían imposibles de resolver en solo 30 días. Algunos casos se resolvieron silenciosamente después de más de un año de progreso, sin costo, o quizás solo con una tarifa de auditoría aceptable. A uno de mis clientes, una compañía Fortune 100, se le pidió que pagara $ 5000 en tarifas de control para resolver una violación de GPL en una línea de productos de miles de millones de dólares. Los infractores actuales pueden ser demandados de manera más sencilla porque estos casos son costosos de tratar, pero en general la comunidad prioriza la aplicación de la ley sobre los ingresos y no reclama daños mayores como lo haría una empresa en la industria del software propietario.

    P: ¿Por qué se hizo el anuncio de hoy? R: Las empresas están preocupadas por una persona, Patrick McHardy. No tengo conocimiento personal de esto, pero la abogada Heather Meeker lo documentó. Se dice que generó alrededor de 50 reclamos de derechos de autor sobre el kernel de Linux, con la intención de recaudar ingresos en lugar de simplemente obtener el cumplimiento de la licencia GPL. Casi todos en la comunidad de código abierto y las empresas involucradas se oponen a este comportamiento. Yo también. Pero a mi leal saber y entender, McHardy tiene el derecho legal de presentar tales reclamaciones sobre los derechos de autor que posee, incluso si es incompatible con los Principios de la comunidad, que en realidad nadie está obligado a seguir. Las grandes empresas y los miembros de la comunidad (y yo) queremos desalentar a McHardy y otras partes que quieran convertirse en “trolls de derechos de autor” en un estilo similar y causar daños exactos debido a infractores involuntarios de programas con licencia GPL y otros programas.

    P: ¿El Linux Core Team hizo un anuncio similar al de las cuatro empresas? A: si. Eso es lo que tenían que decir. Es probable que en el futuro el equipo central deje de aceptar contribuciones de personas que no se adhieran a las políticas de ese enlace. Actualmente excluyen al Sr. McHardy del equipo central. Pero es importante tener en cuenta que existe una gran cantidad de trabajo existente en el kernel por parte de los titulares de derechos de autor que no tienen que cumplir con estos principios, y los titulares de derechos de autor no todos los programas GPL excepto el kernel (software más grande que el kernel) obligada a respetar estos principios.

    P: ¿Es cierto que los principios que las cuatro empresas anunciaron hoy se toman de la licencia GPL 3, pero los aplican a GPL 2? A: si. Si su software está bajo GPL 3, necesita los mismos períodos de espera prometidos por los cuatro compañías. Por lo tanto, es irónico que cuando originalmente tuvieron la oportunidad de aplicar GPL 3 a Linux, Linus Torvalds y el equipo de Kernel fueron bastante hostiles al respecto, mientras que el reciente anuncio del equipo del kernel atribuye los principios que adoptaron al texto en GPL 3. Quizás hayan aprendido algo desde esos momentos hostiles.

    P: Tengo más preguntas. R: Envíelos a Bruce en perens punto com.

  • bruceperens dice:

    La versión de este comentario con enlaces está en https://perens.com/2017/11/28/understanding-the-red-hat-ibm-google-facebook-gpl-enforcement-announcement/

  • Un dron dice:

    GPL contra LO QUE SEA … ¡A China no le importa!

    • Elliot Williams dice:

      ¡Realmente no! Se contrató a varias empresas chinas que no cumplían con las normas después de que se les informara de sus responsabilidades.

    • rubypanther dice:

      No a todo el mundo en China le importa, no a todo el mundo en Estados Unidos le importa.

      A Naomi Wu le importa, por eso creó la plataforma educativa sine: un poco! (con ingeniería donada por elecrow) El objetivo es enseñar los principios de la PI dando acceso a las herramientas de código abierto a los jóvenes. Una vez que comienzan en la industria, ya han desarrollado su pensamiento sobre cómo copiar código; por lo que es importante comenzar antes de esa fecha, enseñándoles la higiene de la propiedad intelectual cuando eran niños. Y, por supuesto, es mucho más fácil darles algo a los niños y enseñarles por qué se lo diste, y hacer que lo aprecien, y luego decirles “no” y esperar que les importe.

      https://github.com/sinobitorg
      https://www.elecrow.com/sino-bit-v1-0.html

      ¡A China le importa y están trabajando en ello! ¡Gracias Naomi!

  • bueyes dice:

    “Mientras que los nerds más causales salieron de la sala de exposición, yo seguí adelante”, por lo que el escritor no es razonable, ¿entiendo?

    • Tom Nardi dice:

      Diría que a estas alturas me he graduado como nerd profesional en este momento, sí.

      • alfie275 dice:

        ¿Qué le permite romper la causalidad? : PAG

        • Greenaum dice:

          Es una forma de hacer que tus nerds sean más efectivos.

    • Shirley Grava dice:

      Vine a la sección de comentarios buscando solo esto. Gracias.

  • JackDanson dice:

    No creo en el “código abierto”, que todavía tiene una cadena atada, incluso si se supone que esas cadenas están diseñadas para obligar al usuario a liberar el código abierto. Lo simplifico. Si no quiero que sea de código abierto, no lo publico. Si lo publico, se publica bajo el MIT.

    • rubypanther dice:

      Es por eso que esto se llama software libre en lugar de código abierto.

      Afirmas estar en contra de obligar al usuario, pero el MIT tiene algunas cadenas importantes.

      Si desea evitar la coerción, ¿podría sugerirle que consulte la licencia de Apache 2? Entonces, los proyectos autorizados por el MIT aún se pueden copiar de usted, al igual que todos los demás, incluidos los proyectos GPL y propietarios.

      Me parece extraño que uno de los mejores “equipos de licencias” en el mundo del código abierto quiera afirmar que son más abiertos que todos los demás, incluso cuando su licencia no es la más compatible o la menos difícil.

  • Que no dice:

    ¿Red Hat otorgará ese “período de gracia” a otros oa sí mismos (y socios)? Ya sabes, para que puedan jugar con código abierto por motivos comerciales. Porque parece haber una tendencia lenta y constante hacia un mayor comercialismo en el mundo de Linux también.
    Las mentes cínicas quieren saber.

  • hotaru dice:

    GPL es inútil sin el estricto cumplimiento de los titulares de los derechos de autor. Varias veces he intentado (sin éxito porque no soy propietario de derechos de autor en el kernel de Linux) conseguir que las empresas publiquen el código fuente para sus versiones modificadas del kernel de Linux en los dispositivos que he comprado. si los titulares de los derechos de autor no están dispuestos a cumplir con la licencia, no ayuda en absoluto a los usuarios finales.

    • rubypanther dice:

      Tomemos, por ejemplo, TripWire; si tuvieran un perdón accidental, tendrían más posibilidades de evitar lanzar una versión de código abierto, pero de esa manera tenían que lanzarla para evitar el retiro del mercado de un producto.

      Pero ya me gustó la GPL 2 más que la 3.

  • hotaru dice:

    (reaparición porque aparentemente no pasó la primera vez)

    GPL es inútil sin el estricto cumplimiento de los titulares de los derechos de autor. Varias veces he intentado (sin éxito porque no soy propietario de derechos de autor en el kernel de Linux) conseguir que las empresas publiquen el código fuente para sus versiones modificadas del kernel de Linux en los dispositivos que he comprado. si los titulares de los derechos de autor no están dispuestos a cumplir con la licencia, no ayuda en absoluto a los usuarios finales.

  • rubypanther dice:

    ¡Alabado sea San Ignacio!

    En mi opinión, el impacto en los aficionados es demasiado, ya que es poco probable que la acción coercitiva pueda ayudarlos mucho. Por ejemplo, si no repitieron la información de la licencia en cada archivo, esto se soluciona fácilmente. Y debido a que tienen una licencia, no puede rastrearlos fácilmente debido a una infracción de derechos de autor. No es suficiente mostrar una infracción técnica, debe mostrar una infracción sensible que le perjudica; sin que te lastimen, ¡ni siquiera soportas un juicio! E incluso entonces, si agregan los bloques de licencia a los archivos que especificó en el proceso, ahora el problema es cuestionable y no tiene caso.

    ¡Que Emacs y gcc estén contigo, siempre!

  • Juan (@joltdude) dice:

    Vea lo que no sucede con MOSH debido a la licencia …..
    De hecho, la licencia puede impedir el uso …

  • xorpunk dice:

    Siempre he pensado que es ridículo cómo los usuarios de Linux discuten sobre GPL y LGPL y AGPL y la seguridad, pero voluntariamente usan kernels, llenos de blobs binarios con privilegios completos en su sistema, que nunca han sido analizados. Principalmente para la aceleración 3D para el mercado de juegos y arte. eso realmente no existe para OSS.

Isabella Ortiz
Isabella Ortiz

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *