Ciao Andrea, lf you go ahead and create the wiki page, me and the other geosolutions guys will take care of going through the licenses of each dependency that is actually shipped with geotools in order to report them. I believe that instead of finding a specific solutions for the gdal plugin it is better to spend a little effort in fixing things from ground up.
Do we have a deal? 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 Wed, Jan 21, 2009 at 1:06 PM, Adrian Custer <acus...@gmail.com> wrote: > On Wed, 2009-01-21 at 11:43 +0100, Andrea Aime wrote: >> Adrian Custer ha scritto: >> > On Wed, 2009-01-21 at 10:17 +0100, Andrea Aime wrote: >> > ... >> >>> Adrian Custer ha scritto: >> >>>> How did you resolve the 'advertising clause' issue? Are we expecting to >> >>>> change all our docs to include the credit requested by SUN? >> > ... >> >> Reading into this GNU document about the nature of the >> >> BSD issue: >> >> http://www.gnu.org/philosophy/bsd.html >> >> >> >> It really seems the only issue GNU sees is a matter of >> >> practicality, that is, that if you have 70 different >> >> BSD style licenses, you have to add "full page ad" to >> >> the material you distribute to cite all of them... >> >> >> >> As usual, no lawyer, so I may be just plain wrong. >> > >> > That is my understanding as well. The GeoTools project and all dependent >> > projects would gain the obligation to cite SUN in their core project >> > document. Essentially, GeoTools becomes licensed under 'LGPL + >> > documentation obligation', if you will. >> > >> > This is not incompatible but will be more work and imposes a new >> > obligation so the change should be undertaken as a conscious decision >> > rather than happen as an un-intended side-effect of other work. >> >> What about the following: >> - someone takes a binary distribution of GeoTools, goes thru all the >> extra jas, and makes up a page with deps and their licenses. >> A simple table with the jar names grouped per license, and >> a reference to the license would do, wouldn't it? >> - we make it a project procedure that whoever adds a dependency >> to any supported module has to update that page >> - we also make it a project procedure that the release manager >> double checks the jars around during the release and sees >> if all of them are covered in the license page >> >> If that is ok, I'm ready to throw in a weekend of mine to setup >> the above wiki page >> Cheers >> Andrea > > Your proposal would be quite useful. The page would formally document > where we stand and your procedural proposal would formalize our > treatment of code dependencies. Together that would complete the review > that the OSGeo incubation started us off on. We may also discover that > we have additional responsibilities beyond what we thought. > > I suspect you will want to have separate sections for the core library, > the plugins, and the experimental work. > > Since you are willing to write up the page, please do that work. That > will give us a better sense of where we are today and should clarify the > next steps. We may indeed want to change the formal statement of the > overall project license from "this is lgpl" to some more accurate > statement. > > > The move to GPLv3+ would be wonderful as well. It would take me some > time to evaluate the difference between moving to LGPLv3 or GPL > +CLASSPATH since I have not read either license; I favour the latter > merely out of deference to the CLASSPATH project. But either way, they > are a better licenses for everyone, including GeoTools. And being able > to work with Apache code seems nothing but fantastic, well, actually, > merely reasonable in today's age. > > > So let's clarify where we stand globally first, then figure out what our > LICENSE files and headers should actually say to document that, and > third, if there is consensus and it simplifies things, upgrade the > license to a new version. > > You get the ball rolling and I'll pitch in on the second part. Yes, I > know it's shitty work---I'd rather be watching the clouds too. > > --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 > ------------------------------------------------------------------------------ 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
