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

Fri Jul 27 13:01:46 PDT 2012

On Fri, Jul 27, 2012 at 11:09 AM, Adrian Custer <acuster at 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 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 <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.
>
>
>
> ______________________________**_________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/discuss<http://lists.osgeo.org/mailman/listinfo/discuss>
>

-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20120727/95977898/attachment-0002.html>