Es El JCP Un Organismo Que Crea Estándares Libres?
Total Page:16
File Type:pdf, Size:1020Kb
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 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. 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 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. 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 imple- mentaciones. 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