Subject: Use by a Business

From: Mark Metson <[email-masked]>
Date: Mon, 30 May 1994 08:55:39 +0100

I am unclear how the postgres license is to be interpreted where a business
is thinking of using it. Not 'distributing' it, but using it and placing
it on more than one machine. (Distributing it within the company therefore
to be construed as commercial distribution?) I am a consultant employed by
a Collection Agency to support and develop their computer systems. They
currently run a package I wrote for them in Business Basic, running under
S.C.O. Unix System V. The Basic and the Unix cost $2500 and $2300 (cant 
recall which figure is for which of them). They do not wish to pay out
$4800 each time they bring up another machine, hence I propose to move them
to Linux. If I utilise postgres instead of Business Basic to rewrite the
package, where would we stand regarding postgres license? They do not intend,
nor, I suspect, desire, to distribute the package to other agencies. However
we would like to be able to write user-agents for clients to use in accessing
subsets of our data -- this need not require postgres though. Primarily we
need record-locking; it appears ingres and metalbase do not provide this
(at least for isam type databases) whereas postgres does. But postgres may
in many ways be overkill just to obtain that one capability; postgres seems
so powerful that if there is to be a charge for using it, we fear the charge
could be rather high; since we are only considering it due to this one
feature, we probably could not afford such a powerful solution.

They ARE perfectly willing to release all source code of anything they DO
distribute, its just they arent planning to distribute. Would they be
REQUIRED to distribute it to all agencies who express an interest in
obtaining the package, or would they just have to provide source and all
copyrights etc to anyone they DO distribute it to (probably no-one) ???

Blessed Be. -MarkM-

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "[email-masked]"

   If this fails, send mail to "[email-masked]" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================

---

From: [email-masked] (Paul M. Aoki)
Date: Mon, 30 May 94 12:40:03 -0700

Mark Metson <[email-masked]> writes:
> If I utilise postgres instead of Business Basic to rewrite the
> package, where would we stand regarding postgres license?

  Permission to use, copy, modify, and distribute this software and its
  documentation for educational, research, and non-profit purposes and
  without fee is hereby granted, provided that the above copyright
  notice appear in all copies and that both that copyright notice and
  this permission notice appear in supporting documentation, and that
  the name of the University of California not be used in advertising
  or publicity pertaining to distribution of the software without
  specific, written prior permission.  Permission to incorporate this
  software into commercial products can be obtained from the Campus
  Software Office, 295 Evans Hall, University of California, Berkeley,
  Ca., 94720.  The University of California makes no representations
  about the suitability of this software for any purpose.  It is
  provided "as is" without express or implied warranty.
 
offhand, i'd say if someone's making money from the construction
of a system, you should talk to the licensing people (just to be 
safe).

personally, i would not sell a package to a client that contained
postgres (or university ingres, for that matter -- i once told the
last ingres chief programmer about a product that had ingres89
embedded in it and his reaction was priceless).  i'd get a 
commercial database.  (but then, i'm the sort of person who'd say
that if my paycheck was on the line, i'd use bsd/386 instead of 
linux, too..  i like linux, but.. :-)

> Primarily we
> (at least for isam type databases) whereas postgres does.

nope, postgres doesn't do record locking either.  it does actually 
have a multilevel escalating lock manager built in, but it isn't
used at the record level.  it does do page-level locking for b-trees 
but not for r-trees and heaps.

(montage has page-level locking for heaps.)
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  [email-masked]
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki

---

From: Michael Ubell <[email-masked]>
Date: Mon, 30 May 94 12:47:38 -0700

>  it does do page-level locking for b-trees 

Doing page locking on b-trees but not on the underlying heap does not really
buy you anything since if you do an update the whole heap table is locked so
things will be single threaded no matter what you do in the b-tree.

---

From: Mark Metson <[email-masked]>
Date: Tue, 31 May 1994 02:40:14 +0100

Perhaps I dont really specifically need 'record locking' per se. I am 
just used to thinking in such terms because in Business Basic when I call 
up a record onscreen in modify mode for a user and dont want its contents 
changing behind their back, I "EXTRACT" the record. I dont like the idea 
of the entire (for example) debt-masterfile or client-masterfile locked
because one bozo went to lunch with one record onscreen in 
potentially-modifying mode, so the BASIC's approach of locking the record 
seemed a natural approach.

--
Mark Metson              How many mystics does it take to bring Peace on Earth?
[email-masked]    Only one - but each one has to do it for themself.....

---

From: Mark Metson <[email-masked]>
Date: Tue, 31 May 1994 02:55:02 +0100

On Mon, 30 May 1994, Paul M. Aoki wrote:

> Michael Ubell <[email-masked]> writes:
...
> (not that the last two messages have had anything to do with what 
> the guy was asking..)
...

Ah but they do, they do. Locking is the crux of the problem. I have a 
complete application running at a Collection Agency in Business Basic 
under SCO Unix System V. Standard code developed across a number of 
employers in which when you edit a masterfile record the record is locked 
using an 'EXTRACT' until unlocked using a READ or WRITE. Meanwhile it 
sits on user's screen over lunch or until per-input timeouts realise 
they've gone to lunch. There are two pricetags, $2500 and $2300, one for 
new unix, one for new BASIC (can never recall which is which), total 
$4800, which come up every time they think about computerising another 
branch office. Assuming they have $4800 on hand, we'd all feel better if 
they spent it on something more constructive, like buying hardware or 
paying me. I wanted GNU instead of UNIX in the first place, but it wasnt 
available back then. Now, the free unix I kept telling them was on the 
horizon is here, we want to move to it. We also would like to move from 
the BASIC if it'd be cheaper to rewrite than to buy a copy per possible 
new site, and may HAVE to move from BASIC if we cannot get Business Basic 
for Linux. I have just this day discovered some ALPHA code for running 
SCO SysV executables under Linux, so possibly I might be able to stay 
with BASIC, but if not, postgres is the only thing I've seen that might 
be useable in its place, other than to take some standard ISAM code and 
write a shared-memory record-locks-table or somesuch for it; and since 
Linux kernel support for arbitrary locks has no 
deadlock-detection/protection in it, I am rather wary of potential 
deadlock situations if I try to add a key with one task while deleting a 
key with another task in the same index; I suspect record-level locks on 
the blocks ofa Btree would be in real deadlock danger in such scenarios. 
I guess Business Basic spoiled me, I had never spent much thought on what 
nifty tricks the language was taking care of for me in its 
innocent-seeming record handling system.

Blessed Be. -MarkM-

---

From: [email-masked] (Paul M. Aoki)
Date: Mon, 30 May 94 19:53:06 -0700

Michael Ubell <[email-masked]> writes:
> >  it does do page-level locking for b-trees but not for r-trees and heaps.

well, yes.  to quote src/doc/implementation/am.me, written by mike 
olson (now at montage):

          Users  of the access method interface routines need not
     worry about locking.  The  access  method  routines  acquire
     (and,  when  appropriate,  release)  locks  on  relations in
     response to scans and updates.  Heap relations are protected
     by  two-phase  relation  level  locks.   Btree  indices  use
     Lehman-Yao5 short-term locking  for  high  concurrency,  but
     since  the  underlying  relations are locked at the relation
     level, index updates are serialized.  Rtree indices use two-
     phase relation-level locking.

        5 Lehman, P., Yao, S., ``Efficient Locking for Concurrent
     Operations  on  B-trees'', ACM Transactions on Database Sys-
     tems, 6(4), December 1981.

but having working b-link trees reduces the amount of work some 
hypothetical person would have to do to convert the core system to 
page-level locking.