On Fri, Jul 27, 2012 at 11:09 AM, Adrian Custer acus...@gmail.com wrote:
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.
Thanks Adrian. I find this to be a very accurate and unbiased description
of the actual history and chain of events except for the part about it
being a friendly fork. I don't intend to reignite another flame war so i
won't go into detail but in my opinion (and i am speaking as
an individual on the PMC, and not for the entire PMC) things were left
trying to resolve the technical issues and not in a decision that Martin
should fork the code base. Taking into consideration this and the many
events (both online and offline) that have occurred since the origin of
GeoToolkit i would certainly classify it as a hostile fork.
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
