software libre, estándares libres y la plataforma...

Abraham Otero QuintanaAbraham Otero [email protected]@javahispano.org

Software Libre, estándares libres Software Libre, estándares libres y la plataforma Javay la plataforma Java

e-Gallaecia 2004e-Gallaecia 2004

22

El problema :El problema :

Comunidad del Software Libre:Comunidad del Software Libre:

““Java no es Software Libre”Java no es Software Libre”

!Afortunadamente no lo es¡!Afortunadamente no lo es¡

Y esperemos que nuncaY esperemos que nunca sea... sea... softwaresoftware

33

El problema :El problema :

Java es un conjunto de especificaciones de una serie de tecnologías, no un conjunto de programas (software).

Y ello, como veremos, es una de las principales ventajas de la plataforma que nunca se debería perder.

Si no es software menos puede ser “Software Libre” (SL).Lo que cabe preguntarse es ¿Es java un conjunto de especificaciones/estándares libres?

44

AgendaAgenda

La plataforma Java y el Java Community Process.Estándares libres y su importancia.¿Está Java compuesto por estándares libres?.

Criterios de PerensCriterios de Krechmer

Implementaciones de Referencia y Software Libre.Conclusiones.

55

¿Qué es la plataforma Java?¿Qué es la plataforma Java?

Java no es un producto, un software, Java es un conjunto de especificaciones.

Estas especificaciones definen todas y cada una de las tecnologías de la plataforma: JSP, Servlets, EJB, MIDlets...También definen el lenguaje, el formato binario de los bytecodes, la máquina virtual y las librerías estándar (JDK).

Ventajas de ser especificaciones:Se fomenta la aparición de múltiples implementaciones con un amplio rango de precios y características.Se fomenta la competencia entre los distintos vendedores.

66

¿Qué es la plataforma Java?¿Qué es la plataforma Java?Se evita el “vendor lock in”.

Se puede cambiar de un producto a otro equivalente en cualquier momento, sin modificar el código. No se queda atrapado por un vendedor y obligado a pagar costosas renovaciones o actualizaciones de los productos.Que el proveedor de la solución por la que se ha apostado quiebre, o simplemente deje de darle soporte, no supone un grave problema: hay más proveedores que ofrecen otras implementaciones de la misma solución.

El Java Java Community Process [1] es el organismo que crea y mantiene las especificaciones.

Por lo tanto controla y dirige la evolución de la plataforma.

77

Java Community Process: organizaciónJava Community Process: organización

Administrado por el Program Management Office (PMO).Órgano 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.J2ME requiere un comité para sí sólo debido al vertiginoso desarrollo que tienen estas tecnologías.

Hay 16 miembros en cada comité: 10 miembros propuestos por el PMO, 5 por votación, 1 es siempre un representante de Sun.

88

Java Community Process: organizaciónJava 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 (comunidad SL):Un comité de tres personas decide si han de pagar o no 2.000$

Individuos a título particular:Gratis.

Es posible participar en una (sólo una) especificación sin pertenecer al JCP:

Java Specification Participation Agreement for an Individual Expert Group Participant

99

Java Specification RequestJava Specification Request

Un Java Specification Request [2] (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 o no con la especificación.

1010


Fases de todo JSR:

1111


Evolución temporal:

1212


1313

Java Community ProcessJava Community Process

Umbrella Java Specification Request (UJSR):JSR que afectan a J2ME, J2SE, J2EE y los perfiles de J2ME.Para aprobarse requieren al menos 5 votos positivos, y 2/3 de los emitidos han de ser de aprobación.Sun tiene derecho de veto sobre ellos.

Motivos: son JSR que afectan a partes críticas de la plataforma. Cambios en ellos podrían afectar a la portabilidad de la plataforma, o a la compatibilidad hacia atrás. Sun justifica sus privilegios para poder velar por Java.

Para pasar los TC (certificación) hay que pagar a Sun.Si una implementación no posee ánimo de lucro un comité decide si ha de pagar o no (Ej.: JOnAS y Gerónimo se certificarán gratis).

1414

Java Community ProcessJava Community ProcessLa IR y TC se desarrollan bajo la licencia que decida el líder del grupo de expertos.

Puede ser tan libre como el quiera (Tomcat, licencia Apache) o propietaria, garantizando acceso RAND al código fuente (Reasonable And Non-Discriminatory) .

No todos los JSR son tan abiertosEl JCP se define en un JSR que evoluciona.Lo descrito aquí es su versión 2.6[3], que está en vigor actualmente.Algunos JSR se rigen por versiones anteriores del JCP, no tan abiertas. Es de esperar que cuando haya revisiones de mantenimiento se actualicen a la última versión del JCP.

1515

Estándares vs especificacionesEstándares vs especificaciones

Definiciones:Un estándar es una tecnología, formato o método desarrollado y adoptado a través de un proceso abierto de consenso, bajo la guía de cuerpos nacionales (ANSI, BSI,...) o internacionales (ISO, IEEE,...) de estándares.Una especificación es un conjunto de documentos desarrollados por un grupo dentro de la industria, pero sin guías o procedimientos formales que aseguren que el trabajo está abierto a cualquier otra parte interesada, o abierto para su revisión y comentario durante el desarrollo (IETF, WC3, OMG).

1616

Estándares vs especificacionesEstándares vs especificacionesEn algunas definiciones se exige que un estándar esté aprobado por un organismo reconocido oficialmente; en otras no se especifica el tipo de organismo que debe reconocerlo.En algunas definiciones a una especificación sólo se le requiere que sea: “un documento declarando requerimientos”.

En algunas ocasiones a un estándar sólo se le requiere que “esté creado a través de un procedimiento abierto que garantice que se escucharán toda las partes interesadas y se llegará a un consenso”.

1717

¿Estándares o especificaciones?¿Estándares o especificaciones?Las especificaciones del JCP:

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, y por lo tanto en la definición y evolución de la plataforma.Incluso sin pertenecer al JCP se puede opinar y participar.

No parece justo caracterizar de “especificación” (al menos según cierta bibliografía), a algo que es consensuado entre tantas partes, con garantías de acceso, transparencia, y con posibilidad de participación sin discriminación en su construcción.

1818

¿Estándares o especificaciones?¿Estándares o especificaciones?

Según algunas definiciones las especificaciones Java podrían caracterizarse de “estándares de facto”.Evitaremos entrar más en discusiones linguísticas y, dado el carácter consensuado y abierto de las especificaciones del JCP las trataremos como “estándares”, aún cuando no estén reconocidas por organismos de estándares oficiales.

El motivo principal para ello es la lentitud de la evolución de los estándares en los organismos oficiales.

En su día Sun consideró llevar a ISO las especificaciones Java. Se descartó porque ralentizaría demasiado la evolución de la plataforma.

1919

AgendaAgenda




2020

Importancia de los estándares libresImportancia de los estándares libres

El software libre por si sólo no genera Interoperabilidad (capacidad de un sistema para trabajar con otro). Los estándares son la base para conseguirla.Los estándares libres pueden implementarse libremente.

Su contenido es público y accesible. No hay barreas de tipo técnico para implementarlos.Tampoco hay barreras de tipo económico o legal (patentes y copyright) que impidan su implementación, algo casi imprescindible para el mundo del SL, que no se puede permitir ni pagar royalties ni largos juicios.

2121


Un estándar libre respeta la libertad de elección: podemos tomar hoy una decisión y mañana otra diferente.

Si desarrollo una web con ASP .NET te verás atado a un servidor web y a un sistema operativo.Si lo haces con JSP o php podrás cambiar en cualquier momento de servidor web (múltiples vendedores) y/o de sistema operativo.

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.

2222

Importancia de los estándares libresImportancia de los estándares libresLos 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). Ej.:

Los desarrolladores de OpenOffice se ven obligados a hacer reingeniería inversa para acceder a los formatos OLE de Microsoft. Lo mimo ocurre con los clientes libres de MSN y el protocolo MSNp10.Microsoft podría impedir la conexión de terceras partes a la red de MSN, inutilizando multitud de clientes libres de su red.

Un estándar libre fomenta la aparición de múltiples implemen-taciones de características heterogéneas (libres y comerciales).

Esto beneficia al usuario final (se evita el “vendor lock-in”).

2323


Reflexión: ¿Hasta que punto es “libre” un software que implementa un estándar propietario?

Podremos modificar el código fuente en detalles menores, pero lo hacemos 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.

Un software “libre”, en el sentido más general de la pa-labra, debe basarse en estándares libres.

2424

¿Qué es un estándar libre?¿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 Software Libre, está liderado por Bruce Perens.

Bruce Perens es uno de los principales líderes del movimiento del Sofware Libre, en el cual milita desde 1987, cofundador de Open Source Iniciative, creador del manifiesto “Open Source definition”, y próximo al entorno de Debian.

Actualmente hay un borrador con el trabajo realizado hasta la fecha en [4].

2525


Otros trabajos interesantes al respecto:Ken Krechmer, The Principles of Open Standars [5]

Krechemer no es un activista del Software Libre, y su documento aborda estándares en general, no sólo estándares referentes a las TIC. Por ello alguna de sus ideas no son totalmente extrapolables a este campo. No obstante recoge ideas interesantes, no presentes el borrador de Perens.

Robin Cover, Patents and Standars [6]Extenso documento en el que analiza cómo las patentes dañan a los estándares abiertos. Da una definición personal de estándar abierto, más exigente que la de Perens, pero sin detallarla, ya que ese no es el objetivo de su trabajo.

2626


Estándares libres en la web:OpenStandards.orghttp://www.openstandards.org/ [7]

En la actualidad abandonado, nunca parece haber tenido actividad.

OpenStandards.nethttp://www.openstandards.net/ [8]

Escaparate de noticias de otros sitios web y almacén de enlaces. Carece de contenidos propios.

2727


Estándares libres en la web:Free Standards Grouphttp://freestandards.org/ [9]

Portal dedicado a crear estándares para el mundo Línux. Poseen certificaciones con cierto reconocimiento: LSD, OpenI18n, OpenPrinting...

Ninguno de ellos da criterios claros para determinar qué es un Ninguno de ellos da criterios claros para determinar qué es un estándar libre, ni identifica qué estándares consideran libres y estándar libre, ni identifica qué estándares consideran libres y cuales no, como OSI y FSF hacen con las licencias de software.cuales no, como OSI y FSF hacen con las licencias de software.Están lejos de ser la “OSI” o “FSF” de los estándares.Están lejos de ser la “OSI” o “FSF” de los estándares.

2828


Los criterios sobre los que trabaja Perens constituyen el intento más serio de la comunidad del Software Libre para definir qué es un estándar libre.

Es el documento que actualmente tiene más reconocimiento dentro del mundo del Software Libre.

No obstante quizás estos criterios no sean suficientes.En nuestro estudio añadiremos algunas ideas de Krechmer a los criterios de Perens.

Reflexión: es curioso que la comunidad del Software Libre pida tanto al software para ser libre, y tan poco a un estándar.

2929

AgendaAgenda




3030

Criterios de PerensCriterios de Perens

Analicemos con criterios de Perens los JSR:Disponibilidad:

Disponibles para todos para leer e implementar. Recomienda que la documentación y la IR del estándar estén disponibles en Internet.Cualquiera puede descargarse la documentación de un JSR e implementarlo. La IR de referencia de un JSR siempre es acceible .

Maximizar la elección del usuario final:Los estándares abiertos deben generar un mercado competitivo permitiendo un amplio rango de implementaciones, con precios desde muy altos a nulos.Evitar el “vendor lock-in” es una de los principales ventajas de la plataforma Java frente a otras tecnologías propietarias.En la plataforma hay costosas implementaciones empresariales (Ej: BEA WebLogic, IBM WebSphere ~100.000 $ por CPU) y libres (Ej: JBoss, JOnAS).

3131

Criterios de PerensCriterios de PerensSin Royalties:

Debe ser posible implementar una especificación sin pagar royalties. Las patentes involucradas en el estándar deben ser RF (Royalty-Free). La certificación del estándar puede requerir pagar. Se debería (no imprescindible) 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” [10] a quien las implemente.La certificación requiere pagar de cuotas a Sun, pero los TC son accesibles gratuitamente para individuos y organizaciones sin ánimo de lucro [10]. Es posible auto-certificarse.Existe un camino para la certificación gratuita de implementaciones libres (JOnAS y Geronimo se certificarán gratis).El código de la IR (y TC) debe estar disponible bajo condiciones RAND [10] (o más permisibles) para basar en ella otras implementaciones.

3232

Criterios de PerensCriterios de PerensNo discriminación:

No se puede favorecer a ninguna implementación sobre otras: 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 (Ej.: En [11] se recogen múltiples variaciones del lenguaje Java, bytecode y JVM , normalmente desarrolladas con fines investigadores).En general no es posible certificar subconjuntos, sí superconjuntos de ciertas especificaciones (Ej.: J2EE), lo que permite a los diferentes vendedores diferenciar sus productos.

3333

Criterios de PerensCriterios de PerensDefensa contra prácticas predatorias (es una concesión más que un requerimiento):

Los estándares pueden protegerse contra modificaciones por parte de terceras partes para evitar prácticas “embrace-and-extend” (Un vendedor predominante crea una extensión de un estándar incompatible con el original, e impide mediante patentes y copyright que los demás vendedores implementen estas extensiones. Esto provoca que las implementaciones de los demás vendedores no sean compatibles con las vendedor predominante y permiten a este crear un monopolio sobre el estándar). Dentro de las propias especificaciones no se identifican restricciones en este sentido.No obstante la certificación de las implementaciones, así como la propiedad de Sun de la marca “Java” y términos relacionados, términos que sólo se pueden emplear tras certificarse, defienden la plataforma de este tipo de prácticas (Ej.: JVM de Microsoft [12]).

3434

¿Cumple Java con los criterios de Perens?¿Cumple Java con los criterios de Perens?

El Draft de Perens es el intento más serio y consensuado para definir qué es un estándar libre dentro del mundo del Software Libre.

Las especificaciones de la plataforma Java cumplen sus requerimientos (y en ocasiones aún van más allá).

En base a los criterios de Perens la plataforma Java, un conjunto de especificaciones que definen una serie de tecnologías, es libre.

Esto no quiere decir que todas las implementaciones de cada tecnología lo sean. En general las hay de ambos tipos.

3535

¿Cumple Java con los criterios de Perens?¿Cumple Java con los criterios de Perens?

Estos requerimientos no son suficientes para considerar un estándar libre.

Podrían definir un estándar “accesible”: puedo verlo e implementarlo libremente.Esto no es suficiente. 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.

Para completar el estudio añadiremos varios criterios de Krechmer a los de Perens.

3636

Criterios de KrechmerCriterios de Krechmer

Apertura:Todas las partes interesadas pueden participar en el desarrollo del estándar.Cualquiera puede formar parte del JCP, ya bien sea a título personal o como representante de una empresa u organización.Incluso sin participar en el JCP se puede participar en un JSR.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.Este criterio se cumple.

3737


Consenso y proceso de decisión justo:Todos los intereses son discutidos y se llega a un acuerdo sin dominación. Una votación puede ser empleada para encontrar una solución.Todos los intereses son discutidos en el JCP, y la votación, de los CE, es la que finalmente decide qué se incorpora y qué no se incorpora en las especificaciones de la plataforma.Sin embargo siempre hay un miembro de Sun Microsystems en cada CE, y de los restantes 15 miembros 10 son propuestos por Sun (criterios: comunidad balanceada y representación regional), aunque deben de pasar una ratificación pública.

3838

Criterios de KrechmerCriterios de KrechmerEl PMO, aunque es un mero órgano administrativo, 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 gratis al JCP o pasar el TC sin pagar.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.

3939


La solución:Gestión del JPC por un organismo independiente estilo Apache Software Foundation.

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 los intereses particulares de una empresa.

Elección democrática de todos los miembros de los CE.Sin ningún tipo de veto: que a comunidad decida lo que quiere hacer.

4040

AgendaAgenda




4141

IR y Software LibreIR y Software Libre

La comunidad del Software Libre se beneficiaría de poseer un código libre en el que basar sus implementaciones de las especificaciones.Lo ideal sería que fuesen las propias IR.

Son la primera implementación que se desarrolla: se dispondría del código rápidamente.La libertad de la IR permitiría que esta fuese testada por muchos desarrolladores, lo que aumentaría su portabilidad y su calidad, así como la portabilidad y calidad de las demás implementaciones.

Jason Hunter afirma que desde que gracias a que Tomcat es libre se han eliminado muchos bugs de portabilidad en los motores de Servlets.

4242

IR y Software LibreIR y Software LibreLa licencia de las IR son la principal fuente de críticas a Java

Java no es un software, son unas especificaciones. Alguna de sus implementaciones no, otras sí, pero esto no tiene que ver con la libertad de las especificaciones (que según Perens sí son libres).La IR de J2SE: la más polémica.

Libres: Kaffe [13], GCJ [14], GNU Classpath [15], Japhar [16], Jikes [17]...No libres: Sun, IBM, BlackDown, Bea...

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 [18].Tercer lenguaje de programación en sourceforge después de C y C++.

4343

El SoftwareEl SoftwareBuena parte de las IR polémicas pertenecen a Sun y su licencia es Sun Community Source License [19].

“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

Danese Cooper (responsable de la relación de Sun con el SL) tras varias reuniones con representantes del mundo del Software Libre han concluido que: “compatibilidad obligatoria y SL no pueden coexistir”.

Esto, desde un punto de vista teórico (definición de SL) es obvio.

4444

El SoftwareEl SoftwarePero ¿es necesaria SCSL para velar por la fragmentación de la plataforma en la práctica?

Sun defiende la necesidad de la licencia para defender la plataforma de la fragmentación (JVM de Microsoft).Pero las grandes empresas, o la comunidad del SL, pueden implementar una JVM desde cero, con lo cual este argumento pierde bastante sentido.No hay ningún indicio de fragmentación: las implementaciones libres de J2SE (y otras especificaciones) siempre tratan de adherirse a las especificaciones.

4545

El SoftwareEl SoftwareLa comunidad del software libre ha demostrado que, a pesar de su afán diversificador (Ej: múltiples distribuciones de Línux...), sabe reconocer y respetar ciertas cosas qué no se deben bifurcar o pierden su valor (...pero un sólo kernel, se mantiene la compatibilidad).

En la práctica no hay indicios de que liberar el código fuente de las IR suponga un riesgo de fragmentación para la plataforma.

4646

El SoftwareEl Software

¿Cual es el problema entonces?La realidad es otra: Sun necesita Java, y necesita controlar Java (a nivel empresarial):

Las plataformas Intel y compatibles, junto con Línux, están comiendo el terreno de los servidores SPARC y Solaris, y es de prever que esta tendencia continúe los próximos años. Los últimos resultados económicos de Sun no han sido nada positivos.En respuesta a esto Sun, una compañía que tradicionalmente vivía del hardware, está tratando de reorientar sus negocios hacia el software y los servicios.El centro del negocio del software en Sun es Java: Java Entreprise System, Java Studio Creator, Sun Java System Application Server, Java Desktop System... (¡En el último la palabra Java se incluyó en el nombre sólo como marketing!)

4747

El SoftwareEl SoftwareSin embargo ni el servidor de aplicaciones ni el IDE de Sun poseen una cuota de mercado considerable, y el éxito de Java Desktop System y Java Entreprise System está por ver.Sun actualmente obtiene una gran cantidad de ingresos por las licencias de su tecnología. Así mismo su control sobre Java pueden ayudarle a posicionarse en un mercado emergente: J2ME (http://java.com/, sitio web de Sun enfocado al cliente, está muy orientado a este mercado).Siendo razonable (las empresas no son ONGs) no es lógico que Sun ceda el control sobre Java, y no explote una tecnología en la que ha invertido tanto; y menos dada su situación actual.

Conclusión: el mundo de Software libre busca un control de Java que probablemente Sun no se pueda permitir ceder en este momento sin dañar gravemente sus intereses.

4848

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

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

Ej.: MySQL (MySQL AB), BerkleeyDB (Sleepycat Software Inc), Qt (TrollTech As).

Emplear la libre satisface todos los requerimientos del mundo del Software Libre. Sin embargo no será aceptable para muchas compañías, que verían su código infectado (efecto “virus”) por la licencia con copyleft y tendrían que hacerlo libre. Estas se verán obligadas a optar por la licencia propietaria, y de este modo Sun seguiría obteniendo beneficios y controlando Java a nivel empresarial.

4949

¿No existe una solución que satisfaga a ¿No existe una solución que satisfaga a ambas partes?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 en el cual basar sus desarrollos.Dejaría de tener reticencias sobre si algún día Sun empieza a cobrar por Java.Tendría garantías de que Java no se vería afectado por una hipotética opa hostil, o cualquier otra adversidad, que afecte a Sun.

5050

AgendaAgenda




5151

ConclusionesConclusiones

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.

A pesar de ello no hay constancia de que Sun los haya empleado con otro fin distinto que velar por la plataforma.

5252

ConclusionesConclusiones

Liberar e código SCSL bajo una doble licencia (¿SCSL y GPL?) beneficiaría al mundo del SL y a Sun:

Haría que Java fuese mejor acogido y tuviese más apoyos en la comunidad del SL, con los consecuentes beneficios para la plataforma, y por extensión para Sun.

Más desarrollos libres en y para Java, y más apoyo de la comunidad del SL.Mayor chequeo del código, que incrementaría la portabilidad y fiabilidad de las IR, y por extensión de todas las implementaciones que se basen en la 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.Sun gana el apoyo del mundo del SL sin perder su control sobre la empresa.

5353

Referencias (I)Referencias (I)[1] Java Community Process, http://jcp.org.[2] Java Specification Request, http://jcp.org/en/jsr/overview.[3] JCP 2.6, http://jcp.org/en/jsr/detail?id=215.[4] Bruce Perens et al. Open Standards Principles and Practice.http://perens.com/OpenStandards/Definition.html.[5] Ken Krechmer. The Principles of Open Standars, http://www.ses-standards.org/library/krechmer.pdf.[6] Robin Cover. Patents and Standars, http://xml.coverpages.org/patents.html.[7] OpenStandards.org. http://www.openstandards.org/.[8] OpenStandards.net. http://www.openstandards.net/.[9] Free Standards Group. http://freestandards.org/.[10] Java Specification Participation Agreement, http://jcp.org/aboutJava/communityprocess/JSPA2.pdf.[11] Múltiples variaciones del lenguaje Java, bytecode y JVM. http://www.robert-tolksdorf.de/vmlanguages.html,

5454

Referencias (II)Referencias (II)[12] Declaración de James Gosling en el juicio contra Microsoft por su implementación de la JVM. http://java.sun.com/lawsuit/82198gosling.html[13] Kaffe, http://www.kaffe.org[14] GCJ, http://gcc.gnu.org/java/[15] Classpath, http://www.gnu.org/software/classpath/[16] Japhar, http://www.japhar.org[17] Jikes, http://www-124.ibm.com/developerworks/oss/jikesrvm/[18] Alberto Molpeceres y Martín Pérez. Arquitectura empresarial y software libre, J2EE. http://www.javahispano.org/articles.article.action?id=70.

[19] Sun Community Source License (SCSL), http://www.Sun.com/software/communitysource

[20] Mikko Valimaki, Dual Licensing in Open Source Software Industry. http://www.soberit.hut.fi/~msvalima/dual_licensing.pdf

Abraham OteroAbraham Otero [email protected]@javahispano.org

GraciasGracias

software libre, estándares libres y la plataforma...

Documents