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 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@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.
_______________________________________________ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss