RE: User locks code - Mailing list pgsql-hackers

From Mikheev, Vadim
Subject RE: User locks code
Date
Msg-id 3705826352029646A3E91C53F7189E3201674F@sectorbase2.sectorbase.com
Whole thread Raw
In response to User locks code  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Responses Re: User locks code
List 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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: User locks code
Next
From: Tom Lane
Date:
Subject: Re: Assessment on namespace clean include file names