Hi again,
here belove, the reply I did to Justin about the geotools release process:
--------------------------------------------------------------------------------------
I'm finishing to fix/rebuild/deploy/upload anything required for the
geotools imageio-ext-gdal plugin.
Anyway, due to physical time (human resources/internet resources) required
for uploading and deploying files, updating pages with the new imageio-ext
release, and doing additional tests, this could additionally delay the
process. Therefore I suggest to exclude the gt-imageio-ext-gdal plugin from
the 2.5.3 release and, consequently, from geoserver 1.7.2.
I will to remove that module in the main plugin pom.xml to let the release
proceed.
I also have re-opened the JIRA.
Regards,
Daniele
On Tue, Jan 20, 2009 at 6:14 PM, Simone Giannecchini <
simone.giannecch...@geo-solutions.it> wrote:
> Ok, I have investigated deeper and I think that we are good to go with
> pulling in imageio-ext (as long as imageio-ext use the correct
> licensing with respect to SUN's code :-) ).
> What I did:
> I have started to search for projects that I know are including code
> using modified code from JAI and Imageio and I have found a lot of
> info about the issue we have been talking about.
> I have focused especially on the ITEXT project which includes some
> code from ImageIO.
> As you can see from here (http://www.1t3xt.com/about/copyright/), they
> include enough information about third party code, and they include
> also some code from SUN. They incidentally use a dual licensing scheme
> BSD, LGPL, which I am going to use anyway for imageio-ext. From there
> I moved onto FEDORE since it seems that they are distributing itext
> and they had concerns about the nuclear facility stuff as well. As you
> can see from here (https://bugzilla.redhat.com/show_bug.cgi?id=465511)
> and here (https://admin.fedoraproject.org/pkgdb/packages/name/itext),
> FEDORE-LEGAL has worked on the potential problem and decided that it
> is not a problem at all (quoting them "I talked with RH Legal about it
> and we're now in agreement that the clause has been effectively
> altered to be a form of "warranty disclaimer". Lifting FE-Legal, you
> should be okay from a licensing perspective.").
>
> I guess this should help us with considering the issue closed, at
> least geotools-wise (and also GeoServer-wise). Opinions?
>
> Ciao,
> Simone.
> -------------------------------------------------------
> Ing. Simone Giannecchini
> GeoSolutions S.A.S.
> Owner - Software Engineer
> Via Carignoni 51
> 55041 Camaiore (LU)
> Italy
>
> phone: +39 0584983027
> fax: +39 0584983027
> mob: +39 333 8128928
>
>
> http://www.geo-solutions.it
> http://simboss.blogspot.com/
> http://www.linkedin.com/in/simonegiannecchini
>
> -------------------------------------------------------
>
>
>
> On Tue, Jan 20, 2009 at 5:52 PM, Martin Desruisseaux
> <martin.desruisse...@geomatys.fr> wrote:
> > Adrian Custer a écrit :
> >>> I have found jai_imageio-1.1.jar and jai_codec-1.1.3.jar in the
> geotools-2.5.2-bin.zip.
> >>> Therefore it seems that they are distributed and this could represent
> >>> the same problem involved in distributing our libs.
> >>
> >> Sounds like you have found a possible legal issue with GeoTools. I don't
> >> have any knowledge of those jars, of their contents, and of why we
> >> thought we had the right to distribute them.
> >
> >
> > A while ago, we required users to download and install JAI and Image I/O
> > themself in order to compile and use GeoTools. I was pushing for manual
> > installation partially because the installer include native libraries
> anyway.
> >
> > However we got very high pressure for including those JARs in the
> distribution.
> > Asking users to download from Sun and run the "setup.exe" program was
> considered
> > too much. I must said that at that time, GeoTools had JAI dependency
> right at
> > metadata level (the first module). Since that time, the JAI dependencies
> has
> > been reduced (enough for getting referencing to work without JAI), but
> not
> > totally removed on GeoTools 2.x trunk. On Geotidy, the separation is now
> total -
> > only coverage depends on JAI.
> >
> > For those wanting the inclusion of those JARs in the GeoTools
> distribution, I
> > believe that our understanding was that the GeoTools license applied to
> Geotools
> > modules only, not to the dependencies we bundled with it given that those
> > dependencies were just copied without changes. However maybe we have not
> > clarified enough this issue...
> >
> > I don't know what are the GeoTools community intend. On geotidy, I'm
> still
> > asking users to install JAI and Image I/O themself, but only if they want
> to use
> > coverages...
> >
> > Martin
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by:
> > SourcForge Community
> > SourceForge wants to tell your story.
> > http://p.sf.net/sfu/sf-spreadtheword
> > _______________________________________________
> > Geotools-devel mailing list
> > Geotools-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> >
> >
>
--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer
GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267
http://www.geo-solutions.it
-------------------------------------------------------
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
