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.
--
> > 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
> 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.
>
> 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.
Yes, it would be better.
Vadim
---(end of broadcast)--
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 backen
Bruce Momjian wrote:
...
>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.
Correction - it takes away from the *distributor* of binaries the right to
give users fewer rights than he has. If he
> 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
> Bruce Momjian <[EMAIL PROTECTED]> 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 b
> > 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
- Original Message -
From: Bruce Momjian <[EMAIL PROTECTED]>
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.
>
>
- Original Message -
From: Bruce Momjian <[EMAIL PROTECTED]>
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.
>
>
Bruce Momjian <[EMAIL PROTECTED]> 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.
> >
>
> > 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
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,
> 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 s
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
> 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 usin
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 user
> > 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
> > 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. Jus
> > No, you were clear.
>
> So I missed your "near-zero cost" sentence.
OK.
> > 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
> 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 i
> > > 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
> > > For example, one could use user-locks for processing incoming
> > > orders by multiple operators:
> > > select * from orders where user_lock(orders.oid) = 1 LIMIT 1
> > > - so each operator would lock one order for processing and
> > > operators wouldn't block each other. So, could such
> >
> > For example, one could use user-locks for processing incoming
> > orders by multiple operators:
> > select * from orders where user_lock(orders.oid) = 1 LIMIT 1
> > - so each operator would lock one order for processing and
> > operators wouldn't block each other. So, could such
> > applicatio
> > > 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.
>
> No, Bruce - backend part of code is useless without interface
> functions and I wonder doesn't GPL-ed int
> > 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.
No, Bruce - backend part of code is useless without interface
functions and I wonder doesn't GPL-ed interface implement
> 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.
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 th
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
(a
30 matches
Mail list logo
