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:55:29 |
Message-ID: | 3705826352029646A3E91C53F7189E32016750@sectorbase2.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > Application would explicitly call user_lock() functions in
> > queries, so issue is still not clear for me. And once again -
>
> Well, yes, it calls user_lock(), but the communication is not
> OS-linked, it is linked over a network socket, so I don't think
> the GPL spreads over a socket. Just as telnet'ing somewhere an
> typing 'bash' doesn't make your telnet GPL'ed, so I think the
> client code is safe. To the client, the backend is just
> returning information. You don't really link to the query
> results.
Ah, ok.
> > compare complexities of contrib/userlock and backend' userlock
> > code: what's reason to cover contrib/userlock by GPL?
>
> Only because Massimo prefers it. I can think of no other reason.
> It clearly GPL-stamps any backend that links it in.
Ok, let's do one step back - you wrote:
> 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.)
So, one would have to open-source and GPL all procedures/triggers
used by application just because of application uses user_lock()
in queries?! Is it good?
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-08-24 00:11:38 | Re: User locks code |
Previous Message | Bruce Momjian | 2001-08-23 23:34:40 | Re: User locks code |