[OSGeo-Discuss] The Geotools fork and current relicensing discussion [was Re: The importance of a project's license]

[Adrian Custer]

Hello everyone,



On 7/27/12 12:55 AM, Alex Mandel wrote:
> This is a really interesting debate. Reading the links provided it also
> appears to be a mixed bag about acceptance of LGPL of various firms and
> I'm also sure many of us can name firms that have no issue shipping LGPL
> components.
>
> Aside from that though, reading about the Apache SIS project motivation
> and better understanding of why Geotools forked to begin with seem quite
> relevant. The first was easy to find, but does anyone have a good
> history of geotools v geotoolkit?


The fork had *nothing* to do with licensing but was primarily motivated 
by governance issues and differences of opinion in project direction.

Also note that the fork followed over a year of work attempting to 
reconcile differences of vision and governance, so that the fork, when 
it happened, was essentially 'friendly' in that it was based on a common 
agreement that two groups wanted to work in two different directions and 
that the struggle of working together was no longer worth the cost.

At the core, the fork was motivated by different views for how to handle 
geospatial imagery: one group, including the original author and 
maintainer, had one architectural vision for the code and wanted to work 
in Java exclusively, the other group had a different architectural 
vision and ended up binding to C language libraries for the different 
image formats.

However, there were a myriad of other issues. The groups differed in the 
consideration of the importance of working against a formally defined 
abstract API (the GeoAPI project) and of the importance of having this 
API aligned to published international standards from the International 
Organization for Standardization , ISO, and the Open Geospatial 
Consortium, OGC. The group differed in visions of the independence of 
the Geotools library from that of Geoserver including in the direction 
of development, in the schedule for releases, in support for new JAVA 
APIs, in the adoption of new versions of the JAVA runtime environment. 
Finally, there were philosophical differences in the approach towards 
accuracy that seemed due to differences in approach of engineers as 
compared to that of scientists.

In other words, the fork was motivated by two groups wanting to work in 
different ways, on different things, towards different goals. The fork, 
then, reflects exactly the reasons we give each other the freedom to 
work with the code we create.





As for the relicensing decision itself, here is my take.

Note, that I am not unbiased in this issue [1], although I suspect my 
bias is more against OSGeo than for anyone in particular.

First, the choice is only OSGeo's to make. The work that the Geotools 
community put into the copyright assignment focused explicitly on making 
OSGeo the custodian of these issues. In our minds at the time, the 
copyright assignment was designed for three reasons; first, to have 
legal documentation of the intent of a user to contribute, second, to 
have an advocate in the case that any lawsuits arose, and, third, to 
allow the code base to move past any legal problems that might arise 
with the general public license, such as unintended conflicts between 
the (l)GPL and other licenses. So while consulting with current Geotools 
members is elegant, it does not absolve the Board from the ethical 
responsibility for making its own decision.

Second, the Board is not impartial in this matter. A first point of 
disparity, is that historically, OSGeo is tied closely to the Geoserver 
community, having many of those contributors as Charter Members and 
having board members with direct ties to that project. Conversely, OSGeo 
has never managed to pull in Martin Desruisseaux as a charter member 
[2]. A second point of disparity is that OSGeo denied Geotoolkit 
acceptance as an OSGeo project [*] which, in effect, blessed one side of 
the fork and not the other. Since there are financial and strategic 
issues involved in allowing Geotoolkit to join Apache and form another 
community, the history of OSGeo's relation to geotoolkit should make the 
board extra cautious to base their decision on a well founded reasoning 
rather than on the personal preferences of individuals.

Third, the decision strikes me as between honoring the intent of 
contributors to Geotools 2.6 and honoring the desire of the Geotoolkit 
contributors to take forwards their code base and build a community 
after having been rejected by OSGeo. Personally, it feels wrong to have 
all of Geotools 2.6 relicensed from a *GPL style license to an APL or 
similarly permissive license. My personal motivations are very different 
in those two different environments. However, it also feels wrong to 
impose my strong personal preference in a way that blocks the progress 
of others since I want free software exactly so that others have the 
freedom to leverage my work. This is especially true given that the core 
code base of the two projects was overwhelmingly Martin's work, and that 
the new code base has diverged enormously from the time of the fork.


Given these two 'wrong feelings' how do we find the best resolution? I 
am surprising myself in deciding that my strong inclination towards 
considering as inviolate the terms of a license are trumped by 
circumstance. Given the exclusion of Geotoolkit from OSGeo, the 
importance of the Apache foundation to free software in general, the 
overwhelming contribution of Martin to the original Geotools code base, 
the extent to which the geotoolkit code has been refactored since them, 
it would strike me as most judicious for OSGeo to figure out a way for 
Geotoolkit to be able to join the Apache project.


   ~adrian custer



P.S. Like others, I find license discussions exceedingly burdensome, a 
necessary evil. Today, I have lost a few hours on this email. Therefore, 
I might simply ignore subsequent discussion, even if messages contain 
direct questions made to me. It is not that interesting.


[1] I was a minor contributor to Geotools, mostly on the analysis and 
documentation side and was then part of the Geotoolkit fork. Please do 
note however, that I have since moved on and am not working with any of 
those projects or talking to any of those folk these days, so this 
analysis, critique, and comments are my own only.


[2] I personally find the failure to make Martin a charter member as one 
glaring indictment of OSGeo and its community, revealing the inwards 
looking favoritism and lack of exploration beyond. There are few people 
as passionate, knowledgeable, or productive as Martin about free 
geospatial software so the fact that OSGeo has not managed to pull in 
his energy reveals both that the community fails to include some great 
folk and that OSGeo does not actually manage to represent the interests 
of 'free geospatial software' in general.


[3] For the pedantic, yes, the OSGeo incubating committee did not 
actually *deny* geotoolkit.  Indeed trac ticket 362 
(http://trac.osgeo.org/osgeo/ticket/362) is still open. However, the 
incubating committee slowly stopped communicating with the project 
resulting in a de facto rejection. Taking a formal decision might have 
required some fortitude but would have been more elegant.