<br><br><div class="gmail_quote">On Fri, Jul 27, 2012 at 11:09 AM, Adrian Custer <span dir="ltr"><<a href="mailto:acuster@gmail.com" target="_blank">acuster@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello everyone,<br>
<br>
<br>
<br>
On 7/27/12 12:55 AM, Alex Mandel wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is a really interesting debate. Reading the links provided it also<br>
appears to be a mixed bag about acceptance of LGPL of various firms and<br>
I'm also sure many of us can name firms that have no issue shipping LGPL<br>
components.<br>
<br>
Aside from that though, reading about the Apache SIS project motivation<br>
and better understanding of why Geotools forked to begin with seem quite<br>
relevant. The first was easy to find, but does anyone have a good<br>
history of geotools v geotoolkit?<br>
</blockquote>
<br>
<br>
The fork had *nothing* to do with licensing but was primarily motivated by governance issues and differences of opinion in project direction.<br>
<br>
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.<br>

<br>
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.<br>

<br>
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.<br>

<br>
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.<br>

<br></blockquote><div>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. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As for the relicensing decision itself, here is my take.<br>
<br>
Note, that I am not unbiased in this issue [1], although I suspect my bias is more against OSGeo than for anyone in particular.<br>
<br>
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.<br>

<br>
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.<br>

<br>
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.<br>

<br>
<br>
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.<br>

<br>
<br>
  ~adrian custer<br>
<br>
<br>
<br>
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.<br>

<br>
<br>
[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.<br>

<br>
<br>
[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.<br>

<br>
<br>
[3] For the pedantic, yes, the OSGeo incubating committee did not actually *deny* geotoolkit.  Indeed trac ticket 362 (<a href="http://trac.osgeo.org/osgeo/ticket/362" target="_blank">http://trac.osgeo.org/osgeo/<u></u>ticket/362</a>) 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.<br>

<br>
<br>
<br>
______________________________<u></u>_________________<br>
Discuss mailing list<br>
<a href="mailto:Discuss@lists.osgeo.org" target="_blank">Discuss@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/discuss</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><font face="'courier new', monospace">Justin Deoliveira</font><div><font face="'courier new', monospace">OpenGeo - <a href="http://opengeo.org" target="_blank">http://opengeo.org</a></font></div>
<div><font face="'courier new', monospace">Enterprise support for open source geospatial.</font></div><br>