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.

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.

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