The schema and refdataset jars are only used in GeoTools and GeoServer 
tests. These artifacts are not deployed as part of a GeoTools or 
GeoServer release and have version numbers governed elsewhere (plus a 
packager suffix) and are unrelated to GeoTools release numbers. 
Deployment is a manual process. I agree that migrating refdataset would 
require cleaning up its governance; this would be a good thing.

The refdataset SQL has been contributed to OSGeo. The provenance is 
clean: origin was DPI Victoria (state of Australia), the only licence 
requirement was mandatory modification. This was performed by Victor Tey 
of CSIRO, the originator of refdataset and the corresponding tests in 
GeoServer app-schema-test. CSIRO contributed this content as a corporate 
osgeo contributor. The SQL *could* go into git, but *should* it? It is a 
big chunk of data.

The app-schema-packages artifacts are more problematic, and have IP issues:
https://github.com/geotools/geotools/tree/master/modules/extension/app-schema/app-schema-packages

These poms build unmodified copies of public documents that are used 
only for testing. I argue that this is a caching mechanism (but I am not 
a lawyer). Most are OGC and IUGS-CGI schemas. These organisations are 
all for interoperability; our use is testing our software for 
compatibility with their schemas. However, an example IUGS-CGI copyright 
statement is: "Copyright (c) Commission for the Management and 
Application of Geoscience Information 2013. All rights reserved." These 
documents are AFAICT incompatible with the LGPL. I do not see how we can 
check these into git. The OGC licence is much more permissive.

Some mention of the more ancient schemas here as well (app-schema IP 
review):
http://jira.codehaus.org/browse/GEOT-3623

See also (legality of caching content provided for free):
http://en.wikipedia.org/wiki/Field_v._Google,_Inc.
http://www.theregister.co.uk/2006/01/27/google_cache_copyright_breach_ruling/

Kind regards,
Ben.

On 18/03/15 17:15, Chris Bennight wrote:
> 3 - I have to admit I'm not as familiar with this.  Are these things people
> need if they want to use geotools, write a geoserver plugin, or are these
> things needed for GeoServer integration/verification tests?  That said, as
> long as the group has redistribution rights I don't see any reason why
> those couldn't be uploaded.  (Other than the work you mentioned that would
> have to be done to pomify/version control the refdataset jar, which could
> be added to this proposal)

-- 
Ben Caradoc-Davies <[email protected]>
Director
Transient Software Limited <http://transient.nz>
New Zealand

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to