Matt

You’re missing the fact that there is a large amount of new code and new functionality in this release. It is not just aggregation. Marc Fleury’s comment that it is “the same thing you had yesterday for free, except it is now under the GPL and a proprietary subscription license” is plain wrong, and merely shows that he hasn’t examined it closely enough or/and doesn’t appreciate the importance of a generic OSGi-based middleware solution. The fact that Marc Fleury has never given Spring or SpringSource any credit for their innovations over the years is a matter of public record, in any case.

SpringSource has never been in the business of “me-too” technology. This server provides a new option for more modular, manageable deployment; supports versioning of application components (with potential greater uptime); introduces a powerful means of managing library dependencies; allows more sophisticated sharing of artifacts across applications; introduces a greater degree of semantic understanding of deployed artifacts that simplifies deployment (and enhances developer productivity) compared to existing technologies–just to cite a few benefits.

Analogous to Eclipse on the desktop, it provides a context for OSGi which makes that technology useable to a large audience: in this case, enterprise Java developers.

Some resources detailing some of the new features, which were not available from the component parts:

- Completing the picture: Spring, OSGi, and the SpringSource Application Platform

- Introducing the SpringSource Application Platform

- Running Spring Applications on OSGi with the SpringSource Application Platform

Rgds
Rod

I forgot to add: no license is being *changed*. We are using another open source license for a *new* product.

[...] SpringSource’s GPL move highlights commercial concerns [...]

It’s the new campaign to denigrate the GPL.

First the GPL was bad because it wasn’t commercial-friendly enough.

Now, it’s because is too commercial-friendy.

Worse, you’re equating the GPL with proprietary.

Give me a break.

Don’t you have nothing better to do that to continue releasing anti-gpl propaganda.

Much due congratulations to the SpringSource team and their new beta OSGi based App server! FWIW: We started down the OSGi path about 6 months ago and found there was going to be a ton of code needed to provide the proper infrastructure to OpenNMS and decided to put it off until our 2.0 version. And now, here, like a great gift, we’ll be able to move forward with this great technology.

Back on topic, since OpenNMS is GPL, there are no licensing issues for us, however, I will chime in with support of SpringSource’s decision to use the GPL license for we understand, in no uncertain terms, how this protects their technological investment and the open source community. I’m sure that if the folks over at RedHat could go back in time they would change the JBoss licensing to something more like GPL + “Classpath exception” for the JBoss APIs vs. the LGPL route. I think LGPL works well for libraries and such but not so well for full applications or frameworks such as an App Server when there is signification technological achievements being made.

Rod, while we’re not worthy! (grin), we’ve reviewed some of the code and believe this work is definitely another example of great thought leadership and fantastic Java work from the Spring community.

You seem to be missing the point of the dual license. A commercial open source company like SpringSource releases code in open source under the GPL because it is not commercial-friendly. The open source community don’t mind the GPL. However commercial organizations who want to use the software don’t like the GPL (particularly if they are embedding the technology into something) so they prefer to pay for a commercial (non-GPL) license. I don’t think Matt is equating the GPL with proprietary just pointing out that SpringSource is moving to the increasingly popular GPL-or-commercial dual license model.

[...] Java server that forms the foundation of the SpringSource Application Platform, which we first wrote about back in [...]

[...] Carlo cites as an example the use of the GPL by the usually Apache-focused SpringSource for its SpringSource dm Server as a means of restricting the commercial opportunities for potential rivals, something that we covered here. [...]

[...] we noted when SpringSource introduced dm Server, the choice of GPL was appeared to be designed to protect [...]