> In particular, what kind of situation, legal and otherwise, are you
> creating for someone who may in the future want to implement a free
> version of these types?
Well, legal problems none at all: to paraphrase a bad rap tune,
people can "do what they like, be how they like". Our existance does
not create a legal constraint on people to do whatever they want with
their own code.
Otherwise problems, just the problem of our being there first: most
people won't be sufficiently loyal to the BSD licence to want to
reimplement the whole OpenGIS spec when there's already an open source
version around.
> This PostGIS project seems big enough that they can handle their own
> releases. I have a general problem with everything that comes our way
> being stuffed in contrib (imagine Perl shipping the whole CPAN in its
> tarball), but half a meg seems to be too much.
This is a valid point, but the line around where things get added or
not seems fuzzy. GIS support is as useful as soundex and probabilistic
matching functions, it is just inconveniently more involved and
therefor bigger. Is size the determinant? Licencing? Both? This is
something which probably should be hashed out in general. What
constitues the core product and (just as important) what are the
packaging standards for non-core modules which will allow them to
be added to the core with a minimum of effort (CPAN is an excellent
example).
--
__
/
| Paul Ramsey
| Refractions Research
| Email: pramsey@refractions.net
| Phone: (250) 885-0632
\_