Horton
Menu

Thread

  1. RE: User locks code

    Mikheev, Vadim <vmikheev@sectorbase.com> — 2001-08-19T18:20:12Z

    Well, ability to lock only unlocked rows in select for update is useful,
of course. But uniq features of user'locks are:

1. They don't interfere with normal locks hold by session/transaction.
2. Share lock is available.
3. User can lock *and unlock objects* inside transaction, which is not
    (and will not be) available with locks held by transactions.

They are interesting too and proposed implementation will not impact lock
manager (just additional 4 bytes in LOCKTAG => same size of LOCKTAG
on machines with 8 bytes alignment).

> An interesting method would be to allow users to simply avoid locked
> rows:
>
> SELECT * FROM queue FOR UPDATE LIMIT 1 UNLOCKED;
>
> Unlocked, return immediately, whatever could be used as a keyword to
> avoid rows that are locked (skipping over them).
>
> For update locks the row of course.  Currently for the above type of
> thing I issue an ORDER BY random() which avoids common rows enough,
> the queue agent dies if queries start taking too long (showing it's
> waiting for other things) and tosses up new copies if it goes a while
> without waiting at all (showing increased load).
>
> --
> Rod Taylor
>
> This message represents the official view of the voices in my head
>
> ----- Original Message -----
> From: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
> To: <pgsql-hackers@postgresql.org>
> Sent: Friday, August 17, 2001 2:48 PM
> Subject: [HACKERS] User locks code
>
>
> > 1. Just noted this in contrib/userlock/README.user_locks:
> >
> > > User locks, by Massimo Dal Zotto <dz@cs.unitn.it>
> > > Copyright (C) 1999, Massimo Dal Zotto <dz@cs.unitn.it>
> > >
> > > This software is distributed under the GNU General Public License
> > > either version 2, or (at your option) any later version.
> >
> > Well, anyone can put code into contrib with whatever license
> > he/she want but "user locks" package includes interface
> > functions in contrib *and* changes in our lock manager, ie
> > changes in backend code. I wonder if backend' part of package
> > is covered by the same license above? And is it good if yes?
> >
> > 2. Not good implementation, imho.
> >
> > It's too complex (separate lock method table, etc). Much cleaner
> > would be implement this feature the same way as transactions
> > wait other transaction commit/abort: by locking objects in
> > pseudo table. We could get rid of offnum and lockmethod from
> > LOCKTAG and add
> >
> > struct
> >

> > Oid RelId;
> > Oid ObjId;
> > } userObjId;
> >
> > to objId union of LOCKTAG.
> >
> > This way user could lock whatever object he/she want in specified
> > table and note that we would be able to use table access rights to
> > control if user allowed to lock objects in table - missed in 1.
> >
> > One could object that 1. is good because user locks never wait.
> > I argue that "never waiting" for lock is same bad as "always
> waiting".
> > Someday we'll have time-wait etc features for general lock method
> > and everybody will be happy -:)
> >
> > Comments?
> >
> > Vadim
> > P.S. I could add 2. very fast, no matter if we'll keep 1. or not.
> >
> > ---------------------------(end of
> broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly
> >
>

  2. Re: User locks code

    Massimo Dal Zotto <dz@cs.unitn.it> — 2001-08-19T21:15:54Z

    > Well, ability to lock only unlocked rows in select for update is useful,
> of course. But uniq features of user'locks are:
> 
> 1. They don't interfere with normal locks hold by session/transaction.
> 2. Share lock is available.
> 3. User can lock *and unlock objects* inside transaction, which is not
>     (and will not be) available with locks held by transactions.
> 
> They are interesting too and proposed implementation will not impact lock
> manager (just additional 4 bytes in LOCKTAG => same size of LOCKTAG
> on machines with 8 bytes alignment).
> 
> > An interesting method would be to allow users to simply avoid locked
> > rows:
> >
> > SELECT * FROM queue FOR UPDATE LIMIT 1 UNLOCKED;
> >
> > Unlocked, return immediately, whatever could be used as a keyword to
> > avoid rows that are locked (skipping over them).
> >
> > For update locks the row of course.  Currently for the above type of
> > thing I issue an ORDER BY random() which avoids common rows enough,
> > the queue agent dies if queries start taking too long (showing it's
> > waiting for other things) and tosses up new copies if it goes a while
> > without waiting at all (showing increased load).
> >
> > --
> > Rod Taylor
> >
> > This message represents the official view of the voices in my head
> >
> > ----- Original Message -----
> > From: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
> > To: <pgsql-hackers@postgresql.org>
> > Sent: Friday, August 17, 2001 2:48 PM
> > Subject: [HACKERS] User locks code
> >
> >
> > > 1. Just noted this in contrib/userlock/README.user_locks:
> > >
> > > > User locks, by Massimo Dal Zotto <dz@cs.unitn.it>
> > > > Copyright (C) 1999, Massimo Dal Zotto <dz@cs.unitn.it>
> > > >
> > > > This software is distributed under the GNU General Public License
> > > > either version 2, or (at your option) any later version.
> > >
> > > Well, anyone can put code into contrib with whatever license
> > > he/she want but "user locks" package includes interface
> > > functions in contrib *and* changes in our lock manager, ie
> > > changes in backend code. I wonder if backend' part of package
> > > is covered by the same license above? And is it good if yes?
> > >
> > > 2. Not good implementation, imho.
> > >
> > > It's too complex (separate lock method table, etc). Much cleaner
> > > would be implement this feature the same way as transactions
> > > wait other transaction commit/abort: by locking objects in
> > > pseudo table. We could get rid of offnum and lockmethod from
> > > LOCKTAG and add
> > >
> > > struct
> > >
> 
> > > Oid RelId;
> > > Oid ObjId;
> > > } userObjId;
> > >
> > > to objId union of LOCKTAG.
> > >
> > > This way user could lock whatever object he/she want in specified
> > > table and note that we would be able to use table access rights to
> > > control if user allowed to lock objects in table - missed in 1.
> > >
> > > One could object that 1. is good because user locks never wait.
> > > I argue that "never waiting" for lock is same bad as "always
> > waiting".
> > > Someday we'll have time-wait etc features for general lock method
> > > and everybody will be happy -:)
> > >
> > > Comments?
> > >
> > > Vadim
> > > P.S. I could add 2. very fast, no matter if we'll keep 1. or not.
> > >

4. Most important: user locks are retained across transaction, which is
   not possible with ordinary locks.

5. User locks semantic is defined entirely by the application and is not
   related to rows in the database.

I wrote the user locks code because I needed a method to mark items as
`busy' for very long time to avoid more users modifying the same object
and overwriting each one's changes. This requires two features:

    1.	they must survive transaction boundary. The typical use of user
	locks is:

		transaction 1:	select object,user_lock(object);

		... work on object for long time

		transaction 2: update object,user_unlock(object);

    2.	they must not block if the object is already locked, so that the
	program doesn't freeze and the user simply knows it can't use that
	object.

When I wrote the code the only way to do this was to add a separate lock
table and use the same machinery of ordinary locks. I agree that the code
is complex and should probably be rewritten.

If you think there is a better way to implement this feature go ahead,
better code is always welcome.

The only problem I have found with user locks is that if a backend crashes
without releasing a lock there is no way to relase it except restarting
the whole postgres (I don't remember exactly why, I forgot the details).

Regarding the licencing of the code, I always release my code under GPL,
which is the licence I prefer, but my code in the backend is obviously
released under the original postgres licence. Since the module is loaded
dynamically and not linked into the backend I don't see a problem here.
If the licence becomes a problem I can easily change it, but I prefer the
GPL if possible.

-- 
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: see my www home page         |
+----------------------------------------------------------------------+

  3. RE: User locks code

    Lincoln Yeoh <lyeoh@pop.jaring.my> — 2001-08-20T15:52:03Z

    At 11:20 AM 8/19/01 -0700, Vadim Mikheev wrote:
>Well, ability to lock only unlocked rows in select for update is useful,
>of course. But uniq features of user'locks are:
>
>1. They don't interfere with normal locks hold by session/transaction.
>2. Share lock is available.
>3. User can lock *and unlock objects* inside transaction, which is not
>    (and will not be) available with locks held by transactions.

Would your suggested implementation allow locking on an arbitrary string?

If it does then one of the things I'd use it for is to insert unique data
without having to lock the table or rollback on failed insert (unique index
still kept as a guarantee).

Cheerio,
Link.

  4. Re: User locks code

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-23T20:45:09Z

    > Regarding the licencing of the code, I always release my code under GPL,
> which is the licence I prefer, but my code in the backend is obviously
> released under the original postgres licence. Since the module is loaded
> dynamically and not linked into the backend I don't see a problem here.
> If the licence becomes a problem I can easily change it, but I prefer the
> GPL if possible.

We just wanted to make sure the backend changes were not under the GPL.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  5. RE: User locks code

    Mikheev, Vadim <vmikheev@sectorbase.com> — 2001-08-23T23:55:29Z

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

  6. Re: User locks code

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-24T00:11:38Z

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

Yes, kind of tricky.  I am no expert in this but I have had the usual
discussions.

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

Yep.  Is it good?  Well, if you like the GPL, I guess so.  If you don't,
then it isn't good.  

Of course, if you want to try and make money selling your program, it
isn't good whether you like the GPL or not.  :-)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  7. Re: User locks code

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-08-24T00:14:59Z

    I definitely agree with Vadim here: it's fairly silly that the
contrib userlock code is GPL'd, when it consists only of a few dozen
lines of wrapper for the real functionality that's in the main backend.
The only thing this licensing setup can accomplish is to discourage
people from using the userlock code; what's the value of that?

Besides, anyone who actually wanted to use the userlock code would need
only to write their own wrapper functions to get around the GPL license.

			regards, tom lane

  8. Re: User locks code

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-24T00:31:56Z

    > I definitely agree with Vadim here: it's fairly silly that the
> contrib userlock code is GPL'd, when it consists only of a few dozen
> lines of wrapper for the real functionality that's in the main backend.
> The only thing this licensing setup can accomplish is to discourage
> people from using the userlock code; what's the value of that?
> 
> Besides, anyone who actually wanted to use the userlock code would need
> only to write their own wrapper functions to get around the GPL license.

Hey, I agree with Vadim too.  The GPL license is just a roadblock, but I
can't tell Massimo what to do with his code if it is not in the backend
proper.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  9. Re: User locks code

    Hannu Krosing <hannu@tm.ee> — 2001-08-24T02:25:06Z

    Tom Lane wrote:
> 
> I definitely agree with Vadim here: it's fairly silly that the
> contrib userlock code is GPL'd, when it consists only of a few dozen
> lines of wrapper for the real functionality that's in the main backend.

As it seems a generally useful feature, it could at least be LGPL'd so 
that linking to it won't force the whole backend under GPL.

> The only thing this licensing setup can accomplish is to discourage
> people from using the userlock code; what's the value of that?

Maybe it makes Massimo feel good ? It seems a worhty reason to me, as 
he has contributed a lot of useful stuff over the time.

I really think that mixing licences inside one program is bad, if not
for 
any other reason then for confusing people and making them have
discussions 
like this.

> Besides, anyone who actually wanted to use the userlock code would need
> only to write their own wrapper functions to get around the GPL license.

This is a part of copyright law that eludes me - can i write a
replacement
function for something so simple that it can essentially be done in one 
way only (like incrementing a value by one) ?

-----------------
Hannu

  10. Re: User locks code

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-24T14:42:48Z

    > Tom Lane wrote:
> > 
> > I definitely agree with Vadim here: it's fairly silly that the
> > contrib userlock code is GPL'd, when it consists only of a few dozen
> > lines of wrapper for the real functionality that's in the main backend.
> 

I was incorrect in something I said to Vadim.  I said stored procedures
would have to be released if linked against a GPL'ed backend.  They have
to be released only if they are in C or another object file linked into
the backend.  PlpgSQL or SQL functions don't have to be released because
their code is "loaded" into the backend as a script, not existing in the
backend binary or required for the backend to run.

> Maybe it makes Massimo feel good ? It seems a worhty reason to me, as 
> he has contributed a lot of useful stuff over the time.

Yes, that is probably it.  The GPL doesn't give anything to users, it
takes some control away from users and gives it to the author of the
code.

> I really think that mixing licences inside one program is bad, if not
> for 
> any other reason then for confusing people and making them have
> discussions 
> like this.

Yes, the weird part is that the BSD license is so lax (don't sue us)
that it is the addition of the GPL that changes the affect of the
license.  If you added a BSD license to a GPL'ed piece of code, the
effect would be near zero.

> > Besides, anyone who actually wanted to use the userlock code would need
> > only to write their own wrapper functions to get around the GPL license.
> 
> This is a part of copyright law that eludes me - can i write a
> replacement
> function for something so simple that it can essentially be done in one 
> way only (like incrementing a value by one) ?

Sure, if you don't cut and paste the code line by line, or retype the
code while staring at the previous version.  That is how Berkeley got
unix-free version of the BSD operating system.  However, the few places
where they lazily copied got them in trouble.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  11. Re: User locks code

    Hannu Krosing <hannu@tm.ee> — 2001-08-24T15:33:43Z

    Bruce Momjian wrote:
> 
> >
> > This is a part of copyright law that eludes me - can i write a
> > replacement
> > function for something so simple that it can essentially be done in one
> > way only (like incrementing a value by one) ?
> 
> Sure, if you don't cut and paste the code line by line, or retype the
> code while staring at the previous version.  That is how Berkeley got
> unix-free version of the BSD operating system.  However, the few places
> where they lazily copied got them in trouble.
>

I can imagine that when writing a trivial code for performing a trivial
and 
well-known function it is quite possible to arrive at a result that is 
virtually indistinguishable from the original.

I know that Compaq was forced to do a clean-room re-engineering of PC
BIOS 
(two teams - the dirti one with access to real bios athat does
description 
and testin and the clean team to write the actual code so that they can 
prove they did not "steal" even if the result is byte-by-byte simila)
for 
similar reasons

I guess we dont have enough provably clean developers to do it ;)

BTW, teher seems to be some problem with mailing list - I get very few 
messages from the list that are not CC:d to me too

------------------
Hannu

  12. Re: User locks code

    Trond Eivind Glomsrød <teg@redhat.com> — 2001-08-24T16:02:54Z

    Bruce Momjian <pgman@candle.pha.pa.us> writes:

> > Tom Lane wrote:
> > > 
> > > I definitely agree with Vadim here: it's fairly silly that the
> > > contrib userlock code is GPL'd, when it consists only of a few dozen
> > > lines of wrapper for the real functionality that's in the main backend.
> > 
> 
> I was incorrect in something I said to Vadim.  I said stored procedures
> would have to be released if linked against a GPL'ed backend. 

Only to those you actually distribute this product to. If you're using
it internally, you have no obligations to release it to anyone, to
give one example.

-- 
Trond Eivind Glomsrød
Red Hat, Inc.

  13. Re: User locks code

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-24T16:03:34Z

    > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 
> > > Tom Lane wrote:
> > > > 
> > > > I definitely agree with Vadim here: it's fairly silly that the
> > > > contrib userlock code is GPL'd, when it consists only of a few dozen
> > > > lines of wrapper for the real functionality that's in the main backend.
> > > 
> > 
> > I was incorrect in something I said to Vadim.  I said stored procedures
> > would have to be released if linked against a GPL'ed backend. 
> 
> Only to those you actually distribute this product to. If you're using
> it internally, you have no obligations to release it to anyone, to
> give one example.

Yes, I was speaking only of selling the software.  Good point.
 
-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  14. Re: User locks code

    Ross J. Reedstrom <reedstrm@rice.edu> — 2001-08-24T16:06:56Z

    Uh, guys? The last thing I can find that Massimo says about the license
is this, from Sunday:

On Sun, Aug 19, 2001 at 11:15:54PM +0200, Massimo Dal Zotto wrote:
> 
> Regarding the licencing of the code, I always release my code under GPL,
> which is the licence I prefer, but my code in the backend is obviously
> released under the original postgres licence. Since the module is loaded
> dynamically and not linked into the backend I don't see a problem here.
> If the licence becomes a problem I can easily change it, but I prefer the
> GPL if possible.
> 

So, rather than going over everone's IANAL opinons about mixing
licenses, let's just let Massimo know that it'd just be a lot easier to
PostgreSQL/BSD license the whole thing, if he doesn't mind too much.

Ross

On Fri, Aug 24, 2001 at 10:42:48AM -0400, Bruce Momjian wrote:
<I'm not sure who wrote this, Bruce trimmed the attribution>
> > Maybe it makes Massimo feel good ? It seems a worhty reason to me, as 
> > he has contributed a lot of useful stuff over the time.
> 
> Yes, that is probably it.  The GPL doesn't give anything to users, it
> takes some control away from users and gives it to the author of the
> code.
>

  15. [OT] Re: User locks code

    Serguei Mokhov <sa_mokho@alcor.concordia.ca> — 2001-08-24T16:07:04Z

    ----- Original Message ----- 
From: Bruce Momjian <pgman@candle.pha.pa.us>
Sent: Friday, August 24, 2001 10:42 AM


> > I really think that mixing licences inside one program is bad, if not
> > for 
> > any other reason then for confusing people and making them have
> > discussions 
> > like this.
> 
> Yes, the weird part is that the BSD license is so lax (don't sue us)
> that it is the addition of the GPL that changes the affect of the
> license.  If you added a BSD license to a GPL'ed piece of code, the
> effect would be near zero.

Sorry for asking this off-topic question, but I'm not sure I completely
understand this license issue... How GPL, LGPL, and BSD are conflicting
and or overlap, so that it causes such problems? AFAIK with the GPL
one has to ship the source code along with the product every time, but
under BSD it can be shipped without the source (that's why M$ doesn't attack
BSD as it does for GPL), and why the PostgreSQL project originally is being
released under the BSD-like license? Just curious...

Serguei

  16. [OT] Re: User locks code

    Serguei Mokhov <sa_mokho@alcor.concordia.ca> — 2001-08-24T16:07:04Z

    ----- Original Message ----- 
From: Bruce Momjian <pgman@candle.pha.pa.us>
Sent: Friday, August 24, 2001 10:42 AM


> > I really think that mixing licences inside one program is bad, if not
> > for 
> > any other reason then for confusing people and making them have
> > discussions 
> > like this.
> 
> Yes, the weird part is that the BSD license is so lax (don't sue us)
> that it is the addition of the GPL that changes the affect of the
> license.  If you added a BSD license to a GPL'ed piece of code, the
> effect would be near zero.

Sorry for asking this off-topic question, but I'm not sure I completely
understand this license issue... How GPL, LGPL, and BSD are conflicting
and or overlap, so that it causes such problems? AFAIK with the GPL
one has to ship the source code along with the product every time, but
under BSD it can be shipped without the source (that's why M$ doesn't attack
BSD as it does for GPL), and why the PostgreSQL project originally is being
released under the BSD-like license? Just curious...

Serguei

  17. Re: [OT] Re: User locks code

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-24T16:16:18Z

    > > Yes, the weird part is that the BSD license is so lax (don't sue us)
> > that it is the addition of the GPL that changes the affect of the
> > license.  If you added a BSD license to a GPL'ed piece of code, the
> > effect would be near zero.
> 
> Sorry for asking this off-topic question, but I'm not sure I completely
> understand this license issue... How GPL, LGPL, and BSD are conflicting
> and or overlap, so that it causes such problems? AFAIK with the GPL
> one has to ship the source code along with the product every time, but
> under BSD it can be shipped without the source (that's why M$ doesn't attack
> BSD as it does for GPL), and why the PostgreSQL project originally is being
> released under the BSD-like license? Just curious...

Because the code we got from Berkeley was BSD licensed, we can't change
it, and because many of us like the BSD license better because we don't
want to require them to release the source code, we just want them to
use PostgreSQL.  And we think they will release the source code
eventually anyway.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  18. Re: User locks code

    Massimo Dal Zotto <dz@cs.unitn.it> — 2001-08-24T19:33:53Z

    > > Tom Lane wrote:
> > > 
> > > I definitely agree with Vadim here: it's fairly silly that the
> > > contrib userlock code is GPL'd, when it consists only of a few dozen
> > > lines of wrapper for the real functionality that's in the main backend.
> > 
> 
> I was incorrect in something I said to Vadim.  I said stored procedures
> would have to be released if linked against a GPL'ed backend.  They have
> to be released only if they are in C or another object file linked into
> the backend.  PlpgSQL or SQL functions don't have to be released because
> their code is "loaded" into the backend as a script, not existing in the
> backend binary or required for the backend to run.
> 
> > Maybe it makes Massimo feel good ? It seems a worhty reason to me, as 
> > he has contributed a lot of useful stuff over the time.
> 
> Yes, that is probably it.  The GPL doesn't give anything to users, it
> takes some control away from users and gives it to the author of the
> code.

I have to disagree here. GPL gives users the assurance that code can't be
modified and distributed under a more restrictive licence, for example with
no source code available or restrictions on commercial use.

On the contrary BSD doesn't guarantee almost anything on this sense.
Think about what happened with the original Kerberos and the microsoft
version which was deliberately modified to prevent compatibilty with
non microsoft implementations. This has been possible only because it
was released under BSD licence. This why I prefer GPL over BSD.

I choosed to release my code under GPL because I'm more concerned with
freedom of software than with commercial issues of it.

Anyway, please stop this thread. I will change the licence of my contrib
code and make it compatible with postgres licence.

After all, as someone poited out, it is a very trivial code and I don't
really care about what people is doing with it.

> > I really think that mixing licences inside one program is bad, if not
> > for 
> > any other reason then for confusing people and making them have
> > discussions 
> > like this.
> 
> Yes, the weird part is that the BSD license is so lax (don't sue us)
> that it is the addition of the GPL that changes the affect of the
> license.  If you added a BSD license to a GPL'ed piece of code, the
> effect would be near zero.
> 
> > > Besides, anyone who actually wanted to use the userlock code would need
> > > only to write their own wrapper functions to get around the GPL license.
> > 
> > This is a part of copyright law that eludes me - can i write a
> > replacement
> > function for something so simple that it can essentially be done in one 
> > way only (like incrementing a value by one) ?
> 
> Sure, if you don't cut and paste the code line by line, or retype the
> code while staring at the previous version.  That is how Berkeley got
> unix-free version of the BSD operating system.  However, the few places
> where they lazily copied got them in trouble.
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html
> 

-- 
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: see my www home page         |
+----------------------------------------------------------------------+

  19. Re: User locks code

    Ian Lance Taylor <ian@airs.com> — 2001-08-24T21:38:53Z

    Hannu Krosing <hannu@tm.ee> writes:

> I know that Compaq was forced to do a clean-room re-engineering of PC
> BIOS 
> (two teams - the dirti one with access to real bios athat does
> description 
> and testin and the clean team to write the actual code so that they can 
> prove they did not "steal" even if the result is byte-by-byte simila)
> for 
> similar reasons

Compaq wasn't forced to do this.  They did it on the basis that
following this complex procedure would guarantee that they would win
if it came to a court case (which it did not).  But there is no way to
tell whether a simpler procedure would not win in court.

The GPL is a copyright license.  Copyrights, unlike patents, only put
limitations on derived works.  If you independently write the same
novel, and you can prove in court that you never saw the original
novel, you are not guily of violating copyright.  That's why Compaq
followed the procedure they did (and it's why Pierre Menard was not
guilty of copyright infringement).

But that's novels.  As far as I know, there is no U.S. law, and there
are no U.S. court decisions, determining when one program is a
derivative of another.  If you read a novel, and write a novel with
similar themes or characters, you've infringed.  However, there is
less protection for functional specifications, in which there may be
only one way to do something.  When does a computer program infringe?
Nobody knows.

Ian

  20. Re: [OT] Re: User locks code

    Hannu Krosing <hannu@tm.ee> — 2001-08-31T10:15:47Z

    Serguei Mokhov wrote:
> 
> and why the PostgreSQL project originally is being
> released under the BSD-like license? Just curious...

Berkeley usually releases their free projects under BSD licence ;)

There have been some discussion about changing it, but it has never got 
enough support.

--------------
Hannu