RE: User locks code

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Massimo Dal Zotto <dz(at)cs(dot)unitn(dot)it>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: User locks code
Date: 2001-08-23 23:24:39
Message-ID: 3705826352029646A3E91C53F7189E3201674F@sectorbase2.sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > > I assume any code that uses contrib/userlock has to be GPL'ed,
> > > meaning it can be used for commercial purposes but can't be sold
> > > as binary-only, and actually can't be sold for much because you
> > > have to make the code available for near-zero cost.
> >
> > I'm talking not about solding contrib/userlock separately, but
> > about ability to sold applications which use contrib/userlock.
> > Sorry, if it was not clear.
>
> No, you were clear.

So I missed your "near-zero cost" sentence.

> My assumption is that once you link that code into
> the backend, the entire backend is GPL'ed and any other
> application code you link into it is also (stored procedures,
> triggers, etc.) I don't think your client application will
> be GPL'ed, assuming you didn't link in libreadline.

Application would explicitly call user_lock() functions in
queries, so issue is still not clear for me. And once again -
compare complexities of contrib/userlock and backend' userlock
code: what's reason to cover contrib/userlock by GPL?

Vadim

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-08-23 23:27:01 Re: Assessment on namespace clean include file names
Previous Message Bruce Momjian 2001-08-23 23:04:28 Re: User locks code