Ciao Adrian, please read below... ------------------------------------------------------- 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 3:33 PM, Adrian Custer <[email protected]> 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. > Understood and agreed. We will repackage the code that comes from modifications of SUN's code as separate jars and we'll make more clear what type of license applies to such code. I guess in the end we will need to use a dual licensing sort of solutions since we have investigating deeper and the situation is quite garbled since the website of image says BSD but the license.ext says something different. So in the end we will resort to split down our code into basically two parts, one LGPL which contains the code compatible with LGPL, the other one, the one that comes from SUN' imageio code which will have a license similar to the IMAGEIO license, This should address most concerns, since we will be in a similar situation to jai and imageio. > 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 > Thx. >> >> 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. See here: http://jira.codehaus.org/browse/GEOT-2289 I admit I could be more specific :-). > > >> 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. K. > > We had a conditional dependency flag to avoid this code, why is that no > longer suitable? Well, I guess that under the supported land there should be no such flags. It was used as long as gdal support was under unsupported. > >> 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. Thanks for that, I always say that I should use grep more :-). However I was referring to sentences like this one: "The first was a utility class (seems like a good place to start, no?) which contained only static methods but had a chaotic view of inheritance: it's not final but not instantiable and then has some public, some private and some package-protected methods. " Ciao, Simone. > > --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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
