RE: User locks code

Поиск
Список
Период
Сортировка
От Mikheev, Vadim
Тема RE: User locks code
Дата
Msg-id 3705826352029646A3E91C53F7189E3201674F@sectorbase2.sectorbase.com
обсуждение исходный текст
Ответ на User locks code  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Ответы Re: User locks code  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: User locks code
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Assessment on namespace clean include file names