Re: contrib/postgis spatial extensions
От | Paul Ramsey |
---|---|
Тема | Re: contrib/postgis spatial extensions |
Дата | |
Msg-id | 3B71CA4E.A71EA7BF@refractions.net обсуждение исходный текст |
Ответ на | Re: contrib/postgis spatial extensions (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: contrib/postgis spatial extensions
|
Список | pgsql-patches |
> 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 \_
В списке pgsql-patches по дате отправления: