Обсуждение: Re: Proposal: replace no-overwrite with Berkeley DB
on 5/15/00 2:15 AM, Michael A. Olson at mao@sleepycat.com wrote: > Berkeley DB is Open Source. It's free for use in other Open Source > projects, like PostgreSQL. If a developer wants to use it in a > proprietary application, then the developer needs to pay Sleepycat > a licensing fee -- that's how we make our living. But Open Source > projects don't have to pay us anything. You can download the full > package from our Web site at www.sleepycat.com. I have to add my 0.02 to this issue. I read the informal description of the Sleepycat license (http://www.sleepycat.com/licensing.html). It looks like a commercial twist on BSD with a GPL sense to it. 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. It seems that forcing this new license on Postgres would be counter-productive at a time when the user base seems to be on the rise and PostgreSQL is starting to make a new, quality name for itself in the Open-Source community. This is by no means a judgement of Berkeley DB Data Store as a product, just a point about current users of PostgreSQL and their expectations. -Ben
> on 5/15/00 2:15 AM, Michael A. Olson at mao@sleepycat.com wrote: > > > Berkeley DB is Open Source. It's free for use in other Open Source > > projects, like PostgreSQL. If a developer wants to use it in a > > proprietary application, then the developer needs to pay Sleepycat > > a licensing fee -- that's how we make our living. But Open Source > > projects don't have to pay us anything. You can download the full > > package from our Web site at www.sleepycat.com. > > I have to add my 0.02 to this issue. I read the informal description of the > Sleepycat license (http://www.sleepycat.com/licensing.html). It looks like a > commercial twist on BSD with a GPL sense to it. > > 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. > > It seems that forcing this new license on Postgres would be > counter-productive at a time when the user base seems to be on the rise and > PostgreSQL is starting to make a new, quality name for itself in the > Open-Source community. > > This is by no means a judgement of Berkeley DB Data Store as a product, just > a point about current users of PostgreSQL and their expectations. Yes, it seems we would need some special arrangement from them. We don't plan on changing our license just to use Sleepycat DB. In fact, this is just an exploration. We don't even know if it will be a win for us. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
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
> 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. Another option is to keep our heap table structure intact, and just Sleepycat DB for our indexes. That may be a big win, with little downside. Certainly something to think about. It may work better with MVCC, and allow fast sequential scans and fast heap access from the indexs, without having to go through the db structures to get to it. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Several people have asked about the terms of the Berkeley DB license,
and the conditions under which users need to pay Sleepycat for
redistribution.
To clarify, you're permitted to redistribute binary copies of your
application, including Berkeley DB, as long as source code is freely
available *somewhere*. Anyone could compile and sell PostgreSQL on
a CD without paying Sleepycat, because the source code remains
available on PostgreSQL.org.
Lots of people ship binary copies of the OpenLDAP directory server,
which uses Berkeley DB. They don't pay us. Only the companies that
ship proprietary directory servers do.
License fees are only required if you make a proprietary version of
the Open Source product. For example, if a vendor took PostgreSQL,
made changes to the backend, and didn't contribute those changes
back to PostgreSQL.org, then the vendor would have to pay Sleepycat
for the right to redistribute our software as a part of the package.
For the purposes of this proposal, we'd consider the PostgreSQL
backend to be the embedding app -- that is, anyone could develop
new proprietary clients, since those don't directly embed our code.
And we stipulate that dynamically-loaded functions that implement
user-defined types and functions don't constitute changes to the
backend.
So the only case in which a license fee would be required would
be if someone forked the backend and kept their changes proprietary.
I'm not aware of anyone distributing a forked version of the
backend now, but I've been outside the community for a while now.
I understand the implications of the BSD and GPL licenses, and why
they're appropriate or inappropriate for particular cases. If the
Berkeley DB license imposes conditions on PostgreSQL that aren't
in keeping with the desires of the developers, then of course the
proposed project won't work.
If you've got additional questions on the license, ask away.
mike
> Several people have asked about the terms of the Berkeley DB license, > and the conditions under which users need to pay Sleepycat for > redistribution. > > To clarify, you're permitted to redistribute binary copies of your > application, including Berkeley DB, as long as source code is freely > available *somewhere*. Anyone could compile and sell PostgreSQL on > a CD without paying Sleepycat, because the source code remains > available on PostgreSQL.org. > > Lots of people ship binary copies of the OpenLDAP directory server, > which uses Berkeley DB. They don't pay us. Only the companies that > ship proprietary directory servers do. > > License fees are only required if you make a proprietary version of > the Open Source product. For example, if a vendor took PostgreSQL, > made changes to the backend, and didn't contribute those changes > back to PostgreSQL.org, then the vendor would have to pay Sleepycat > for the right to redistribute our software as a part of the package. Seems this changes our license more toward GPL. I don't think that is going to be supportable by the group. I doubt we are willing to modify our license in order to use the Sleepycat DB code. We don't use GPL code in PostgreSQL for the same reason. > I understand the implications of the BSD and GPL licenses, and why > they're appropriate or inappropriate for particular cases. If the > Berkeley DB license imposes conditions on PostgreSQL that aren't > in keeping with the desires of the developers, then of course the > proposed project won't work. Sorry, looks like a deal killer. Of course, others will voice their opinions. This is just my guess. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
At 11:08 AM 5/16/00 +1000, you wrote:
> Essentially, this is the same as the GPL licence, right?
Yes, except that companies that want to distribute proprietary versions
can pay for the privilege.
mike
At 09:15 PM 5/15/00 -0400, you wrote: > Sorry, looks like a deal killer. Of course, others will voice their > opinions. This is just my guess. Given the preferences that I've heard expressed so far, I think you're probably right. And it sounds as if Vadim's making progress on a WAL that will preserve multi-versioning, so that's another reason for you to stick with what you've got now. Never hurts to ask, though :-). If the situation changes at some point, and you'd like to resume the discussion, we'd be glad to do that. mike
On Mon, 15 May 2000, Bruce Momjian wrote: > > Several people have asked about the terms of the Berkeley DB license, > > and the conditions under which users need to pay Sleepycat for > > redistribution. > > > > To clarify, you're permitted to redistribute binary copies of your > > application, including Berkeley DB, as long as source code is freely > > available *somewhere*. Anyone could compile and sell PostgreSQL on > > a CD without paying Sleepycat, because the source code remains > > available on PostgreSQL.org. > > > > Lots of people ship binary copies of the OpenLDAP directory server, > > which uses Berkeley DB. They don't pay us. Only the companies that > > ship proprietary directory servers do. > > > > License fees are only required if you make a proprietary version of > > the Open Source product. For example, if a vendor took PostgreSQL, > > made changes to the backend, and didn't contribute those changes > > back to PostgreSQL.org, then the vendor would have to pay Sleepycat > > for the right to redistribute our software as a part of the package. > > Seems this changes our license more toward GPL. I don't think that is > going to be supportable by the group. I doubt we are willing to modify > our license in order to use the Sleepycat DB code. I don't know ... I read this as totally anti-GPL ... "you are more then welcome to distribute binary only, but then you have to pay us for use of our libraries" ... ... the only aspect that would worry me is if SleepCat were to change their license and make it more restrictive ...
> > Seems this changes our license more toward GPL. I don't think that is > > going to be supportable by the group. I doubt we are willing to modify > > our license in order to use the Sleepycat DB code. > > I don't know ... I read this as totally anti-GPL ... "you are more then > welcome to distribute binary only, but then you have to pay us for use of > our libraries" ... > > ... the only aspect that would worry me is if SleepCat were to change > their license and make it more restrictive ... But it ties the hands of binary-only distributors, or pay them. Not a good choice. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Mon, 15 May 2000, Bruce Momjian wrote: > > > Seems this changes our license more toward GPL. I don't think that is > > > going to be supportable by the group. I doubt we are willing to modify > > > our license in order to use the Sleepycat DB code. > > > > I don't know ... I read this as totally anti-GPL ... "you are more then > > welcome to distribute binary only, but then you have to pay us for use of > > our libraries" ... > > > > ... the only aspect that would worry me is if SleepCat were to change > > their license and make it more restrictive ... > > But it ties the hands of binary-only distributors, or pay them. Not a > good choice. Woah here ... didn't Michael state that binary-only was okay, as long as the source *was* available on the 'Net? ie. Enhydra can distribute their binaries, as long as sources were still available on postgresql.org?
At 11:52 AM 5/16/00 +1000, Chris Bitmead wrote:
> That's no different to GPL. One is always free to negotiate with the
> author a fee to not have to abide the standard licence. Out of
> curiousity, any reason you didn't just use the GPL as-is since it is the
> same idea?
Berkeley DB already carried the University of California copyright,
and we couldn't remove it or the conditions it imposed. We'd have
preferred the GPL but we'd have had to craft a more complicated and
newer license the preserved the UC terms and the GNU terms.
mike
> On Mon, 15 May 2000, Bruce Momjian wrote: > > > > > Seems this changes our license more toward GPL. I don't think that is > > > > going to be supportable by the group. I doubt we are willing to modify > > > > our license in order to use the Sleepycat DB code. > > > > > > I don't know ... I read this as totally anti-GPL ... "you are more then > > > welcome to distribute binary only, but then you have to pay us for use of > > > our libraries" ... > > > > > > ... the only aspect that would worry me is if SleepCat were to change > > > their license and make it more restrictive ... > > > > But it ties the hands of binary-only distributors, or pay them. Not a > > good choice. > > Woah here ... didn't Michael state that binary-only was okay, as long as > the source *was* available on the 'Net? ie. Enhydra can distribute their > binaries, as long as sources were still available on postgresql.org? But that limits companies from distributing binary-only versions where they don't want to give out the source. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Woah here ... didn't Michael state that binary-only was okay, as long as
>> the source *was* available on the 'Net? ie. Enhydra can distribute their
>> binaries, as long as sources were still available on postgresql.org?
> But that limits companies from distributing binary-only versions where
> they don't want to give out the source.
The way I read it was that as long as *we* are making Postgres source
available, people using Postgres as a component wouldn't have to, nor
make their own source available which'd probably be the real issue.
OTOH, there'd still be a problem with distributing slightly-modified
versions of Postgres --- that might require a Sleepycat license.
On the whole this seems like a can of worms better left unopened.
We don't want to create questions about whether Postgres is free
or not.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> Woah here ... didn't Michael state that binary-only was okay, as long as > >> the source *was* available on the 'Net? ie. Enhydra can distribute their > >> binaries, as long as sources were still available on postgresql.org? > > > But that limits companies from distributing binary-only versions where > > they don't want to give out the source. > > The way I read it was that as long as *we* are making Postgres source > available, people using Postgres as a component wouldn't have to, nor > make their own source available which'd probably be the real issue. > > OTOH, there'd still be a problem with distributing slightly-modified > versions of Postgres --- that might require a Sleepycat license. > > On the whole this seems like a can of worms better left unopened. > We don't want to create questions about whether Postgres is free > or not. Agreed. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Seems like something went wrong with the new Majordomo. I used to get ~50-60 messages per day from pgsql-hackers and interfaces lists. Now I get 1-2 per day. It started last week. Apparently something is wrong with the majordomo setup. Gene Sokolov.
PRS ... PostReleaseSyndrome ... ppl are rebuilding up their energy,
watching for bugs while waiting for development to start up again.
On Tue, 16 May 2000, Gene Sokolov wrote:
> Seems like something went wrong with the new Majordomo. I used to get ~50-60
> messages per day from pgsql-hackers and interfaces lists. Now I get 1-2 per
> day. It started last week. Apparently something is wrong with the majordomo
> setup.
>
> Gene Sokolov.
>
>
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
> PRS ... PostReleaseSyndrome ... ppl are rebuilding up their energy,
> watching for bugs while waiting for development to start up again.
If he's only getting one or two messages a day, then something's surely
broken! According to my maillog there were 92 messages on the pghackers
list yesterday, and another 20+ on interfaces.
However, I'm inclined to think that the breakage is on his end, since
no one else is complaining ...
BTW, did I mention that I confirmed majordomo had lost my subscription
to pgsql-patches? I did a who on the list and found no entry. Curious.
Doesn't seem to have happened on any other list, but it explains why
I've seen no patches for a good while.
regards, tom lane
On Tue, 16 May 2000, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > PRS ... PostReleaseSyndrome ... ppl are rebuilding up their energy, > > watching for bugs while waiting for development to start up again. > > If he's only getting one or two messages a day, then something's surely > broken! According to my maillog there were 92 messages on the pghackers > list yesterday, and another 20+ on interfaces. > > However, I'm inclined to think that the breakage is on his end, since > no one else is complaining ... Regardless of which end is at fault, I am looking at this from our end anyway ... I'm wondering if maybe there was a connection problem to his system and the mail system itself just bounced it ... > BTW, did I mention that I confirmed majordomo had lost my subscription > to pgsql-patches? I did a who on the list and found no entry. > Curious. Doesn't seem to have happened on any other list, but it > explains why I've seen no patches for a good while. I'm embarressed to say that the Mj2 guys took a look at our system logs and, ummmm, it doesn't look like some ppl were subscribed to the pgsql-patches list when we first moved it over :( Looks like definitely operator error on this one *sigh*
From: "The Hermit Hacker" <scrappy@hub.org> > On Tue, 16 May 2000, Tom Lane wrote: > > The Hermit Hacker <scrappy@hub.org> writes: > > > PRS ... PostReleaseSyndrome ... ppl are rebuilding up their energy, > > > watching for bugs while waiting for development to start up again. > > > > If he's only getting one or two messages a day, then something's surely > > broken! According to my maillog there were 92 messages on the pghackers > > list yesterday, and another 20+ on interfaces. > > > > However, I'm inclined to think that the breakage is on his end, since > > no one else is complaining ... > > Regardless of which end is at fault, I am looking at this from our end > anyway ... I'm wondering if maybe there was a connection problem to his > system and the mail system itself just bounced it ... Thanks for helping me. Unfortunately your subscription reset did not help. The traffic is still the same. I don't believe the problem is on my end becuase the traffic I get from the freebsd-stable as well as a couple of other lists is usual. I also get a large traffic from customers, which is not affected in any way. Just the two postgres lists are affected. I vaguely remember getting a couple of test messages from one of the pg lists about ten days ago and I think the volume dropped right after that. We did have a connectivity outage some time ago when both our primary and seconday MXs were unavailable, but it did not last longer than a couple of hours. If Majordomo unsubscribed me, I wonder why I still get any traffic from pg and why the subscription reset did not help. Gene Sokolov.
On Wed, 17 May 2000, Gene Sokolov wrote: > From: "The Hermit Hacker" <scrappy@hub.org> > > On Tue, 16 May 2000, Tom Lane wrote: > > > The Hermit Hacker <scrappy@hub.org> writes: > > > > PRS ... PostReleaseSyndrome ... ppl are rebuilding up their energy, > > > > watching for bugs while waiting for development to start up again. > > > > > > If he's only getting one or two messages a day, then something's surely > > > broken! According to my maillog there were 92 messages on the pghackers > > > list yesterday, and another 20+ on interfaces. > > > > > > However, I'm inclined to think that the breakage is on his end, since > > > no one else is complaining ... > > > > Regardless of which end is at fault, I am looking at this from our end > > anyway ... I'm wondering if maybe there was a connection problem to his > > system and the mail system itself just bounced it ... > > Thanks for helping me. Unfortunately your subscription reset did not help. > The traffic is still the same. I don't believe the problem is on my end > becuase the traffic I get from the freebsd-stable as well as a couple of > other lists is usual. I also get a large traffic from customers, which is > not affected in any way. Just the two postgres lists are affected. > > I vaguely remember getting a couple of test messages from one of the pg > lists about ten days ago and I think the volume dropped right after that. > > We did have a connectivity outage some time ago when both our primary > and seconday MXs were unavailable, but it did not last longer than a couple > of hours. If Majordomo unsubscribed me, I wonder why I still get any traffic > from pg and why the subscription reset did not help. Are you running any kind of filtering software? Procmail or perhaps something built into OE? Maybe there's a header that you're keying off of that's dumping the mail to the trash. Around the time of the test messages was the mail2news gateway stuff, I don't know if there were any more headers put in tho. (haven't paid attention) Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
From: "Vince Vielhaber" <vev@michvhf.com> > Are you running any kind of filtering software? Procmail or perhaps > something built into OE? Maybe there's a header that you're keying off > of that's dumping the mail to the trash. Around the time of the test > messages was the mail2news gateway stuff, I don't know if there were any > more headers put in tho. (haven't paid attention) No, I don't have any filters. But even if the mail was dumped to the trash, I should have seen it there. I just checked maillog on our primary MX (sendmail 8.9.3). Grepping for hub.org and postgresql.org produced just 2 entries. Grepping the same log for freebsd.org produced a few dozen entries which is about the right number for the traffic there. This evidently rules out any settings local to my workstation. I tend to believe that majordomo is not even trying to deliver anything to me. Is it possible that majordomo2 can automatically consider some domains "bad" and not deliver? Something like compiling a list of domains where it once failed to deliver mail? Gene Sokolov.
The Hermit Hacker <scrappy@hub.org> writes: > I don't know ... I read this as totally anti-GPL ... "you are more then > welcome to distribute binary only, but then you have to pay us for use of > our libraries" ... GPL (as opposed to LGPL) has been used for that purpose - either GPL your code, or if you want to keep it proprietary: Pay us, and we'll give you the same code with a different license. -- Trond Eivind Glomsrød Red Hat, Inc.