Re: Proposal: replace no-overwrite with Berkeley DB
От | Tom Lane |
---|---|
Тема | Re: Proposal: replace no-overwrite with Berkeley DB |
Дата | |
Msg-id | 28437.958419360@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proposal: replace no-overwrite with Berkeley DB (Benjamin Adida <ben@mit.edu>) |
Ответы |
Re: Proposal: replace no-overwrite with Berkeley DB
(Bruce Momjian <pgman@candle.pha.pa.us>)
|
Список | pgsql-hackers |
Benjamin Adida <ben@mit.edu> writes: > If this were a totally new product, I think it might be an acceptable > license, a compromise between BSD's total freedom and the GPL's push to keep > things open-source. However, given that there are existing users of Postgres > who probably use the binary without distributing source, this license is > significantly more restrictive than the previous one, and would force > current users to review their practices. IMHO it would not be acceptable to make Postgres distribution even a little less free than it is now. However, it could be that we can get around that. According to the FAQ on Sleepycat's website, they consider that the open-source restriction applies to the software that directly calls Berkeley DB --- which would be Postgres. Code that sits atop Postgres could still be proprietary without triggering licensing requirements. So their existing policy is already close to what we'd need. Also, I note (forget if this is on their website or if it was in last night's private email) that Sleepycat have cut some sort of special licensing deal with Gnome to persuade the Gnome folks that it's OK for them to depend on Berkeley DB. So I expect they'd be open to making a similar deal with us. I think a written, signed agreement between Sleepycat and us, guaranteeing that Berkeley DB + Postgres could be distributed as freely as Postgres is now, is possible and would solve everyone's concerns on this issue. I'm more concerned about the technical issues, the biggest of which is how we can preserve MVCC semantics. Mike made a good point that users don't care about implementation technology --- but they do care about results, and MVCC's lack of locking (readers don't block writers nor vice versa) is an important result that I'm unwilling to give up. I'm also dissatisfied with the idea of going through a "Recno" access method to get at heap data; that sounds like a recipe for serious performance degradation. However, maybe we could address issues like that by working with the Sleepycat guys to develop a true heap access method within their framework. The MVCC issue is more serious because I'm not sure that could be added to their framework after-the-fact. If we go into this at all, we'd certainly *not* want to take the attitude that Berkeley DB is a closed box that we don't get to mess with. It's open source and we'd be contributing improvements to it, probably some pretty major ones. In effect we'd become partners with the Sleepycat guys --- and so another big issue is how comfortable we would be working together. But it could be a win-win proposition if we join forces to produce better software than either group could do alone. I'm not at all sold that this is a workable proposal --- but I think it has enough potential to be worth some close examination. regards, tom lane
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Vince VielhaberДата:
Сообщение: Re: broken links on http://www.postgresql.org/doxlist.html
Следующее
От: The Hermit HackerДата:
Сообщение: Re: FTP-sever ftp.postgresql.org unable to get dir-list ?