Hello Chris Le 25/07/12 17:28, Mattmann, Chris A (388J) a écrit :
Do you have any indication as to why GeoTools, GeoServer, and uDig would rather go to Eclipse than come to Apache? I would welcome them all here. And of course, I think a non copyleft license like the ALv2 is the superior choice for a Geospatial toolkit compared to copyleft licenses (that may impose downstream impacts), that's why I started the SIS project.
The Eclipse peoples asked the same question, why to go to Apache rather than Eclipse... I interpret (maybe wrongly) Eclipse as a little bit more business-oriented than Apache. I'm sure that both approaches are legitimate, but on our side we have a bit more academic/scientific background. Our company is hosted in a governmental agency trying to help developing countries, which has some influence on our philosophy. We have the (maybe superficial) impression that we could feel a little bit more at home at Apache.
The Eclipse's LocationTech group has been very active in approaching some Geospatial projects. Given that LocationTech could been seen as an OSGeo competitor, I wonder how they will work together. Because Eclipse is much bigger, OSGeo has to find some way to collaborate while preserving their identity.
A similar relationship exists between the "Geotoolkit.org/Constellation-SDI/Puzzle" stack and the "GeoTools/GeoServer/uDig" stack. Both have similar targets, but the later stack has more marketing power. Geotoolkit.org tries to find its identity by focusing on a different community and by exploring different technologies, e.g. JAXB (included in JDK6) instead than the Eclipse Modelling Framework for XML, Swing instead than SWT for desktop applications (while we make room for different widget toolkits). Maybe the fact that GeoTools/uDig use more Eclipse technologies than we do, and the fact that we use more Apache technologies than they do (e.g. the Derby database) is an additional argument for the way the respective projects would settle down... This is not necessarily at the Apache SIS disadvantage, since the softwares that we would like to offer to Apache cover a similar spectrum of functionalities. Since they do not have the installed users base that uDig/Geoserver have, I think the Apache SIS project would get more flexibility for making drastic changes if needed to better suit peoples needs.
Their initial plan was to make an exception to the Eclipse licensing policy in order to accept GeoTools with its LGPL license. However our request to re-license our code to Apache caused some GeoTools members to propose re-licensing GeoTools to Eclipse. If GeoTools makes such re-licensing, it may facilitate our request to OSGeo since it is a similarly-permissive license. That's the thing. LGPL isn't similarly permissive to ALv2. In fact they are quite different, depending on the versions (e.g., LGPL2, LGPL3, compared to ALv2).
I wanted to said "Eclipse license similarly permissive to ALv2". I see the Eclipse license as somewhere between Apache and LGPL, but closer to Apache than to LGPL. My thought was that if GeoTools goes to Eclipse license, this is one more argument for convincing OSGeo to give formal approval for Geotoolkit.org going to Apache license.
I'm not sure how economical interests play into the fold really. ALv2 allows anyone downstream to use the software however they want. IMHO, it's extremely more permissive than the current situation in Geospatial toolkits and APIs for Java, which by my accounts in 2010 were mostly copyleft licenses. IME, copyleft licenses prevent commercial companies in most situations, e.g., like IBM, Oracle, Google, etc., from contributing their developer time because the copy can't turn around on the consumer end of the open source, and include that open source in their commercial products without inheriting the upstream copyleft restrictions.
At least two small or medium companies are making their living from selling GeoTools/GeoServer services. Geotoolkit.org/Constellation-SDI is a competitor for them. It was a rather inoffensive competitor as long as it was largely unknown despite the technical merits (in my opinion). But a project having Apache's credibility with the code that Geotoolkit.org can provide may be a treat to some businesses. However it doesn't mean that they would behave madly; in the GeoTools vote, two members of the same company voted in opposite way: 1 yes and 1 no. Consequently I really don't know if/how those considerations may play.
However those kind of projects don't have to be competitors in all aspects. GeoAPI is in theory a path allowing a project to use services from an other project. The hard thing is to convince other projects to use and implement GeoAPI interfaces. I think it can happen only if a GeoAPI implementation - as Apache SIS could be - become attractive enough for inciting other projects to inter-operate with it.
Great to hear! :) Of course my personal interest would be to have you guys join up with SIS.
Thanks, this is appreciated :-)
Cool, well up to you guys but Apache could also be a home for GeoAPI too -- but again up to you guys. Not sure of the precise thought process behind bringing that part to Eclipse, but it's probably b/c I lack the full context.
A first reason why we propose GeoAPI to LocationTech is that we feel useful to stay in touch with them, so GeoAPI could be our link. A second reason is that the guys that we need to convince to use GeoAPI, namely GeoTools, are on the Eclipse side (hopping that Apache SIS would not be too difficult to convince :-) ), so we hope to make that easier by being close to them. A third reason is that the big players involved in Eclipse (Oracle, IBM, etc.) seem similar to the big players involved in OGC, and they are the players who make standards a success or a failure (at least in the way OGC currently work). Since GeoAPI is an OGC standard but not yet a de-facto standard, we think that we need to play by their rules in order to give GeoAPI a chance.
Cheers, Martin
