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
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 |