Es El JCP Un Organismo Que Crea Estándares Libres?

Estándares libres y Java: ¿Es el JCP un organismo que crea estándares libres?

II Congreso javaHispano, Móstoles, Madrid (España). Fecha: 15 / 12 / 2004

Abraham Otero Quintana / javaHispano El problema :

La comunidad del Software Libre “Java no es Software Libre” !Afortunadamente no lo es¡ Y esperemos que nunca sea...software

2 El problema

Java es un conjunto de especificaciones, no un conjunto de programas (software). Esto es una de las principales ventajas de la plataforma. Lo que cabe preguntarse es ¿Es java un conjunto de especificaciones/estándares libres?

3 Agenda

El Java Community Process. Estándares libres ¿por qué son importantes? ¿Está Java formado por estándares libres? Criterios de Perens Criterios de Krechmer Implementaciones de Referencia y Software Libre. Conclusiones.

4 ¿Qué es la plataforma Java?

Un conjunto de especificaciones que definen todas y cada una de las tecnologías de la plataforma. También definen el lenguaje, el formato binario de los bytecodes, la máquina virtual y las librerías estándar (JDK). Hay múltiples implementaciones de las especificaciones. Pero Java no es un software, una implementación concreta. 5 Ventajas de ser especificaciones:

Se fomenta la aparición de múltiples implementaciones de muy diversas características. Se fomenta la competencia entre las distintas implementaciones. Se evita el “vendor lock in”. Se evita quedar atrapado por un vendedor y verse obligado a pagar costosas renovaciones o actualizaciones. Si mi proveedor quiebra o abandona el producto, no me supone un gran problema: hay más proveedores para esa misma solución. 6 Java Community Process: organización

El Java Java Community Process es el organismo que crea y mantiene las especificaciones. Administrado por el Program Management Office (PMO), formado por empleados de Sun. Dos comités ejecutivos (CE) se encargan de aprobar las especificaciones: Uno se encarga de J2SE y J2EE y el otro de J2ME. Hay 16 miembros en cada comité: 10 miembros propuestos por el PMO, 5 por votación, 1 es siempre un representante de Sun. 7 Comité ejecutivo de J2ME

8 Comité ejecutivo de J2SE y J2EE

9 Java Community Process: organización

El resto de los miembros: Empresas: 5.000$ anuales de cuota, gratis si son licenciatarias de Sun. Organizaciones académicas y sin ánimo de lucro: un comité decide si han de pagar o no 2.000$. Individuos a título particular: siempre gratis.

10 Java Specification Request

Un Java Specification Request (JSR) define una tecnología de la plataforma. Constan de: Una especificación: un documento que describe la tecnología, su necesidad, y cómo afectará al resto de la plataforma. Una implementación de referencia (IR). Demuestra que la tecnología es factible. Un test de compatibilidad (TC): batería de pruebas que permiten verificar si una implementación cumple la especificación. 11 Java Specification Request

Evolución temporal:

12 Java Specification Request

13 Java Community Process

Umbrella Java Specification Request (UJSR): JSR que afectan a J2ME, J2SE, J2EE y los perfiles de J2ME. Sun tiene derecho de veto sobre ellos. Motivo: velar por la portabilidad y la compatibilidad hacia atrás. Para certificarse (pasar el TC) hay que pagar a Sun. Si una implementación no posee ánimo de lucro un comité decide si ha de pagar o no.

14 Java Community Process

La IR y TC se desarrollan bajo la licencia que decida el líder del grupo de expertos. Puede ser libre o propietaria, garantizando acceso RAND (Reasonable And Non-Discriminatory) . No todos los JSR son tan abiertos El JCP se define en un JSR que evoluciona. Lo descrito aquí es su versión 2.6, que está en vigor actualmente. Algunos JSR se rigen por versiones anteriores del JCP, no tan abiertas. 15 ¿Estándares o especificaciones?

Las especificaciones del JCP no están reconidas por ningún SDO. Sin embargo... Se definen entre más de 700 organizaciones e individuos (entre ellas todas las grandes empresas de informática menos Microsoft). Están abiertas a todo el que las quiera examinar. Cualquiera puede participar en el JCP. La propia bibliografía del mundo del SL las trata como estándares.

16 Agenda

17 Importancia de los estándares libres

El software libre por si sólo no genera Interoperabilidad. Los estándares son la base para conseguirla. Los estándares libres pueden implementarse libremente. No pueden tener barreas de tipo técnico para implementarlos: su contenido es público y accesible. Tampoco hay barreras de tipo económico o legal (patentes y copyright).

18 Importancia de los estándares libres

Los estándares propietarios, o el no uso de estándares, es un mecanismo para entorpecer e incuso anular el desarrollo de soluciones de terceros (en especial las libres). OpenOffice y los formatos OLE de Microsoft. Clientes libres de MSN y protocolos MSNpX. Un estándar libre fomenta la aparición de múltiples implementaciones de características heterogéneas. Esto beneficia al usuario final (evita el “vendor lock-in”).

19 Importancia de los estándares libres

Respetan la libertad de elección: podemos tomar hoy una decisión y mañana otra diferente. Si desarrollas una web con ASP .NET te verás atado a un servidor web y a un SO. Si lo haces con JSP o php podrás cambiar en cualquier momento de servidor web y/o de SO. Incluso las más “pequeñas” estandarizaciones libres han permitido enormes avances. TCP/IP, FTP, HTML, XML, SMTP... En su triunfo han sido clave la apertura del estándar, y el no tener que pagar ningún tipo de royalties por emplearlo. 20 SL =? libertad

¿Hasta que punto es “libre” un software que implementa un estándar propietario? Podremos modificar el código fuente, pero siempre dentro de la jaula (formato o protocolo) que define el estándar propietario. El dueño del estándar propietario podría poner trabas, o impedir, el desarrollo del producto libre.

21 SL =? libertad

Una licencia libre ya no garantiza que un desarrollo sea libre. Las licencias libres fallan a especificar y temas referentes a patentes y PI. Un software “libre”, en el sentido más general de la palabra, debe basarse en estándares libres. 22 ¿Qué es un estándar libre?

No hay una definición globalmente aceptada sobre qué es un estándar libre. El mayor intento de conseguirlo, dentro del mundo del SL está liderado por Bruce Perens. Actualmente es sólo un borrador. Otros trabajos interesantes al respecto: Robin Cover, Patents and Standars. Ken Krechmer, The Principles of Open Standars.

23 Estándares libres en la web

OpenStandards.org http://www.openstandards.org/

24 Estándares libres en la web

OpenStandards.net http://www.openstandards.net/

25 Estándares libres en la web

OpenStandards.org http://freestandards.org/

26 ¿Que criterios usamos?

Ninguno de ellos da criterios claros para determinar qué es un estándar libre, ni identifica qué estándares consideran libres y cuales no. Tampoco tienen una auténtica comunidad detrás, salvo freestandards.org Los criterios de Perens son los que tienen más reconocimiento dentro del mundo del SL. No obstante quizás estos criterios no sean suficientes. En nuestro estudio añadiremos algunas ideas de Krechmer a los criterios de Perens. 27 Agenda

28 Estándares abiertos (Perens)

Criterios de Perens Deben estar disponibles para todos para leer e implementar. Recomienda que la documentación y la IR estén disponibles en Internet. Cualquiera puede descargarse la documentación de un JSR e implementarlo. La IR de un JSR también es accesible. Deben maximizar la elección del usuario generando un mercado competitivo con un amplio rango de implementaciones. Evitar el “vendor lock-in” es una de los principales ventajas de la plataforma Java frente a otras tecnologías propietarias. 29 Estándares abiertos (Perens)

Sin Royalties: Debe ser posible implementarlo sin pagar royalties. Las patentes involucradas en el estándar deben ser RF (Royalty-Free). La certificación del estándar puede requerir pagar, pero se debería proporcionar un camino para la auto-certificación. Todas las patentes involucradas en un JSR deben “grant a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable license” (JSPA) a quien las implemente. La certificación requiere pagar de cuotas a Sun, pero existe un camino para la certificación gratuita de implementaciones sin ánimo de lucro.

30 Estándares abiertos (Perens)

No discriminación: no se puede favorecer a ninguna implementación; la certificación ha de ser justa y sólo basarse en motivos tecnológicos. Sólo los motivos tecnológicos se tienen en cuenta al pasar los TC. (Hasta el JCP 2.6 no era así: no podía haber implementaciones libres de los UJSR). Extensión o subconjunto: Los estándares abiertos se pueden extender u ofrecer en subconjunto, aunque en este caso puede negarse la certificación. Es posible implementar subconjuntos, superconjuntos, o modificaciones de las especificaciones del JCP que, en general, no es posible certificar. 31 ¡Esto es todo!

Las especificaciones de la plataforma Java cumplen los requerimientos de Perens Y en ocasiones aún van más allá (certificación completa grátis). En base a los criterios de Perens la plataforma Java, un conjunto de especificaciones que definen una serie de tecnologías, es libre.

32 Pero...

Estos requerimientos no son suficientes para considerar un estándar libre. La única libertad que realmente se tiene es la seguir o no seguir un estándar que podría haber sido definido por una sola parte interesada (empresa, organización o individuo), y no por todas las partes interesadas. Por ello tomaré prestados varios criterios de Krechmer.

33 Estándares abiertos (Krechmer)

Apertura: todas las partes interesadas pueden participar en el desarrollo del estándar. Cualquiera puede formar parte del JCP, a título personal o como representante de una empresa u organización. Aún sin estar directamente involucrado en el JCP, o en uno de sus JSR, se puede acceder al trabajo de todos los JSR mientras se están desarrollando, y enviar realimentación al grupo de expertos.

34 Estándares abiertos (Krechmer)

Consenso y proceso de decisión justo: se discuten todos los intereses y se llega a un acuerdo sin dominación. Puede emplearse una votación para encontrar una solución. Todos los intereses son discutidos en el JCP, y la votación, de los CE, decide qué se incorpora y qué no se incorpora a las especificaciones de la plataforma. Sin embargo... siempre hay un miembro de Sun en cada CE, y 10 miembros son propuestos por Sun (comunidad balanceada y representación regional), aunque deben de pasar una ratificación pública. 35 Estándares abiertos (Krechmer)

El PMO está compuesto por asalariados de Sun. Siempre hay un miembro de Sun en el comité de tres personas que decide si una organización sin ánimo de lucro puede o no pertenecer al JCP o pasar el TC gratis. El miembro de Sun de cada CE tiene derecho de veto sobre todos los UJSR. Este criterio no se cumple. La causa son los privilegios de uno de los participantes en el proceso de definición de las especificaciones: Sun Microsystems. 36 Una posible solución

Gestionar el JPC mediante un organismo independiente estilo ASF. Evitaría que la plataforma se mueva en una dirección que no es la más conveniente para todas las partes interesadas, por causa de intereses particulares. Elección democrática de todos los miembros de los CE. Sin derecho de veto. El líder de cada JSR tendría derecho a explotarlo económicamente.

37 Agenda

38 IR y Software Libre

La comunidad del SL se beneficiaría de poseer un código libre en el que basar sus implementaciones. Lo ideal sería que fuesen las propias IR: Son la primera implementación que se desarrolla. Las IR serían testadas por muchos desarrolladores Aumentaría su portabilidad y su calidad. Y la portabilidad y calidad de las demás implementaciones (Jason Hunter afirma que esto sucedió con Tomcat).

39 Licencias de las IR

La licencia de las IR son la principal fuente de críticas a Java La IR de J2SE: la más polémica.

NO LIBRES LIBRES

40 Java y SL

En general el SL goza de un excelente estado de salud en la plataforma Java: Hay gran cantidad de implementaciones libres, suficiente para construir una solución empresarial completa. Tercer lenguaje de programación en Sourceforge después de C y C++. ¿Por qué siendo tan activa la comunidad del Java SL las implementaciones del entorno base van tan lentas? 41 Java y SL

Quizás porque al haber JDKs gratuitos de calidad constastada... podemos hacer cosas más útiles:

42 IR y Software Libre

Buena parte de las IR polémicas pertenecen a Sun y su licencia es Sun Community Source License. “Prohíbe” las implementaciones que no sigan la especificación. Imposibilita para trabajar en desarrollos libres tras ver el código. Si la implementación es con ánimo de lucro paga cuotas a Sun

43 El problema según Sun

Sun defiende que esta licencia es necesaria para que Java no se fragmente. Una gran empresa, o la comunidad del SL, puede implementar una JVM desde cero. Esto hace que SCSL pierda bastante su sentido. ¿Realmente es necesaria SCSL para evitar la fragmentación de la plataforma en la práctica?

44 La realidad

No hay ningún indicio de fragmentación. Las implementaciones libres de J2SE (y otras) siempre tratan de adherirse a las especificaciones. La comunidad del software libre ha demostrado que sabe reconocer y respetar ciertas cosas qué no se deben bifurcar o pierden su valor. Aunque Sun mantenga lo contrario...

45 La realidad

46 ¿Entonces que pasa?

Las plataformas Intel y compatibles, junto con Línux, ganan terreno a SPARC y Solaris en el servidor. Aunque...

47 El problema real...

Sun, que tradicionalmente vivía del hardware, se reorienta hacia el software y los servicios: Java. Java Studio, Sun Java System Application Server ¿Java Desktop System?

¿¡Sun Java Workstation!?

48 El problema real...

Sun obtiene ingresos considerables por las licencias de Java. Su control sobre Java pueden ayudarle a posicionarse en un mercado emergente: J2ME. Java da prestigio a Sun. Siendo razonable no es lógico que Sun ceda el control sobre Java, y no explote una tecnología en la que ha invertido tanto.

49 ¿No existe una solución que satisfaga a ambas partes?

¡Sí!: la doble licencia: Un software se libera con dos licencias, una libre con un “copyleft” muy fuerte (GPL o similar) y una propietaria.

50 ¿No existe una solución que satisfaga a ambas partes?

Emplear la libre satisface todos los requerimientos del mundo del Software Libre. Sin embargo no será aceptable para muchas empresas: tendrían que liberar su código. Las empresas se verán obligadas a optar por la licencia propietaria: La mayor parte de ellas no estarán dispuestas a liberar su código.

51 ¿No existe una solución que satisfaga a ambas partes?

Sun: Sigue controlando el Java en el mundo empresarial. Gana el apoyo de la comunidad del Software Libre. Toda distribución de Línux incluiría una JVM. La comunidad del software libre: Obtiene un valioso código base para sus desarrollos. Deja de tener reticencias sobre si “algún día Sun empieza a cobrar por Java”. Tiene garantías de que Java no se vería afectado por cualquier adversidad afecte a Sun. 52 Agenda

53 Conclusiones

La plataforma Java, un conjunto de especificaciones que definen una serie de tecnologías, según los criterios (inacabados) del mundo del SL es libre. Las licencias de las IR, u otras implementaciones, carecen de relevancia en lo referente a esta libertad. Extendiendo estos criterios se identifica un problema: Los privilegios que Sun posee sobre el JCP. No obstante no hay constancia de que Sun los haya empleado con otro fin distinto que velar por la plataforma. 54 Conclusiones

Liberar el código SCSL bajo una doble licencia beneficia al mundo del SL y a Sun: Más desarrollos libres en y para Java. Más apoyo de la comunidad del SL. Mayor chequeo del código de las IR. Permitiría a Sun seguir controlando y obteniendo beneficios de Java a nivel empresarial. Las empresas no optarían por la licencia libre por el efecto virus.

55 Conclusiones

56 Disclaimer

Las ideas expuestas en esta presentación pertenecen al autor de la misma, no pudiendo en ningún caso considerarse una opinión o posicionamiento global de la asociación javaHispano.

Muchas gracias por su atención.

Contacto: Abraham Otero Quintana [email protected]