On Thu, 2008-08-07 at 19:30 +0200, Andrea Aime wrote: > Jody Garnett ha scritto: > > Adrian Custer wrote: > >> I've already lost time on this, on top of a bunch of other things so I > >> don't have time to chase down the problems and fix them. > >> > > You lost me? The problems seem to be in the imageio-ext project right - > > I am mostly focused on the geotools unsupported plugin here. > >>> I was under the impression that we were getting formal when code moved > >>> to a supported module; and we were going to try and not make > >>> the unsupported modules available for download (or at least in a > >>> separate jar). > >>> > >> yes, that seems reasonable and was my understanding as well. > >> > > Suppose I better go visit the 2.5.x branch and make sure that happens. > > So, if my understanding is right, being that module still > unsupported, it can be included in the build, right? > Can I switch it back to be included in the build? > Any other concern remaining?
If memory serves, the last time we had this discussion we agreed to wait for a first release of the imageio-ext project before considering it as a formal dependency. Whenever we do decide to consider it, we will probably want to discuss the benefits and costs of becoming formally dependent on that project and its long-term impact on Geotools---that's what we usually do. Our discussions around dependencies tend to be rich with voices for keeping the library light and others for increasing capabilities. So we will undoubtedly need to go through such a discussion. This library is particular: it appears light on the download since it is mostly stubs but is also useless without a native dependency which breaks the Java intent of Geotools. I imagine the discussion will be lively. However, today we cannot legally include the project in our build. There were files with confidential/proprietary code in the library which may or may not have all been removed and other files which conflict with the LGPL. That is all merely from the documentation within the files themselves. It appears, next time the project is proposed, we will have to do another cursory review of the licensing situation and code origin to ensure we have done due diligence towards our users and to prevent trivially obvious licensing conflicts. This is not a project issued from a group like Apache or the FSF which is well known to take particular care with their code origins so I would not expect anyone to be satisfied with merely accepting some unknown group's word for things. --adrian ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
