18/05/2009
02/06/2009
18/06/2009
Bueno, pues se está montando una en The Server Side bien, bien buena.
http://www.theserverside.com/news/thread.tss?thread_id=50727
SpringSource, la compañía fundada por Rod Johnson (fundador de Spring Framework), ha decidido cambiar la política según la que publicará nuevas versiones de Spring al público en general.
La nueva política resulta como sigue (resumiendo todo el contenido de la política y de los comentarios de Rod Johnson en el propio thread de TSS):
Como veis, se trata de un cambio muy grande, y de un auténtico problema. Si extrapolamos estas condiciones al período entre la versión 2.0 y la 2.5, hubiera significado que los "no suscriptores" habríamos tenido la 2.0 (octubre de 2006), la 2.0.1 y la 2.0.2 (enero de 2007)... y después habríamos tenido que esperar hasta noviembre de 2007, 10 meses, a que saliese la 2.5, para ver corregidos los bugs que se hubiesen encontrado por el medio. No habríamos dispuesto de las versiones entre 2.0.3 y 2.0.8.
Por los comentarios en TSS se extrae que mucha gente está enfadada (lógico, opino yo), y sobre todo temen por el futuro de Spring. Si este es el paso que dan ahora... ¿cuál será el siguiente? Está claro que SpringSource tiene derecho "legal" a hacer esto pero... ¿es limpio cambiar así el juego, cuando precisamente lo abierto y fácilmente disponible de tu software es lo que lo ha hecho llegar a una situación de éxito que roza el monopolio?
Esperemos que SpringSource, vista la tremenda reacción que está teniendo este movimiento y las dificultades que está teniendo Rod para defenderse en TSS, se repleantee esta nueva política. El riesgo es muy grande, y hoy en día nuestra industria sin Spring... tiene un problema.
¿Cómo lo veis?
Etiquetas: j2se, java, spring, springsource, licencias
A mi me parece lo mismo que pasó con Ext JS. El modelo Open Source puro a veces choca con el modelo empresarial y, se den cuenta o no los que lo hacen, estas cosas son para "forzar" a tus usuarios a que pasen a ser "de pago" de alguna forma. A mi me suena a eso de "puedes hacer lo que quieras, mientras sea lo que yo digo".
Legalmente es posible, para todo lo demás: MasterCard ;).
Otro punto importante en este caso es... Spring no es una especificación pública, lo cual tendría otras pegas, así que solo hay una implementacion. Antes la respuesta típica era... "pero es un producto open source y las cosas se arreglan o las puedes montar tu...". Llegados a este punto, ¿No es igual de malo ahora depender de un producto que se comporta con las versiones como uno comercial? Las especificaciones tienen sus cosas malas, y muchas que me lo digan a mi que cada vez que veo a los de Web de Sun les doy la vara, pero al menos si un producto te la juega, como es para mi esté caso, "siempre" puedes cambiar a otro (si está bien hecha, claro :) ).
En fin, a mi Pling, por que no uso Spring :) j/k
El riesgo es muy grande, y hoy en día nuestra industria sin Spring... tiene un problema.
Yo no estoy de acuerdo con eso, si hay que dejar de usar Spring pues se usa otro framework y listo, que otra cosa no, pero en Java hay frameworks web hasta aburrir.
Cuando veo una decisión tan drástica, deduzco problemas económicos en la empresa. Es decir, más un "Achicad! Achicad! que el barco se hunde!", que un "Vamos a matar a la gallina a ver si le sacamos todos los huevos que lleva dentro".
No se si me explico :P
> [...] pero en Java hay frameworks web hasta aburrir
Spring no es un framework web, aunque tiene un módulo para ello. De hecho, yo llevo usándolo varios años y específicamente he decidido no usar la parte web porque me parece muy mala (es una opinión). El contenedor IoC es mucho más importante en el concepto de Spring. Y eso sí es realmente bueno.
Y no... desgraciadamente hoy por hoy, no hay ningún framework "de infraestructura" en Java que cubra las funcionalidades de Spring: desde sencillez de uso hasta transaccionalidad, pasando por integración con Hibernate, configuración, AOP, etc. Es realmente bueno, y a Guice aún le falta mucho para llegar ahí.
Y sobre "usar otro framework"... eso lleva tiempo. Formar a la gente es tiempo. Aprender es tiempo. Romper una inercia es tiempo. Y tiempo es dinero. Y hoy por hoy en España, Spring... bueno, no hay más que mirar infojobs. Está claramente en el "paquete básico de conocimientos".
Cualquier persona que ha escrito un sistema Open Source entenderia los problemas de mantenerlo, especialmente con el tiempo, y las versiones pasadas. No se si lo haria como lo han hecho Spring, pero bueno. El codigo es libre todavia.
Los usuarios tienen el derecho de estar enfadados con una situacion asi? La gran mayoria no hacen nada para contribuir al proyecto y por eso el proyecto no debe nada a ellos, punto (aka en ingles "freeloaders"). Esperan que esos programadores siguen haciendolo asi para siempre sin recibir nada, y dicen "esta bien para ellos recibir dinero para su gran trabajo" pero no van a ser esos usuarios que pagan ;-) siempre es para otro usuario pagar. Mas todavia se acostumbran a tenerlo, y a la pequena sugerencia que tienen que hacer un poquito por si mismo ... ayyyyyy imposible! nunca jamas! este software es gratis y siempre lo hemos tenido! cabrones!.
Claro que es para cada empresa mirar al software que existe y utilisarlo como quieren. Todos los proyectos dan la bienvenida para gente nueva contribuir y si no toman esa oportunidad ... bueno, la empresa tiene que hacer un paso atras y aceptarlo
> Mas todavia se acostumbran a tenerlo, y a la pequena
> sugerencia que tienen que hacer un poquito por si mismo ...
> ayyyyyy imposible! nunca jamas! este software es gratis y
> siempre lo hemos tenido! cabrones!.
A mí entender, no es ésa la actitud.
El mercado del OSS tiene unas reglas, y si aceptas que tu software sea libremente distribuible, a cambio consigues un mercado enorme a una velocidad brutal. Y Spring lo consiguió, hasta el punto de ser más popular que los mismísimos EJBs.
Lo que no puedes es cambiarte de mercado a medio camino sin esperar que la gente que te ha llevado ahí arriba haciéndote popular (que son los de gratis, el 99,99%), y que hasta te han permitido crear una exitosa empresa de servicios sobre tu producto gracias a su enorme implantación, no se cabree.
Para descartar la posible mala marcha económica de Spring Source que apunta como posible causa del cambio de rumbo baste una referencia dada por la propia empresa. A mi entender se trata de un simple cambio en la estrategia de marketing de la antigua Interface21 que empezó con el cambio de nombre de la empresa a Spring Source.
Parece que su esfuerzo va en línea de perjudicar lo menos posible a los usuarios de código abierto mientras trata de pasar la factura a las empresas. Su línea de razonamiento es:
- Las empresas son muy conservadoras y emplean versiones anticuadas de Spring al contrario que la comunidad open source en general que suele emplear lo último. Entonces, las correcciones menores de versiones antiguas se pagarán. Las correcciones irán en el siguiente y último lanzamiento estable de Spring (algo que posiblemente no harán las empresas). Este es, según su planteamiento, su forma de perjudicar lo menos posible a la comunidad mientras cobra a las empresas.
- Rod considera que los usuarios de código abierto saben y pueden bajarse el código que necesiten directamente del repositorio. Esto no explica sin embargo porqué no hay tags.
La verdad es que no es una buena noticia para los que usamos Spring sin querer pagar. Pero es que por otro lado, ¿cómo se puede mantener un proyecto de código abierto de esta envergadura sin cobrar lo que cuestan sus muchos desarrolladores de élite?
JBoss lo intentó, entre otras cosas, limitando el uso de su nombre en los ofrecimientos de servicios de consultores de forma que nadie pudiese por ejemplo ofrecer "consultoría en Hibernate" sino "consultoría en mapeo objeto / relacional". Así ellos podrían explotar el área de servicios de forma pura. Fue también un buen follón que no gustó ni a Gavin King (a quién pilló en medio de esta guerra y defendió el uso libre de la marca 'Hibernate'). Esto es algo que, hasta donde sé, Spring aún no ha hecho.
Está por ver cómo se puede sacar dinero de código abierto. Pero es que los desarrolladores necesitan comer. Y la idea original siempre fue código abierto, no gratuito.
Sinceramente, me siento más próximo a Rod
Otra aproximación es la de Rails en donde David Heinemeier (el lider del proyecto) dijo que no crearía una empresa detrás de la iniciativa porque sería tener una posición privilegiada para 'chupar' todo el jugo del framework. Así que su avance, bueno o malo, depende de la buena voluntad de algunos líderes del grupo y la comunidad y, dada su forma de trabajar, más que nada de los proyectos que realizan y de los que luego extraen cosas para el framework.
@Anónimo
No creo que sea un problema de liquidez. En la última ronda de financiación SpringSource ha conseguido una cantidad que otras empresas como JBoss no pueden soñar. Parece que es más bien que Rod se está planteando cómo hacer mantenible el proyecto. Y hacer mantenible ya no es pagar a los desarrolladores, es conseguir el ROI que estas empresas posiblemente estén demandando (que en algunos casos como las de capital riesgo puede ser brutal)
Licenciamiento dual, licenciamiento dual, licenciamiento dual, licenciamiento dual...
Se veía venir, y este sólo es el segundo paso, el primero ya se vio claramente con la publicación como GPL del SpringSource Application Server.
El modelo actual de licencias liberales en productos de EMPRESAS con vocación obviamente comercial yo creo que NO es sostenible, salvo que su línea de negocio fundamental sea la consultoría, el desarrollo a medida y quizás la formación, en donde el software en sí mismo no es la fuente de ingresos.
Pero si el modelo de negocio es fundamentalmente el soporte (subscripción)... chungo, porque curiosamente para conseguir más negocio en soporte hay que fastidiar más la parte "libre". Se puede dar la paradoja de que cuanto mejor sea el software, mejor documentado, más libre de errores, más intuitivo, más facil de instalar etc, etc MENOS posibilidades existen de contratar soporte. No hay más que ver el poco dinero que gana Microsoft en soporte de Windows (dejemos a un lado el debate sobre sus bondades y maldades).
El problema es que estamos hablando de un software de código abierto con licencia liberal (Apache). ¿Se han planteado en SpringSource que cualquiera *legalmente* puede poner en su web el código fuente y compilado de la última versión estable "de pago"? Es lo que ocurre con CentOS respecto al RedHat Enterprise Linux.
Detrás de SpringSource hay dinero de capital riesgo que espera que vuelva a casa lo antes posible e incrementado, al igual que RedHat espera recuperar el pastón que pagó por JBoss, el cual por ejemplo ya sigue el modelo "open source de pago" en su versión Enterprise.
La realidad es que estos productos tienen millones de usuarios y sin embargo un procentaje muy muy pequeño paga una subscripción, son esos pocos subscriptores los que pagan las facturas de millones de usuarios con usos comerciales que no pagan un euro.
Por eso es hasta cierto punto lógico desde un punto de vista comercial, "putear" un poquillo a los usuarios gratis para que algún día se cansen de las piedrecitas que les ponen en el camino y acaben pagando algo por el software que usan. El problema es que estas "putadillas" son comprensibles pero feas feas feas.
La alternativa para mi es el licenciamiento dual.
En el modelo de licenciamiento dual existen dos licencias:
1) Una licencia "viral" tipo GPL o AGPL obviamente gratuita que obliga a que los derivados sean de código abierto.
2) Una licencia comercial de pago que permite derivados de código cerrado.
La ventaja del licenciamiento dual es que si el software tiene éxito el coste de la licencia comercial puede ser muy bajo al repartirse entre todos los clientes que usan el producto con fines comerciales (ganar pasta) y se evita el tener que diferenciar al usuario gorrón (no se gasta un céntimo pero usa el software con fines comerciales) del cliente de pago.
Se me olvidaba, lo que seguramente no saben muchos es que SpringSource YA está usando el modelo de licencia dual en el SpringSource Application Server que es GPL sin excepciones (en plan classpath exception):
http://www.springsource.com/products/suite/dmserver/licensingfaq
Y si se atrevieran lo harían con Spring... pero no se atreven y por eso siguen la vía de las "piedrecitas", ¿imaginaos lo que ocurriría si anunciaran que Spring pasa a estar licenciado como GPL? la cuota del seguro de vida de Rod aumentaría muchísimo :)
En este caso el problema es que, al igual que en con Ext, la diferenciacion entre usuarios "de pago" y "no de pago" es "fastidiando a los de no pago a ver si pagan", en vez de "dando ventajas a los que pagan, a ver si los otros se animan". Tener la misma version para ambos grupos pero a una se la doy a medias o solo de vez en cuando... no me parece buena solucion. Me parece mejor soluciones tipo Resin u otros donde la licencia profesional te da acceso a cosas que no tienes si no pagas, y ademas esas cosas son las que tipicamente necesita una empresa. O si no haces como Atlassian y das licencias libres a los desarrolladores O.S..
Como creador de un proyecto OS que lleva mas de 10 años de vida y voluntario en comunidades OS desde hace años tambien, no hace falta que me expliquen eso de los desarrolladores OS han de comer, pero como algunos mencionan en el hilo de TSS: El problema es la confusión y la incertidumbre.
Empiezas un producto, lo das gratis para que todos lo usen y cuando todos esos usuarios gratis te hacen famoso, decides que ya no te sirven y solo quieres los que te paguen en dinero o especies. Eso es confuso.
Igualmente, se habla mucho de "los desarrolladores open source" contra "las empresas que pagan soporte"... pero ¿ahora nos vamos a hacer los ingenuos y pensar que no existen empresas que usan O.S. y tienen desarrolladores que les pueden mantener el chiringuito sin necesitar manteniemiento?
Y por otro lado ¿Ahora resulta que los desarrolladores O.S. tenemos que ser activos en todos y cada uno de los proyectos que utilizamos, además de los nuestros, para no tener que pagar licencia? Por que si no estariamos en las mismas.
En fin, las fricciones normales de la adaptación de un modelo basado en la libertad a un modelo comercial. Los fines, al fin y al cabo, son diferentes.
Una pregunta un poco offtopic y sin ánimo de iniciar un flame: ¿Para qué sirve Spring (me refiero al motor de inyección, no al framework?
Me explico: Trabajo en un entorno corporativo que tiene todos los datos centralizados en una base de datos relacional. Hay varios grupos de desarrollo y todos ellos utilizan DAOs para el acceso a la base de datos. Uno de los equipos ha empezado a utilizar Spring como motor de inyección de dependencias, y no hemos observado ninguna ventaja. Con Spring, las aplicaciones van tan rápidas como antes y son tan fáciles (o difíciles) de mantener como antes. He leído montones de documentos sobre Spring y la inyección de dependencias, y me queda claro lo ventajoso que es en determinados casos (por ejemplo, si hay que cambiar la base de datos), pero sigo sin tener claro para qué sirve Spring en un entorno corporativo estable con una base de datos fija (que no se va a cambiar en muchos años).
David.
@jmarranz
Pero ¿cómo ayudaría una licencia dual en un caso como éste? Si empleas Spring en un servicio, no en una aplicación que vas a vender, no sería necesario pagar la licencia comercial, GPL sigue siendo válida...
A mi no me parece mal lo que hacen los tios de Spring. Siempre se ha dicho que Open Source no quiere decir gratis. Además, lo que hacen es que no te dan acceso a los "minor releases" pasados tres meses del lanzamiento de una "Major release". A los que trabajamos con Spring no nos afecta demasiado. Si una empresa quiere la ultimísima versión, pues que paguen. Así puede que se consiga que las p$%#s empresas de software, sobretodo la mayoría de españolas, se aprovechen del software libre y aflojen un poco el bolsillo. A estas lo que les atrae del software libre es que no les cuesta un duro, no les importa la calidad que pueda tener, que tenga mas bugs o menos, les importa desarrollar lo más rápido posible y con los menores costes posibles. Si luego al cliente le falla, no pasa nada, se le arregla y se le cobra una pasta. No piensan que alomejor, si contratas un soporte comercial de un producto opensource, lo que harías en 6 meses, lo haces en dos, ni se lo plantean.
Juanmp: Pero ¿cómo ayudaría una licencia dual en un caso como éste? Si empleas Spring en un servicio, no en una aplicación que vas a vender, no sería necesario pagar la licencia comercial, GPL sigue siendo válida...
Teóricamente no estás obligado a distribuir externamente una aplicación que contiene código GPL, incluso dentro de una corporación puede usarse "privadamente" una aplicación basada en GPL.
http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
La GPL es estupenda para el mundo de todo código abierto como es el mundo Qt y KDE (aunque Qt también puede licenciarse comercialmente).
Pero la GPL para código cerrado es un terreno MUY pantanoso. La regla GPL viene a ser "si tienes instalada la aplicación tienes derecho a tener el código fuente", y digo "instalada" porque esta regla no se aplica si a la aplicación se accede via red y no hay transporte de código (compilado o no), para cubrir esa excepción (o agujero como lo llaman algunos) se inventó la AGPL.
Por tanto alguien que usa un software basado a su vez en código GPL adquiere el derecho de poder acceder al código fuente. En una organización cualquier empleado en teoría podría tener derecho a dicho código si la aplicación es local de desktop.
Llevado al extremo, el programador de dicha aplicación podría "llevarse" la aplicación si quisiera. Obviamente existiría una situación de conflicto entre la propiedad intelectual del derivado y la GPL, es decir el (ex)empleado ha firmado que no tiene derecho a llevarse el software por un lado y por otro lado "ha firmado" que sí puede al usar código GPL.
Es como todo, las cosas se pueden hacer "bien" (licencia comercial) o en plan "mientras no me pillen" (GPL/AGPL).
Sun sabe que cuando compró MySQL compró un verdadero botín en propiedad intelectual, montones de empresas grandes y pequeñas tienen aplicaciones que se conectan a MySQL via JDBC cuyo driver es GPL:
http://www.mysql.com/products/connector/j/
Imagino que Sun tomará la via del buen rollo con MySQL pero sabe que puede tirar de la GPL para conseguir nuevos clientes en plan "sabemos que usas MySQL y no tienes ninguna relación comercial con nosotros, ¿podemos establecer una cita?".
http://blogs.sun.com/jonathan/entry/in_a_vortex
Where are the revenue synergies?
The more interesting question is "where aren't the synergies?" Wherever MySQL is deployed, whether the user is paying for software support or not, a server will be purchased, along with a storage device, networking infrastructure - and over time, support services on high value open platforms. Last I checked, we have products in almost all those categories.
Creo que los "quejosos" y los sensacionalistas no han entendido, para todos aquellos que estan ya sobre-reaccionando les recomiendo el blog de Martin Perez: http://brigomp.blogspot.com/2008/09/spring-cambia-el-modelo-de.html
El argumento de "si no estas de acuerdo conmigo es que no lo has entendido" siempre me ha parecido cachondo :), pero aparte de eso, simplemente la reacción negativa de tanta gente es una prueba fehaciente de que lo ha ocurrido no es desdeñable. Aunque sólo sea por haberse explicado mal y que la gente no lo entienda. "La mujer del cesar no sólo ha de serlo, ha de parecerlo".
Sun sabe que cuando compró MySQL compró un verdadero botín en propiedad intelectual, montones de empresas grandes y pequeñas tienen aplicaciones que se conectan a MySQL via JDBC cuyo driver es GPL:
No se si es lo que quieres decir o no se entiende, pero usar el driver JDBC con licencia GPL en tu empresa no implica que tu producto tenga que ser GPL, asi que no es nada de "mientras no me pillen". Los que si que tienen que tener cuidado son los que distribuyan su aplicación y ésta incluya el driver JDBC o lo requiera para funcionar.
Ah, y la distribución dentro de una empresa a sus empleados no se considera "distribucion" a efectos de laGPL, asi que no adquieres derechos en tu empresa. Y si lo hicieras, tampoco creo que los mantengas cuando dejas la empresa, pero eso que lo discutan los abogados laboralistas :).
> Creo que los "quejosos" y los sensacionalistas no han entendido,
> para todos aquellos que estan ya sobre-reaccionando les
> recomiendo el blog de Martin Perez.
Pues como me doy por aludido como "quejoso" y sensacionalista ;-), pregunto: concretamente, ¿qué es lo que no he entendido? ¿hay algún error o malentendido en mi explicación de la situación?
Por cierto, Rod Johnson acaba de decir en el hilo de TSS (lleno de quejosos y sensacionalistas, entre ellos los autores de varias de las librerías open source que usáis a diario y de varios de los libros que muchos tenéis en vuestras estanterías) que ha abierto una "seria discusión interna" en SpringSource sobre este tema. Parece que orientada al trato a dar a la pequeña/mediana empresa (se está hablando de precios de $5,000 - $6,000 por año y desarrollador, que Johnson no ha desmentido para mi pasmo)... pero bueno, al menos es una esperanza para que pongan en orden este desaguisado.
> Como veis, se trata de un cambio muy grande, y de un auténtico problema.
> ¿es limpio cambiar así el juego, cuando precisamente lo abierto y fácilmente disponible de tu software es lo que lo ha hecho llegar a una situación de éxito que roza el monopolio?
> hoy en día nuestra industria sin Spring... tiene un problema.
Estos argumentos los considero sensacionalistas. Lo que no se ha entendido, es que sin duda el desarrollo de Spring es muy costoso, y no es posible que muchas empresas usen versiones "viejas" y esperen que sin actualizarse a versiones "nuevas", les resuelvan los problemas que puedan llegar a tener. Para ello es la suscripción.
Martin Perez expresa muy bien como el percibe la politica de SS, ¿que hay de malo en ello?. El desarrollo de aplicaciones con Spring no se muere. Creo que TSS y JH muchas veces son muy sensacionalistas, no dudo en las buenas intenciones de informar, pero una cosa es informar y otra es fatalizar la situación y plantear escenarios imaginarios basados en suposiciones.
> Estos argumentos los considero sensacionalistas.
Ah vale, entonces no es que yo no lo haya entendido, es simplemente que opinamos distinto ;-)
> Lo que no se ha entendido, es que sin duda el desarrollo
> de Spring es muy costoso, y no es posible que muchas
> empresas usen versiones "viejas" y esperen que sin
> actualizarse a versiones "nuevas", les resuelvan los problemas
> que puedan llegar a tener. Para ello es la suscripción.
No hombre, claro que entiendo que el desarrollo de Spring es muy costoso. He creado tres proyectos open source en los últimos cuatro años, cualquiera de los cuales es absolutamente insignificante y miserable al lado del tamaño de Spring (obviamente)... y sin embargo me han costado un mundo de esfuerzo. Así que soy consciente de que mantener Spring tiene que ser la leche. Y también de que, cuando tienes un producto OSS, consigues un enorme mercado "gratis" a cambio de explotar sólo los servicios, y no el licenciamiento del software. Cada juego tiene sus reglas.
Pero hay un tema en el que me da la impresión de que estás confundido: el tema éste de que las versiones "de libre distribución" sólo existirán durante 3 meses no afecta a las versiones viejas, como parece que comentas: afecta, precisamente, a las nuevas. O sea, que si mañana sacan Spring 3.0, podremos bajarnos la 3.0 y las 3.0.x que salgan hasta 3 meses después de salir la 3.0. Y a partir de ahí, a esperarnos todos (menos los suscriptores) a que salga la 3.1. Tarde lo que tarde.
Eso, creo yo, es tocarle las narices al vulgo llano, que es el que usa siempre las últimas versiones. No a las empresas que demanden soporte, que, efectivamente, igual aún están en la 1.x.
Y de ahí el follón.
Ahora, que esto es como todo... el cuánto de malo o bueno te parezca esto... pues dependerá de cuánto te afecte. A mí, me fastidia bastante ;-)
> [...] pero una cosa es informar y otra es fatalizar la
> situación y plantear escenarios imaginarios basados en
> suposiciones.
¿Escenario imaginario? ¿basado en suposiciones?
>Ahora, que esto es como todo... el cuánto de malo o bueno te parezca esto... pues dependerá de cuánto te afecte. A mí, me fastidia bastante ;-)
Si es asi, puedes pagar la suscripción y asunto arreglado. Tan simple como eso.
> Si es asi, puedes pagar la suscripción y asunto arreglado. Tan simple como eso.
En realidad, desgraciadamente no es tan simple como eso. Porque quienes tendrían que pagarlo serían los clientes. Y, poniéndome en la piel de una empresa consultora típica de este país, podríamos encontrarnos con:
- Mirad, para este proyecto vamos a usar Spring, que es open source así que no os aumenta el precio del proyecto, pero tendremos un acceso limitado a las correcciones de bugs que salgan...
- ¿Y por qué limitado? ¿No es open source?
- Bueno, podría no ser limitado, pero tendríais que pagar X euros por CPU al año.
- Ah no, qué caro. Usad otra cosa.
- Hmm... es que veréis... como Spring era un standard de facto en la industria, y antes era más accesible en estos temas... pues ahora tenemos 300 empleados que llevan varios años formándose en Spring y...
El problema, por tanto, no es tanto que SpringSource haga lo que quiera con su producto (que, obviamente, puede hacerlo), sino que, una vez ha llegado a una situación en la que tiene a buena parte del sector dependiendo de Spring en todo el mundo... les ponen las cosas difíciles. Si lo hubiesen planteado así desde el principio, probablemente hubiesen tenido algo menos de éxito (o no), pero en todo caso nadie se habría enfadado... pero el problema de esto es el cómo, no el qué.
...y sí, lo de la conversación consultor-cliente sí es un escenario imaginario basado en suposiciones, factible, pero basado en suposiciones... así que con ése me puedes dar caña ;-)
> ...y sí, lo de la conversación consultor-cliente sí es un escenario imaginario basado en suposiciones, factible, pero basado en suposiciones... así que con ése me puedes dar caña ;-)
No que va, lamento que mi intención se haya mal interpretado. Pero no creo que cobren por CPU, a menos que uses el SpringSource dm Server
> No que va, lamento que mi intención se haya mal interpretado.
> Pero no creo que cobren por CPU, a menos que uses el
> SpringSource dm Server.
Nah hombre, era una broma para que no pareciese que nos estábamos pegando :-)
Pero sí, las intenciones son que los costes sean por CPU o por desarrollador (imagino que dependiendo de si eres empresa desarrolladora de software o cliente de esta empresa).
Rod Johnson lo expone en este comentario:
http://www.theserverside.com/news/thread.tss?thread_id=50727#269536
Pues yo con JavaEE 5 y con SEAM como framework web, no hecho de menos a Spring en nada. Tengo IoC, integración limpia con hibernate (JPA) y para todo lo demás.... mi gran amigo SEAM ;)
Un saludo.
Mi opinión es un sí puedo pero no debería para esta decisión.
Por supuesto que tienen derecho a tomar decisiones como esta, pero tampoco se puede olvidar que si bien tienen un gran producto muy presente en este mundillo, no es menos cierto que la comunidad ha contribuido enormemente a su difusión de varias maneras:
Es decir, que no sólo su éxito se debe a ellos.
Y nada más, sólo decir que quizá ha llegado el momento de replantearme cambiar a Seam, aunque me disguste la idea.
Supongo que sea el único que defienda esta postura:
Me parece correcto que por un servicio (creo que se puede considerar servicio el hecho de ofrecer correcciones después de 3 meses de uso) se cobre.
La productividad y calidad en los desarrollos que nos ha traído Spring frente al coste de una licencia, o un pago, o lo que sea, supone una inversión ridícula.
Todos queremos obtener algún beneficio de nuestro trabajo, para eso lo hacemos. Creo que esta gente ha hecho un muy buen producto y es natural que busquen una fórmula para poder asegurar su futuro, que será duro frente a EJB3, Seam, ... y requerirá mucha inversión. La competencia es durísima.
Yo por mi parte no tendré inconveniente alguno en pagar una subscripción, a no ser que sea algo abusivo. ¿Cuánto? No se, pongamos que 500€/año podría ser un límite superior que entendería como razonable.
Saludos.
greeneyed: pero usar el driver JDBC con licencia GPL en tu empresa no implica que tu producto tenga que ser GPL
Yo creo que sí y los de MySQL piensan lo mismo, una capa de abstracción no invalida la GPL la cual es por fortuna/desgracia viral.
http://www.mysql.com/products/connector/j/
* MySQL Connector/J 5.1 is the current production-ready version of the driver, and is available under the GPL (recommended).
Commercial licenses for either version can also be purchased from MySQL AB, for those who don't wish to be bound by the GPL.
greeneyed: Ah, y la distribución dentro de una empresa a sus empleados no se considera "distribucion" a efectos de laGPL, asi que no adquieres derechos en tu empresa. Y si lo hicieras, tampoco creo que los mantengas cuando dejas la empresa, pero eso que lo discutan los abogados laboralistas :).
Es una interpretación muy optimista de la GPL :) pero no es el espíritu de la GPL la cual no hace ese tipo de distinciones.
Yo creo Daniel que no suele haber problemas con este tema porque normalmente ningún currillo suele pedir el código fuente de lo que usa, para empezar porque normalmente creerá que lo de la GPL es un tipo de coche, lo segundo porque no tendrá ni idea de lo que hay detrás del programa que usa, lo tercero por que le da bastante igual, lo cuarto porque le dirán irónicamente "que sí que mañana te lo damos" y lo cuarto porque no creo que quiera perder su trabajo.
Volviendo al tema Spring.
Este debate tendría mucho menos fuerza si estuvieramos hablando de unos pocos dólares al año, por ejemplo, cualquier antivirus cuesta unos pocos dólares la subscripción anual para actualizar el antivirus, si McAfee siguiera el modelo de dar sus grandes versiones gratuitas pero sólo actualizaría día a día a los subscriptores de pago pasaría lo siguiente:
1) Los usuarios de gratis tendrían un antivirus desactualizado, estarían en riesgo por los nuevos virus hasta que saliera la nueva versión principal (que cubriría los nuevos virus).
2) Los usuarios de pago estarían protegidos "al día" pero su cuota anual sería altísima como única manera de financiar el desarrollo de las nuevas versiones y la investigación/actualización del producto con los nuevos virus.
Con este modelo casi nadie tendría su ordenador protegido.
Cualquiera puede encontrar una analogía respecto a Spring, JBoss etc.
En un modelo de licencia dual no estaríamos hablando de $5,000 euros anual por desarrollador como se decía más arriba, hablaríamos quizás de 200 euros (por decir algo).
Mis centimos a la discusion,
Como ya otros habeis dicho,
lo que me parece mal es que primero saque un producto gratuito, se haga famoso gracias a sus virtudes pero tambien gracias al resto de la gente que lo usa, escribe blogs, libros,da conferencias, portales, etc. Y cuando nos tiene a todos cojidos por los huevos entonces dice que es de pago.
Sinceramente me parece inmoral, si hubiera estado esta política desde el principio no me habiera parecido mal pero cambiarla ahora que son el estandar de facto,...
De todas formas no me extraña lo que ha pasado, hace unos meses en una entrevista que hicieron a Rod Johnson vino a decir más o menos que el modelo "Open Source" era una forma como otra cualquiera de negocio. Así que mi opinión es que no tiene problemas en sacar nuevas versiones cerradas aunque si hace eso si que ya se lo comen vivo.
A ver, que no os enterais, el código fuente va a seguir estando disponible!! Si quieres bajarte la última release, te bajas los fuentes y los compilas. Lo que no van a ofrecer al cabo de 3 meses son los binarios.
LOS BINARIOS, NO EL FUENTE
y oye, a quien le dé miedo compilarse un proyecto open-source... pues que pague sus miedos jijiji
Al último anónimo:
A ver, que no os enterais, el código fuente va a seguir estando disponible!!
Te veo muy optimista, pero parece que no ves el gran problema. Lee la última parte de la noticia, en concreto:
Todas las soluciones de bugs que forman parte de las minor releases, sin embargo, sí estarán en el repositorio de código fuente, de libre acceso, pero no habrá tags para las minor releases, ya que SpringSource considera "un producto que ofrecen" el conocimiento necesario para saber si en un determinado momento el trunk del repositorio es suficientemente estable como para considerarlo una release. En la práctica esto significa que cualquier checkout compilado desde el repositorio de fuentes no debería considerarse estable, y por tanto no debería pasar a producción.
El problema tras los tres meses de liberación de una major release, dejarán de estar disponibles para todos las minor releases. A partir de ese momento, podrás bajarte el código fuente, sí, pero como no estará etiquetada con minor release no sabrás en qué estado está ese codigo (estable, inestable,...), no tendrás ninguna garantía de que en el momento de tu checkout el código corrija todos los problemas de modo que sea estable.
jmarranz: Yo creo que sí y los de MySQL piensan lo mismo, una capa de abstracción no invalida la GPL la cual es por fortuna/desgracia viral.
No, los de MySQL tampoco lo piensan, ni lo piensan los de GNU ni nadie que realmente conozca la GPL. Usar un producto GPL no afecta para nada si no distribuyes. No se de cuantas maneras hay que decirlo, pero si no distribuyes no hay viralidad ni nada parecido. Precisamente por eso se creo la AGPL, por que en el caso de un modelo de servicios, puedes cobrar sin distribuir y la cosa se estaba desmadrando.
Y no, nada de eso va en contra de la intención de la GPL, si no crees eso, entonces habla con GNU y preguntales por que la han cambiado a AGPL ;). Una cosa es la intención que tenia el que escribió la licencia y otra lo que dice la licencia. Lo primero es legalmente prcaticamente indefendible sin malabarismos.
Mira simplemente sus propias respuestas en el FAQ:
.- http://www.gnu.org/licenses/gpl-faq.es.html#UnreleasedMods -> En esta admiten que si no distribuyes no hay nada que hacer y por eso hay que cambiar a AGPL. Además, eso suponiendo que se acceda a tu aplicación en remoto. Si no, para uso interno la GPL no implica nada de nada.
.- http://www.gnu.org/licenses/gpl-faq.es.html#InternalDistribution -> En esta dicen claramente que "distribución interna" es "que la empresa haga copias para si misma" así que no es distribución. Los derechos son adquiridos por la empresa, no por el trabajador. Otra cosa es facilitar copias a personal externo, pero internamente, nada de nada.
Me sorprende que creas que un "montaje" así se mantiene simplemente por la ignorancia y buena voluntad de la gente. Se nota que no has tenido que pegarte con abogados americanos jejeje. Si la situación fuese siquiera dudosa hacia lo que tu dices, te puedo asegurar que nadie en el mundo tendria un software de ese tipo creado por una empresa americana. Los tiburones huelen la sangre a muchos kilometros, jejeje :).
Por no alargar más en este hilo el off-topic de la licencia de MySQL, comentaos que lo hablamos hace algún tiempo en este otro hilo
http://www.javahispano.org/contenidos/es/mysql_vs_postgresql_cuando_emplear_cada_una_de_ellas_11/
y que, aunque yo inicialmente creía que tú podías usar sin problemas MySQL en una aplicación comercial JEE, me convencí de que no.
La clave es que el problema de la licencia no está en MySQL, sino en el driver Connector-J.
La solución pasa por usar el driver MM.MySQL, que tiene licencia LGPL.
hablando sobre el tema de Spring, la verdad es algo que veia venir, pero pudo a ver sido muucho peor!!
Imaginemos este caso alterno: SpringSource decide que solo dara gratis los Major release, todo minor release habra que pagarlo sea quien sea.
O este otro caso, Solo los subscriptores podran descargar SpringFramework en binarios, todo el resto de chupasangres que queremos todo gratis le toca arreglarselas como puedan con el codigo fuente, porque al fin y al cabo se llama Open Source, no Open Binaries!! jeje xD.
Por otra parte, ¿cuantas veces hemos tenido que actualizar Spring a un minor release porque sin ella nuestro proyecto se va al carajo?? Otra mas ¿cuantas veces en el mismo proyecto hemos tenido que actualizar Spring porque sin esa nueva actualizacion todo fracasara???
Yo he desarrollado muchos proyectos con Spring y hay uno de ellos que todavia usa la version 2.0.0 y va muy muy bien y mi cliente esta contento, me he actualizado a la version 2.5 por las nuevas funcionalidades y para usarla en nuevos proyectos. Y si he bajado minor release no ha sido por bug fixes que necesito, simplemente porque algunas mejoran el rendimiento (que por cierto, no se nota mucho) o porque mejoran la documentacion. Y uso Spring para integrar lo que normalmente se necesita, en mi caso: JPA, JSF, Spring Remoting por los HttpInvokers, algo de AOP, y para inyectar y cablear mis objetos.
Que los de SpringSource cobren lo que se merecen, si yo fuera uno de los programadores de Spring, joder que me paguen lo que hago, asi no veria gente lucrandose con mi trabajo y yo sin recibir un peso/euro/dolar
Te doy la razón en lo de que la distribución interna no implica necesariamente el derecho a la distribución externa, pero me tienes que das la razón de que la distribución interna supone el derecho a la disponibilidad del código fuente por parte del destinario de la instalación, es decir, empleados, y estoy pensando en aplicaciones de desktop que se instalan puesto a puesto y eso en mi pueblo es distribución ;)
Pero me da igual, el ámbito de una organización es un ámbito controlado y nadie quiere el código fuente de las aplicaciones que usa aunque tuviera derecho (y mejor que sea así).
Otra cosa es cuando hablamos de aplicaciones Web en donde NO hay distribución ni siquiera interna en la medida en la que uno se conecte via web y como bien dices para eso se inventó la AGPL (no es que hayan cambiado la licencia GPL es que es otra licencia diferente segun el nivel de restricción o viralidad que quieras aplicar a tu programa).
Respecto al tema de los abogados, sí ha habido movidas con ese tema, seguramente te suena el caso de Tivo que en buena parte motivó la creación de la GPL v3 y la "bendición" por parte de la GNU de la AGPL (ambas impiden la "Tivoización").
y estoy pensando en aplicaciones de desktop que se instalan puesto a puesto y eso en mi pueblo es distribución ;)
Si estas hablando de la misma empresa, el ambito gegráfico no importa. No es distribución. En tu pueblo no serán abogados ;).
Y precisamente esas movidas son las que "me dan la razon". Si la GPL considerará eso distribución habría habido muchas más movidas, y si no pudieras usar software GLP, sin distribuirlo, sin tener que hacer tu software GLP, no haría falta AGPL ni nada parecido.
y que, aunque yo inicialmente creía que tú podías usar sin problemas MySQL en una aplicación comercial JEE, me convencí de que no.
La clave esta en la distribución. Y ojo que no solo es un problema para aplicaciones comerciales, tambien lo es para software licenciado con otras licencias incomptabibles con la GPL.
Y por cierto, si tu software requiere MySQL por narices, teóricamente no está tan claro que usar otro driver solucione tus problemas. Si tu software requiere un software GPL y lo distribuyes, la licencia dice que tambien has de hacerlo GPL. La solución en este caso es hacer el software independiente de la BDD.
Hola Zemi,
He entrado en la página de MM.MySQL,y la última versión es de 2002 , además cuando pinchas en la página del proyecto te redirige a una de MySQL, así que creo que ese proyecto debe estar más que muerto.
Saludos.
MM.MySQL es el predecesor de MySQL JDBC. El autor es Mark Matthews que escribe MySQL JDBC.
Pues parece que tocara dejar de utilizar Spring, y pasarse a JEE 5 y Seam.
Pues yo digo que parece que tocara dejar de usar JAVA y pasarse a Python y sus frameworks!!
Pues si, asi de estupido se escucha los que afirman que tocara pasarse a Seam, Spring sigue siendo Spring, a muchos de nosotros no nos afecta los cambios que se hacen en los minor release, reconzcanlo,por mi parte lo unico que me interesa de nuevas versiones es nuevas features que me ayuden en el trabajo, la mayoria de bugs y problemillas que resuelven a muy pocos afectan. Tocaria pasarse a Seam si Spring se convirtiera en un framework cerrado, o de pago para cualquier version binaria, de lo contrario no veo porque tanto lloriqueo y lamentaciones. Y si, parece un movimiento desleal de parte de SpringSource pero tienen todo el derecho y si alguno de nosotros estuvieramos en sus zapatos pensarammos igual.
en la pagina de SpringSource han abierto un FAQ para este tema:
http://www.springsource.com/products/enterprise/maintenancepolicy/faq
Basicamente lo que hemos discutido hasta ahora en la noticia es como se plantea en SpringSource, pero coloco el link para cualquier duda que aparezca.
En resumen para los que no queremos pagar nada: Tendremos todos los mayor release con la misma licencia de siempre y gratis, tendremos los minor release durante los primeros tres meses despues de lanzado un major release. Tendremos el mismo Issue Tracker para saber que nuevos bug fixes se han agregado y si necesitamos algunos solo toca bajar el fuente y compilarlo. El resto sera lo mismo de siempre.
Bueno, pues parece que, tras el follón que "hemos montado", SpringSource está empezando a replantearse la situación. Al menos, parece que empiezan a considerar la posibilidad de sí proveer los tags del repositorio de fuentes.
Rod Johnson lo acaba de anunciar en el hilo de TSS:
http://www.theserverside.com/news/thread.tss?&thread_id=50727#269803
Desde luego, es una actitud de diálogo que hay que apreciarle, después de toda la presión que hemos hecho los "quejicas" durante este último par de días. Veremos si efectivamente se llega a un compromiso. Ojalá.
algunos comentarios más de Rod:
Aqui tienen un medio calculo de como podria costar una licencia, se esta hablando de US$22,500 dolares por CPU al ano, eso esta de locos: http://www.ryandelaplante.com/rdelaplante/entry/the_cost_of_springsource_enterprise
No es asi nada mas de facil pagar la cuota y ya, Eso nada mas lo pueden pagar empresas grandes.
Yo ya me estoy pasando a JEE con EJB3/Seam, Estoy platicando tambien con mis colegas de esto y tambien se van a mover a Seam porque creo que lo de Spring ya no tiene una solucion.
"tambien se van a mover a Seam porque creo que ..."
Spring y Seam hacen cosas distintas, pero bueno ...
"No tiene una solucion" ? Me parece que no quieres escuchar a lo que ha cambiado y solo reaccionar sin pensar. Los de SpringSource van a anunciar algo mas barato para gente que no quiere lo de Enterprise Spring, la semana que viene.
Por lo visto censuraron mi post, aquellos que solo escuchan su propia voz no se dieron cuenta pero hace rato que quedaron sordos.
No se si se pueden ver los post censurados, antes se podía, pero si es el que he moderado yo, ya te he puesto que podías haber dicho lo mismo sin insultos gratuitos. Si crees que censura es que no te dejen insultar como anónimo en un foro sin ningún tipo de explicación, no entiendes realmente lo que es la libertad de expresión.
Lo unico que podia sonar a insulto en mi post era que la politica de openbravo era atraer ingenuos usuarios gracias a su licencia de codigo abierto. Pude usar una palabra mas fuerte que ingenuos pero pense que eso si me censurarian.
Es la ultima vez que posteo aqui.
Gracias por su desinteres. Nos vemos ahi.
Pues siento que pienses así, ya que puedes expresar el resto de tus ideas sin insultar a nadie. Si hubiera podido editar esa parte y dejar el resto, lo hubiera hecho.
Aunque entiendo que puedas tener esa opinión, y no tengo nada que ver con OpenBaravo, expresarla en un foro de forma anónima así por las buenas no es la forma de actuar, y es una pena por que desvirtúa el resto de tus opiniones, que me parecían totalmente válidas.
Si tus deseos de poder insultar impunemente pueden más que los de compartir opiniones, pues lo lamentaremos pero así es la vida.
yo ya me he replanteado usar solo el core, para todo lo demas EJB 3 e incluso SEAM o icefaces
"Spring Framework" will die!
Oops! I guess I really read something similar in other place.
Quizá ya lo saben pero luego de este lio Spring cambió la política de mantenimiento en octubre del 2008:
http://blog.springsource.com/2008/10/07/a-question-of-balance-tuning-the-maintenance-policy/
Saludos!
Que? me lei todo el hilo y al final cambio la politica ??? XD
Escribe tu comentario