[OSGeo-Discuss] The Geotools fork and current relicensing discussion [was Re: The importance of a project's license]
Adrian Custer
acuster at gmail.com
Fri Jul 27 11:09:18 PDT 2012
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.
More information about the Discuss
mailing list