Hi Adrian,
I have talked with Simone and he already provided you some feedbacks on
these things.
Please, read belove:
On Tue, Jan 20, 2009 at 3:33 PM, Adrian Custer <acus...@gmail.com> wrote:
> On Tue, 2009-01-20 at 12:25 +0100, Simone Giannecchini wrote:
> > Ciao Adrian,
> >
> > -- About Sun's code --
> >
> > Going from memory, we have borrowed some code in order to improve it
> > since sending patches to the imageio project was taking too much time
> > (no releases in the last 2 years). The imageio source code is licensed
> > as BSD (at least the java code), hence it should be perfectly legal to
> > reuse/modify/distribute it.
>
> Yes, if the license is the same as the one I saw this is true: it *is*
> free software. So, if you follow the restrictions in the license, *you*
> have the right to redistribute your work.
>
> Unfortunately, it is not compatible with the gpl/lgpl. The gpl type
> licenses do not allow field of use restrictions. Similarly, they tend to
> frown upon advertising clauses. So, you cannot distribute your
> imageio-ext under the lgpl since that license applies to the work as a
> whole.
>
> Also, this cascades down to GeoTools and to applications built on
> GeoTools. They can work fine if they force users to download your code
> separately, they can't be (l)gpl. You should probably bring this up to
> GeoServer since they might have expertise and advice on the subject.
>
>
> > Of course I might be wrong, but when I
> > asked the Imageio crew about reusing their code, after you raised
> > some concerns, I got no negative answer either. Of course, if you have
> > more info or you can point to links with more info, that would be
> > great, since, generally speaking, information is scarce and
> > fragmented.
>
> Stallman is not always right, but he generally does give us a great
> place to start:
>
> http://www.fsf.org/licensing/licenses/
> http://www.fsf.org/licensing/licenses/index_html#OriginalBSD
> http://www.fsf.org/licensing/essays/bsd.html
>
> >
> > Aside from this, I just had this thought, imageio and jai, which are
> > shipped with geotools, are in a similar situation, they have
> > limitations on where the code can be used, as of their licenses, could
> > this itself represent a problem which we should address as well?
>
> Lots of issues mixed in here. Yes, we have a fundamental problem in
> building free software on a non-free platform. Fortunately, we have, for
> years, had a possibility to get out of the 'java trap'. The CLASSPATH
> project has basically freed us from the trap; we are close to a free
> Java since we have OpenJDK and JDK7 will be only free software. JAI and
> Imageio may follow; the CLASSPATH folk are building the foundations of
> freedom for that software.
> However, we do not distribute JAI or Imageio, we get them directly from
> Sun, so we do not incur any responsibilities with regards to that code.
I have found jai_imageio-1.1.jar and jai_codec-1.1.3.jar in the
geotools-2.5.2-bin.zip<http://downloads.sourceforge.net/geotools/geotools-2.5.2-bin.zip?use_mirror=>
.
Therefore it seems that they are distributed and this could represent the
same problem involved in distributing our libs.
Regards,
Daniele
>
>
> >
> > -- About having coverage depending on imageio-ext --
> >
> > That is indeed an error and daniele is fixing it. Coverage should not
> > depend for the moment on imageio-ext. However this was done since
> > there are substantial bugs in the tiff imagereader/imagewriter which I
> > fixed in imageio-ext by including and improving Sun's code.
>
> We are waiting for you to show us this in Daniele's bug report.
>
>
> > We are
> > preparing patches for the imageio project for inclusion, but given the
> > timings of that project it is unlikely that we will see a new release
> > soon.
> >
> > -- About code you don't like in imageio-ext --
> >
> > Assuming that no core module will depend on imageio-ext for the time
> > being, which I agree would need more consensus, you have various
> > options:
> > 1> do not use plugins that depends on imageio-ext
>
> Yes, I already avoid those modules. But I want to make sure to keep that
> isolation clear as long as I am not confident in the code. It's hard to
> keep straight my responsibility under the lgpl, I really want not to
> have to think about other licenses. So I don't want that code anywhere
> near my build chain such as in my .m2 repo.
>
> We had a conditional dependency flag to avoid this code, why is that no
> longer suitable?
>
> > 2> submit a short enhancement report to the imageio-ext project, which
> > we will surely take into account.
>
>
> grep -i "sun" `find . -name "*\.java"` > lineList.text
>
> Import to gunmeric, break on space and colon, drop subsequent
> columns, export back to fileList.text.
>
> sort fileList.text | uniq > possibleSunList.text
>
> That's how I would build the list of files to track as separate.
>
> --adrian
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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
