Etiquetas: j2se, Seguridad, applet, cryptoapplet, opensource
En ningún sitio he encontrado la licencia bajo la que se distribuye el código hasta que me he bajado el paquete, y ha resultado ser la GPL v2. Sería bueno ponerlo de forma más visible...
... o quizá no, puesto que, sin ánimo de tocar la moral y a fin de avisar, la descarga ofrecida viola los terminos de las licencias del software incluido.
No se si el anónimo de la noticia es parte de los autores o no, pero si es así... yo me remiraría el tema de las licencias de la distribución para no meterme en un lío, en concreto la GPL.
S!
Es el único applet de firma electrónica decente que he encontrado.
Funciona en casi todos los navegadores y sitemas operativos modernos.
Felicidades por la nueva versión
Hola greeneyed. La licencia de todos los proyectos que publica la UJI en proyectostic.uji.es está descrita aquí: http://proyectostic.uji.es/lic/. Es cierto que igual está un poco escondido.
¿Podrías detallar en qué términos viola la licencia GPL?
Gracias al anónimo anterior. Esperamos acortar el ciclo de publicación de versiones para que se pueda disfrutar antes de las nuevas mejoras ...
Una cosa.
¿Por qué no habéis eliminado el código de MSCAPI?
Ya que Java 6 es obligatorio, ¿por qué no se utiliza proveedor de seguridad "Windows-MY" que da acceso al keystore de windows?
Hola r.borillo,
La GPL especifica que los incluyes en tu descarga es parte del producto y como tal ha de cumplir la GPL o estar bajo otra licencia compatible. En la descarga se incluyen algunos .jar, por ejemplo, que están bajo licencia Apache, la cual no se incluye violando los terminos de la misma, y que además es incompatible con la GPL v2 que es la que usais para el Applet. También se incluye otra librería bajo la AGPL sin incluir la licencia, y no tengo muy claro que sea compatible con la GPL v2. Por último, también se incluyen librerias DLL de Microsoft sin su licencia correspondiente y me apuesto el desayuno que no es compatible con la GPL ya que, como mucho, seguramente sea una licencia de distribución de binarios.
En un vistazo rápido, esas son las violaciones más flagrantes, aunque hay librerías que no he mirado.
S!
Respecto a MSCAPI y CryptoApplet, Java 6 no es obligatorio. La distribución está preparada para funcionar con Java 5 y posteriores.
En un primer momento, si el applet detectaba que estabas utilizando Java 6, entonces cargada el proveedor de Sun con el Windows-MY. Durante las pruebas de compatibilidad con distintas tarjetas criptográficas detectamos que en algún caso había cosas que funcionaban bien con MSCAPI y no con el proveedor de Sun, así que decidimos ser prudentes y no realizar aún este cambio.
En cualquier caso, debido al EOL de Java 5 y para futuras versiones, nos estamos planteando pasar definitivamente a Java 6 y dejar de soportar Java 5.
Respecto al tema de las licencias, debo reconocer que no soy un experto sobre los requisitos mínimos a cumplir a la hora de distribuir el producto, así que agradezco tus comentarios greeneyed e intentaremos revisarlo en detalle para darle solución.
Saludos,
a ver si los expertos en el tema de criptografía nos aclaran:
1.- ¿Sirve este paquete para realizar autenticación mediante certificado, y posteriormente verificar dicho certificado a la autoridad certificadora?
2.- ¿Que diferencias o ventajas aporta esta librería frente a otras como Ecofirma o Viafirma?
Gracias
Eduard
No es una plataforma completa como viafirma, asffirma o @firma. Ecofirma no lo conozco.
Simplemente, un applet que puede realizar firmas en un navegador sobre ficheros o datos en varios formatos. Creo que permite también validar el certificado contra un OCSP.
Aún así, el servidor debería ser el responsable de validar que esa firma es correcta en la mayoría, siempre que ese sea el cometido de la aplicación.
Todas las plataformas que te he nombrado tienen su propio applet para realizar firmas. Yo he probado varios y el de cryptoapplet me convenció, sobre todo porque funcionaba casi siempre (navegadores/OS) lo cual te aseguro que no ocurre con otros.
Menudo tema este de las licencias, a mí también me esta dando dolores de cabeza con Form4G,
¿Alguien sabe si existe algún resumen o cuadro de compatibilidades que nos pueda servir de guía?.
Saludos cordiales,
Eduardo O. Frigerio.
Yo creo que greenyed está equivocado.
Ubuntu distribuye código GPL no ya con licencias opensource incompatbiles, sino con código propietario (drivers). Todo ello, se descarga en una ISO y no hay problema de licencias.
En cualquier caso, y según GNU:
"En sentido estricto, la GPL es una licencia del creador para otros, a fin de determinar lo que estos pueden hacer con el programa: uso, distribución y cambios. El creador mismo no se encuentra vinculado por la licencia, de manera que, haga lo que haga, no puede considerarse una «vulneración» de la GPL. De todos modos, si el creador hace algo que supondría una vulneración de la GPL si fuera otro quien lo hiciera, sin duda perderá su credibilidad moral ante la comunidad."
Vamos, que como autores, no están violando GPL, pues pueden hacer lo que les de la gana. Aún así, claro, se supone que nadie podría redistribuir el mismo paquete que ellos.
Otro tema es la MSCAPI.dll. Ahí, probablemente, estén violando la licencia de uso de Microsoft al distribuirla, pero eso no tiene nada que ver con la GPL. Quizás Microsoft permite que MSCAPI se distribuya como se quiera, no lo se.
La AGPL no es compatible con GPL 2, por lo que si tenéis librerías AGPL tendríais que pensar en dejar de utilizarlas. Yo no se cual es la que dice Greenyed. Se me ocurre Itext, pero mientras no uséis la versión 1.5.0, será LGPL.
En cualquier caso, quizás CryptoApplet podría tener una licencia LGPL, lo que haría que no hubiese este tipo de problemas. O también, añadir una claúsula a la GPL (como hacen varios) permitiendo que se redistribuya con las librerías que necesite.
Hola r.borillo,
¿Que diferencias hay entre vuestro proyecto y las librerías de IDEAS de la ACCV? y ¿No os ubiera resultado mas cómodo usar éstas últimas?
Saludos.
Yo creo que greenyed está equivocado.
Es posible, a veces pasa :).
Vamos, que como autores, no están violando GPL, pues pueden hacer lo que les de la gana. Aún así, claro, se supone que nadie podría redistribuir el mismo paquete que ellos.
Ellos pueden violar la GPL de su applet, ellos mismos ya que "simplemente" están distribuyendo algo sin una licencia válida, pero las que están violando realmente son las licencias del otro software que incluyen con su applet. Es decir, la licencia Apache del log4j, la AGPL del iText etc. etc. Y el problema es que todas a la vez no las pueden respetar.
Otro tema es la MSCAPI.dll... pero eso no tiene nada que ver con la GPL.
Puede que estén violando la de la librería de Microsoft, no se si requiere incluir la licencia y el copyright o no, pero tiene que ver con la la GPL por que ésta impone unas condiciones para "el paquete que distribuyes" y tampoco las están cumpliendo... y de hecho no las van a poder cumplir las dos puesto que no podrán "dar acceso a las fuentes".
Quizá la versión de iText esté bajo LGPL, pero ésta tampoco es compatible con la GPL, así que una u otra...
O también, añadir una claúsula a la GPL (como hacen varios) permitiendo que se redistribuya con las librerías que necesite.
Por un lado, una "GPL con clausulas" no es la GPL y hay que saber muy bien lo que se hace para no meter aun más el cazo. Por otro lado, la GPL o lo que fuera resultante afecta sólo al código del applet, pero no puede modificar las licencias de lo otro con lo que se distribuye, así que podría seguir habiendo problemas con las librerías. La licencia Apache es bastante laxa, pero si la versión de iText cae bajo la AGPL puede haber problemas. En todo caso habria que respetar las licencias y al menos incluir las menciones y textos apropiados en la distribución.
En cuanto a Ubuntu, pueden tener permiso de los propietarios del software para distribuir esas librerías o pueden optar por la via de considerar que la distribución es un "bundle" ya que Ubuntu como S.O. no creo que dependa de nada para funcionar que no sea GPL, así que el resto se considera que simplemente "viene por comodidad en el paquete pero no es parte integrante del producto cubierto por la licencia". Eso lo permite explicitamente la GPL. En cambio, el applet requiere de las librerías incluidas así que no puede optar por ahí, y tampoco creo que tengan permiso explícito Apache para distribuirlas, ya que si no, una referencia a dicho permiso estaría incluida en el paquete.
De todas formas, dado que no soy abogado especializado en el tema, no es un consejo legal para nadie. Lo mejor es suponer que no tengo ni idea, investigar uno mismo y hacer lo que cada uno crea... y luego asumir las consecuencias, of course :).
Me olvidaba. De todas formas, aunque uno como autor no "viole la GPL", ¿que sentido tiene distribuir un paquete bajo esa licencia si nadie más va a poder distribuirlo sin meterse en un lio legal? Son ganas de meter en problemas a tus usuarios.
si lo que buscas es compatibilidad entre SO/navegadores el applet de viafirma ofrece una de las mejores matrices de compatibilidad.
http://www.viafirma.com/informacion/tecnicas/#matriz-compatibilidad
Joer pues sí, me ha pillado el certificado en el Mac :-)
http://viafirma.viavansi.com/viafirma
Hola logongas,
Aunque no he utilizado IDEAS, la descripción que reza en la web de la ACCV es:
La librería IDEAS es la API desarrollada en Java para facilitar la integración de aplicaciones con los certificados de la ACCV.
Viendo la distribución, parece que permite realizar firmas RAW y CMS sobre datos, interactuando con certificados disponibles en distintos almacenes (he podido ver el soporte para PKCS11).
El punto fuerte de CryptoApplet, al margen de la gestión y acceso a certificados y dispositivos criptográficos, son los formatos de firma soportados. CryptoApplet permite generar formatos de firma RAW, CMS, XML Signature, XAdES (EPES con jXAdES para Facturae y X-L con OpenXAdES/MITyC), ODF y PDF. Por defecto te funcionará con el DNIe y con la ACCV, pero puedes configurar cualquier CA.
Otro aspecto interesante es que tiene una entrada/salida "plugable", es decir, que los datos de entrada los puedes leer de donde quieras (del DOM de la página, de una URL, del sistema de ficheros, etc) y el resultado lo puedes escribir donde quieras (puedes implementar un conector a tu gusto).
Por último, su uso no se limita al applet y puedes usar sus librerias criptográficas en cualquier aplicación de servidor (validación de datos, firma en servidor, etc).
Ubuntu distribuye código GPL no ya con licencias opensource incompatbiles, sino con código propietario (drivers). Todo ello, se descarga en una ISO y no hay problema de licencias.
Si recuerdo bien Ubuntu te informa sobre la licencia de cada driver propietario que intentes instalar. Pienso que no es que no se pueda incluir si no que se debe ser claro.
LGPL si es compatible con GPL, Greenyed. De hecho, la propia licencia dice que cualquier software LGPL es automaticamente GPL.
Itext 5.0 es AGPL. Versiones anteriores como la que incluye CryptoApplet son LGPL o MPL.
El problema de CryptoApplet podría solucionarse casi completamente actualizando la licencia a GPLv3. Aparte de que todo software que se distribuya debe inclir su licencia, por supuesto, y que la librería de Microsoft no se puede incluir.
GPLv3 es compatible con Apache v2.0, con GPLv2, con AGPLv3 (gracias a una clausula en la propia licencia) y con LGPLv2.
En cuanto a ViaFirma, es desde luego una opción bastante buena, si puedes pagarla y si necesitas una plataforma correcta. La versión libre no comercial es más vieja y no tan compatible.
Hola josuealcalde.
Muchas gracias por tus interesantes aclaraciones.
Es cierto que en ocasiones, te centras en los aspectos técnicos para ofrecer una buena solución y hay detalles que se escapan. El de la licencia y la DLL de Microsoft son un claro ejemplo...
En cualquier caso, pondremos solución para que no tenguais problemas si decidis utilizarlo :)
LGPL si es compatible con GPL, Greenyed. De hecho, la propia licencia dice que cualquier software LGPL es automaticamente GPL.
Esas son afirmaciones muy imprecisas que realmente no aclaran nada. El software LGPL no es GPL, es LGPL. Las condiciones de distribución son diferentes así que no son lo mismo. Sí, la LGPL v3 suplementa la GPL v3 pero decir que el software LGPL es automáticamente GPL es engañoso. Si no, no habría dos licencias distintas. Y eso si estamos hablando de la v3, que todavía hay mucho software con GPL v2 y LGPL v2.1
GPLv3 es compatible con Apache v2.0, con GPLv2, con AGPLv3 (gracias a una clausula en la propia licencia) y con LGPLv2.
Según la propia GNU: Please note that GPLv3 is not compatible with GPLv2 by itself. However, most software released under GPLv2 allows you to use the terms of later versions of the GPL as well.
Así que no, por defecto la GPL v3 no es compatible con la v2, aunque sí lo es en la mayoría de casos. si el software GPL v2 tiene la clausula que permite utilizarlo según versiones posteriores de la licencia. Si no, nada.
Exactamente lo mismo con LGPL v3 con GPL v2. La LGPL v 2.1 sí es compatible con GPL v2, sin condicionantes, y en cambio la AGPL v3 no es compatible, de ninguna manera, con GPLv2 y eso es a lo que yo me refería.
Y seguramente gran parte de los problemas se arreglarían pasando a v3 de la GPL, pero el hecho es que está bajo la v2 y eso causa los problemas descritos. Aun así, pasar a la v3 no lo solucionaría todo y por eso creo que es mejor que se lo miren con calma y encuentren su propia solución satisfactoria. El "negocio" de recomendar soluciones es peliagudo y por eso prefiero abstenerme, sobretodo en un tema con implicaciones legales y tan complejo como licencias etc.
Escribe tu comentario