451 CAOS Theory 
A blog for the enterprise open source community
SpringSource’s GPL move highlights commercial concerns
Matthew Aslett, May 2, 2008 @ 9:39 am ETGiven the previous discussion on this blog and elsewhere about the commercial benefits of the GPL versus more permissive open source licenses it is fascinating (if you’re in to that sort of thing) to see that SpringSource has chosen the GPLv3 for its new Application Platform.
Due for release in June the SpringSource Application Platform combines the Spring Framework, Apache Tomcat, Eclipse Equinox and other OSGi-based technologies with the new SpringSource Dynamic Module Kernel backbone. All of these are available under Apache or Eclipse, however, the SpringSource Application Project itself will be under the GPLv3.
As Rod Johnson explains, the choice of license is very much designed to protect the commercial interests of SpringSource:
“Creating an application platform that makes the benefits of OSGi available to end users was a huge investment for us. There’s a lot of technical innovation under the hood which won’t be immediately apparent but which enables us to make a generational leap. If we’re giving that technology away in open source, we wanted others who build on it to also give away the results in open source.”
TheServerSide discussion shows that not everyone is happy with the company’s decision to go GPL and it is interesting to see the company using the GPL to restrict the commercial opportunities for potential rivals (although at least the code is still open source, it could after all have changed it to a proprietary license). Marc Fleury, meanwhile, describes it as “the same thing you had yesterday for free, except it is now under the GPL and a proprietary subscription license.”
To clarify, the Spring Framework itself remains under the ASL 2.0, and it is also worth noting that the change SpringSource has made (like it or not) is only possible thanks to the GPLv3’s compatibility with the Apache license (although the Eclipse Equinox tools are another matter).
Email This Post
|
Technorati Links |
Bookmark on del.icio.us |
digg it
Categories: Licensing, Software
Comments RSS feed | Trackback URI
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.
Thanks Rob for the additional information. Do you have any insight on the licensing situation with regards to Eclipse?
[…] 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.
Who said the use of the GPL for commercial reasons was bad? Trying taking off the tin foil hat and reading the post again.
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.
Thanks for the insight David.