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