I am considering moving some of the community-schemas code base from GeoServer to GeoTools. This raises several issues.
(1) Is there any copyright or licensing problem moving GeoServer code to GeoTools?
(2) Which copyright headers should they use? Their original ones, or should they be changed to the new project?
(3) Is there a best/preferred practice for how to do this? Dumb copy (losing history), svnadmin dump ...
The code in question includes the WFS binding overrides in the wfs-c fork in the 1.6.x branch. Having these binding overrides in GeoServer prevents any GeoTools unit tests from touching them. This has allowed some deficiencies in GeoTools community-schemas-ds to persist for far too long. The key problem is that the existing GeoTools community-schemas-ds unit tests cover feature construction but not encoding, and there are no useful unit tests(!) for GeoServer community-schemas. Half of the action happens during encoding, so this is a big problem. This situation can be remedied by moving the bindings to GeoTools, and doing a lot of work to retrofit unit tests.
I won't be moving this code right away, but it has to be done. It should probably be done when we port community-schemas to trunk, to minimise the carnage.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Hi Ben,
I don't think there will be any issues moving them across. Technically topp owns copyright on GeoServer code, but in cases such as these (and i could be wrong here) topp is willing to give up copyright and assign it to Geotools directly.
So i think the easiest path would be just to do the move and assign a regular geotools / osgeo copyright header.
As for keeping svn history I am not sure that will be easy since they are in different svn repositories. If its easy to svn dump and import a single file then i would do that... but otherwise I would just manually copy the file over, maybe noting the original location in the GeoServer repo to that is someone really wants to dig up the history can.
-Justin
Ben Caradoc-Davies wrote:
I am considering moving some of the community-schemas code base from GeoServer to GeoTools. This raises several issues.
(1) Is there any copyright or licensing problem moving GeoServer code to GeoTools?
(2) Which copyright headers should they use? Their original ones, or should they be changed to the new project?
(3) Is there a best/preferred practice for how to do this? Dumb copy (losing history), svnadmin dump ...
The code in question includes the WFS binding overrides in the wfs-c fork in the 1.6.x branch. Having these binding overrides in GeoServer prevents any GeoTools unit tests from touching them. This has allowed some deficiencies in GeoTools community-schemas-ds to persist for far too long. The key problem is that the existing GeoTools community-schemas-ds unit tests cover feature construction but not encoding, and there are no useful unit tests(!) for GeoServer community-schemas. Half of the action happens during encoding, so this is a big problem. This situation can be remedied by moving the bindings to GeoTools, and doing a lot of work to retrofit unit tests.
I won't be moving this code right away, but it has to be done. It should probably be done when we port community-schemas to trunk, to minimise the carnage.
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com