2011-05-02 12 views
7

Estoy tratando de descubrir las consecuencias de licenciar el uso de Grails como la base para el software cerrado de código no libre. Este sería un producto de servidor que se descarga e instala. Los usuarios no tendrían el derecho de redistribuirlo o ejecutarlo como un servicio alojado.¿Puedo usar Grails en software propietario?

Grails y Groovy son geniales: tienen licencia bajo ASF 2.0, que es genial. Sin embargo, Grails tiene mil millones de dependencias y me estoy volviendo loca rastreando a todos.

Grails puede generar una lista de software de la que depende su proyecto ejecutando grails dependency-report. Estoy revisando esa lista de dependencias, PERO:

  • Muchas de las bibliotecas no enumeran sus licencias. Así que iré a todas y cada una de las bibliotecas y sabré su licencia.
  • Supongo que dependency-report no enumera todas las dependencias transitivas (bibliotecas que incluyen esas bibliotecas, etc.) porque no están completamente especificadas en Ivy.

¿Alguien ha realizado este ejercicio anteriormente? Solo saber el resultado final sería una GRAN ayuda. En realidad, tener una lista de todas las dependencias y sus licencias sería una ayuda MÁSIVA.

Gracias!

+0

instalar el paquete de software de un repositorio de Linux respetado (como Fedora o Debian) y una lista de todas las dependencias utilizando el gestor de paquetes. Puedes grep licencias de eso usando una secuencia de comandos. Lamentablemente, Grails no está en la base de datos de Fedora AFAIK. Esto le da un buen resultado, pero no es 100% exacto (errores de licencia pueden ocurrir pero es 99% correcto). – lzap

+0

Grails es un framework de software Java/Spring/Hibernate. Acabo de [buscar en el repositorio de Debian] (http://www.debian.org/distrib/packages#search_packages) y no lo vi. Si conoce un repositorio que lo contiene, ¡hágamelo saber! –

+1

https://launchpad.net/~groovy-dev/+archive/grails – hakre

Respuesta

5

Pasé un día rastreando todas las dependencias de Grails 1.3.7. Aquí está el quid:

  • Grails en sí tiene el agradable licencia ASF amigable
  • Algunos subcomponentes utilizan licencias más restrictivas
  • Sin embargo, ninguno de los subcomponentes usar lo me había llamada un "sensacional" licencia como GPL
  • Sin embargo,, algunas personas considerarían que algunas de las licencias son sorprendentes, sobre todo la LGPL utilizada por Hibernate.

Los abogados tienen miedo a la muerte de LGPL porque es fácil para los desarrolladores cometer un error que obliga a todo el sistema a convertirse en código abierto. Las cosas que desencadenarían esto son: modificar cualquier fragmento del código fuente LGPL, copiar cualquier fragmento del código fuente en su producto o vincularlo al software GPL "estáticamente" en lugar de "dinámicamente" (eso es una larga discusión).

Debido a esto, algunas compañías de software y departamentos de compras tienen reglas que prohíben su uso.

Aquí están los subcomponentes con licencias más restrictivas que ASF. LGPL de lo peor:

  • Hibernate (LGPL)
  • Un montón de cosas javax (como la activación y electrónico) bajo CDDL 1.0
  • org.beanshell BSH es SPL
  • javassist es MPL

Todo lo demás tiene licencia BSD, MIT o ASF. Esos están bien.

+2

No entiendo cómo modificar un poco de LGPL obligaría al licenciatario a liberar todo el código fuente a cualquier cosa que no sea el componente con licencia LGPL que se modificó. –

+0

Siempre me ha sorprendido, pero lo he encontrado una y otra vez en mis empresas y lo he visto en otro lado. Un ejemplo notable fue Oracle adquiriendo BEA y [limpiando su fuente de GPL y LGPL] (http: // www.theregister.co.uk/2008/04/08/oracle_bea_gpl_lgpl_code_check/) –

+0

@Tadeusz A. Kadłubowski - no es así. Solo el código derivado del código LGPL debe estar bajo LGPL también. Vincular contra el código LGPL no significa que usted cree un derivado. La licencia es bastante concreta: http://www.gnu.org/copyleft/lesser.html – hakre

2

Creo que todas las dependencias de Grails estarán bien para su uso con software comercial ya que SpringSource le ofrece soporte comercial. Podrías tratar de preguntarles sobre los problemas de licencia ya que probablemente lo tienen todo resuelto.

-1

El license en el sitio web de Grails seguramente tendrá una respuesta.

+0

Como dice la pregunta, la licencia de Grails a la que se vincula es ASF 2.0 y no dice nada sobre las licencias de las cosas de las que depende. –

0

¿Puedo usar Grails en software propietario?

Pregunte Oracle, Grails se está ejecutando en Java. Podría estar restringido por derechos más altos, por lo que es posible que primero deba obtener una licencia de Oracle para crear su software específico. Mejor preguntar primero al vendedor de la plataforma.

[...] especificaciones Java son tecnología patentada que se deben autorizar directamente a partir de la iniciativa de especificaciones bajo cualquier términos elige la ventaja de especificaciones.

Ver Apache foundation resigns from Java community

Además depende de la licencia del paquete de Grails. Se publica bajo ASF 2.0 mientras escribe. Además, supongo que esta licencia se aplica a todo el paquete como lo sugiere el sitio web, pero debe verificar todo el código fuente por su cuenta si realmente desea confiar en esto, ya que el software no ofrece ninguna garantía. En caso de que la gente de Grails haya cometido un error al licenciar, recae en ti una parte mayor si la información que proporcionaron fue incorrecta.

Tenga en cuenta que usted está planteando la creación de su propio software. Ese es un trabajo por sí mismo, su negocio, y debe encargarse de todo lo legal que sea por su cuenta.

Nunca se puede confiar a cualquier comentario a menos que sea uno de un abogado que actúa nombre propio de verdad.

No es un plugin que podría ser útil para comprobar las condiciones de licencia por adelantado visibles: http://www.grails.org/License+Plugin

La licencia ASF 2.0 es una licencia de software libre, por lo que incluso si se tiene en cuenta que "amigable" con toda la actitud que muestran, tenga en cuenta que tiene cláusulas de terminación, así como GPL/LGPL. Esos son para proteger la libertad del software.

+0

Sí, las implementaciones específicas de Java son propietarias, es por eso que las personas no empaquetan Java con su software, sino que requieren que se instalen. como una precondición para usar su software. –

Cuestiones relacionadas