> > 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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
