Re: a faster compression algorithm for pg_dump
От
Greg Stark
Тема
Re: a faster compression algorithm for pg_dump
Дата
Msg-id
r2m407d949e1004082051oc6ddeb1cm5f2b2b7cf259640a@mail.gmail.com
Ответ на
a faster compression algorithm for pg_dump (Joachim Wieland)
Список
Дерево обсуждения
a faster compression algorithm for pg_dump Joachim Wieland <joe@mcknight.de>
Re: a faster compression algorithm for pg_dump Greg Stark <gsstark@mit.edu>
Re: a faster compression algorithm for pg_dump Joachim Wieland <joe@mcknight.de>
Re: a faster compression algorithm for pg_dump Tom Lane <tgl@sss.pgh.pa.us>
Re: a faster compression algorithm for pg_dump daveg <daveg@sonic.net>
Re: a faster compression algorithm for pg_dump Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Re: a faster compression algorithm for pg_dump Dimitri Fontaine <dfontaine@hi-media.com>
Re: a faster compression algorithm for pg_dump Bruce Momjian <bruce@momjian.us>
On Fri, Apr 9, 2010 at 12:17 AM, Joachim Wieland wrote: > One question that I do not yet see answered is, do we risk violating a > patent even if we just link against a compression library, for example > liblzf, without shipping the actual code? > Generally patents are infringed on when the process is used. So whether we link against or ship the code isn't really relevant. The user using the software would need a patent license either way. We want Postgres to be usable without being dependent on any copyright or patent licenses. Linking against as an option isn't nearly as bad since the user compiling it can choose whether to include the restricted feature or not. That's what we do with readline. However it's not nearly as attractive when it restricts what file formats Postgres supports -- it means someone might generate backup dump files that they later discover they don't have a legal right to read and restore :( -- greg
В списке pgsql-hackers по дате отправления