Re: [GENERAL] lztext and compression ratios...
Tom Lane wrote: > [EMAIL PROTECTED] (Jan Wieck) writes: > > One thing to keep in mind is that the LZ algorithm you're > > thinking of must be distributable under the terms of the BSD > > license. If it's copyrighted or patented by any third party, > > not agreeing to these terms, it's out of discussion and will > > never appear in the Postgres source tree. Especially the LZ > > algorithm used in GIF is one of these show-stoppers. > > As long as you brought it up: how sure are you that the method you've > used is not subject to any patents? The mere fact that you learned > it from someone who didn't patent it does not guarantee anything --- > someone else could have invented it independently and filed for a > patent. Now that you ask for it: I'm not sure. Could be. > If you can show that this method uses no ideas not found in zlib, > then I'll feel reassured --- a good deal of legal research went into > zlib to make sure it didn't fall foul of any patents, and zlib has > now been around long enough that it'd be tough for anyone to get a > new patent on one of its techniques. But if SLZ has any additional > ideas in it, then we could be in trouble. There are an awful lot of > compression patents. To do so I don't know enough about the algorithms used in zlib. Is there someone out here who could verify that if I detailed enough describe what our compression code does? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] #
RE: [GENERAL] responses to licensing discussion
>not being from maryland but, i would think that the constitution's >prohibition against ex post facto laws would prevent retro-active >applications of laws, if the usa actually followed the constitution; >but that's another topic... Ex post facto seems pretty one way. If you drop a cigg butt on the ground today, and tomorrow your town votes to make it illegal to throw cigg butts on the ground, you aren't held liable unless you do it again, AFTER the law was passed. I'm curious tho - if you sue Oracle today, and UCITA is passed tomorrow, does UCITA wipe out your suit? Rob Nelson [EMAIL PROTECTED]
[GENERAL] Vacuum and 24 hour availability
I'm using PostgreSQL for an online game (www.merchantempires.net). Running Vacuum analyze locks down the database. Unfortunately, its a little disconcerting to my players when this occurs. I've got people playing 24 hours a day. My question is how can PostgreSQL ever be used for a database that needs to be available 24/7, if running a vacumm locks it down? I like PostgreSQL but if there is no way around this rather significant feature (bug?) then I will have to switch to something else. Please forward replies to: [EMAIL PROTECTED] Thanks
[GENERAL] psotgresql history function
Hi, I compiled and installed PostgreSQL v7.0.2 on a Linux box where the history function in psql (cursor up/down) worked without any problems. After that I recompiled the package on a Digital Unix 4.0d machine. But there it is not working! Is there something I have to configure? I tried to use several terminal emulations (vt100, xterm) which did not work out. Any suggestions?? TIA, Peter
[GENERAL] change in now() and ago with 7.x
Pre-7.x, we used to use a line like: " request.date_submitted > (now() + '24 hours ago')" to pull data created in the past day (used against a timestamp). Something changed with 7.x that blows that line out. I am looking for a work around for use with 7.x. Currently I'm using "select now()::DATETIME - '24 hours'::TIMESPAN" and using the return as a variable to test against -- too much code. I'd rather just fix the one line rather than hack all the existing scripts. So what suggestions do you have and could you point me to what changed between 6.x and 7.x that broke my scripts (I've got to tell the boss something :-) ) Thanks! Dave Stokes
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this morepalatable?
Mike Mascari wrote: > Why do you continue to insist that GPL is superior to BSD? GPL is > BSD *with restrictions*. If someone comes along and sweeps up the > major developers: > > A) Good for the major developers - they deserve to have large > sums of cash thrown their way, particularly for many of them who > have been working on this *for years* > My understanding is that BSD allows someone to take the code commercial without consulting the original developers at all. With GPL, a company would have to negotiate an alternative license with the copyright holders in order to use the code for a closed source commercial product. This would ensure that the copyright holders receive some compensation. (Multiple licensing is a common strategy; e.g., ReiserFS if offered under GPL and commercial licensing. It is also possible to let users choose one of several licenses, so you can release your code under BSD and GPL and let users decide which they prefer, although this could create additional problems with integrating contributed code.) With BSD you are basically saying that anyone can use the code anyway they want, even if they take it and sell it as part of a commercial closed source product. I'm also happy if major postgres developers get sums of cash thrown their way, but why does BSD make that more likely? Also, I will point out that the GPL allows anyone to make closed source modifications to code as long as they do not redistribute the modifications. Its perfectly fine to modify the code and use the modified version within an organization. Placing modifications under the GPL only applies when these modifications are distributed to others. I believe some of the GPL 'poison' comments incorrectly implied that the GPL restricts organizations from making closed source modifications for internal use. T. -- Timothy H. Keitt National Center for Ecological Analysis and Synthesis 735 State Street, Suite 300, Santa Barbara, CA 93101 Phone: 805-892-2519, FAX: 805-892-2510 http://www.nceas.ucsb.edu/~keitt/
[GENERAL] pl/pgsql function out parameters
Hi there, Does anyone know if out parameters are supported in pl/pgsql functions? What I mean is something like this: create function f(out int4) returns text as ' select $1 = 3 return "" ' language 'plpgsql'; db ==> declare i int4; db ==> select f(i); db ==> select i; i == 3 I have scanned most of the plsql documentation I can lay hands on without much joy - mailing list archives - User guide that is shipped with the postgres 7.02 - Programmer's guide shipped with release 7.02 - I notice that in the jdbc CallableStatement implementation, registerOutpurParameter merely throws a notImplemented exception - Is this a hint? - Bruce Momjian's book - There is a chapter on functions and triggers, but I cannot seem to find this mentioned anywhere. If this is not doable, could someone please confirm that so I should stop looking. On the other hand, if anyone out there has an idea how to accomplish this, please, please help. Kind regards, Richard.
Re: [GENERAL] PostgreSQL & the BSD License
On Thu, 6 Jul 2000, Tom Lane wrote: > The Hermit Hacker <[EMAIL PROTECTED]> writes: > > I would like to plug this in early next week, unless someone can see > > something major that makes them feel uncomfortable ... > > What are you trying to do Marc, foreclose a full discussion? I think > this is *way* premature. No ... what I posted as a replacement for our current COPYRIGHT is the *base* that nobody disagrees with ... I don't care if everyone wants to argue til their are blue in the face for the next 6 months concerning the two paras that were drop'd, we can always add them in later, its just removing stuff that is a pita ... ... hell, I'll create a pgsql-license mailing list if ppl want, just to discuss those two paras and centralize the discussions ... >From the feeling I got from those that have posted to the lists, what is in the one I posted last night is agreeable to *everyone*, both American and non-American, since it doesn't change the gist of the BSD license, it only extends the umbrella of warranty/liability over all of us ...
RE: [GENERAL] Find all the dates in the calendar week?
On Thu, 6 Jul 2000, Andrew Snow wrote:
> > See the documentation at:
> > http://www.comptechnews.com/~reaster/postgres/functions2976.htm
>
>
> So, something like:
>
> SELECT event FROM events WHERE to_char(CURRENT_TIMESTAMP, 'ww') =
> to_char(eventdate, 'ww');
A small note about 'WW' in to_char/timestamp(), in 7.0 is a small bug
in this code (already discussed) and it is based on standard weeks, but in
7.1 it will *different* and based on weeks like Oracle (already in CVS).
Oracle: first week start JAN-1 and all next weeks start in same day. For
example if first day of year is friday, all weeks start in friday.
ISO-week: week that has more than 4 day and start in Sunday.
In future I try implement 'IW' that is ISO-week, but now I work on different
things.
In current 7.0 is probably better for week operations use
date_part('week', TIMESTAMP) than to_char().
Karel
Re: [GENERAL] change in now() and ago with 7.x
> Pre-7.x, we used to use a line like: " request.date_submitted > (now() > + '24 hours ago')" > to pull data created in the past day (used against a timestamp). > Something changed with 7.x that blows that line out. You will have to be more specific on what is not working for you. afaict that line should still work: lockhart=# select * from t1 where d < now() + '24 hours ago'; i |d ---+- 1 | Mon Jul 03 00:00:60.00 2000 PDT ... (though my personal preference is for something like (timestamp 'now' - interval '24 hours') ). One thing that changed for 7.0 is that "timestamp" is the primary date/time type. Make sure that you do everything using that type, rather than using "datetime"; the latter is sort-of supported by the parser to help with upgrades, but that support is not complete.
[GENERAL] Re: [HACKERS] pl/pgsql function out parameters
> Does anyone know if out parameters are supported in pl/pgsql functions? Yes. They are not supported. I've got patches ready to submit which recognize the IN, OUT and INOUT keywords defined in SQL99, but the patches will just throw an explicit error if you specify an OUT/INOUT parameter. btw, everyone: any objections to or comments on the above? - Thomas
Re: [GENERAL] Find all the dates in the calendar week?
> ISO-week: week that has more than 4 day and start in Sunday.
> In future I try implement 'IW' that is ISO-week, but now I work on different
> things.
> In current 7.0 is probably better for week operations use
> date_part('week', TIMESTAMP) than to_char().
Note that the above returns ISO-week, not some Sun-Sat thing ('dow' ==
"day of week" does that). I haven't yet implemented ISO-year (Karel?)
which would seem to be an essential piece to use ISO-week effectively.
- Thomas
Re: [GENERAL] Partial indices
Mike Mascari <[EMAIL PROTECTED]> writes: >> Are Partial Indices still supported into latest release of PostgreSQL? > I think they have suffered some serious bit-rot over the years > and are no longer functional, although some of the core code > still exists in the backend. Actually, quite a LOT of partial-index support code still exists in the backend. Someone removed support for the "WHERE predicate" clause of CREATE INDEX from the grammar, but I don't know when or why that was done. AFAICT everything is still there to support the feature downstream, and it doesn't look particularly bit-rotted. Someday when we don't have any more-pressing problems, I'd like to try to re-enable that support. At the very least I might learn why it was disabled ;-) (Hey Bruce, do we have a TODO item for "Fix partial indices"?) regards, tom lane
Re: [GENERAL] PostgreSQL & the BSD License
>On Thu, 6 Jul 2000, Tom Lane wrote: > > > The Hermit Hacker <[EMAIL PROTECTED]> writes: > > > I would like to plug this in early next week, unless someone can > > > see something major that makes them feel uncomfortable ... > > > > What are you trying to do Marc, foreclose a full discussion? I > > think this is *way* premature. > > > >From the feeling I got from those that have posted to the lists, what >is in the one I posted last night is agreeable to *everyone*, both >American and non-American, since it doesn't change the gist of the BSD >license, it only extends the umbrella of warranty/liability over all >of us ... > IMO, it is difficult to say that this is a "BSD license" unless there is a general agreement by those who use the (current) BSD license to adopt it as *the* BSD license. I fear that unilaterally changing the license, even if that change is deemed necessary and correct, may cause unnecessary confusion, and tends toward a competitive rather than cooperative atmosphere for standard setting. If the BSD license is flawed, then most projects using it should logically want to change it along with everyone else. But without consulting with/working with other major BSD license users, it is possible that postgesql will face a situation where it will have to consider changing it's "PostgreSQL license" to a new "BSD" license because the other BSD-license users have established a standard license that adds to or modifies the "Postgres license". This comment is in line with several others that have voiced concern about "yet another license". It simply seems more productive to proactively build a consensus for a new standard by including other BSD license users in discussions sooner rather than later. Unless, of course, the license is so flawed that a new license needs to be implemented immediately, without a such a larger and inclusive discussion. Yet, the license has been flawed for years - and other BSD-license users are in the same boat - wouldn't it be in their best interest to adopt an interim license also? John Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: [GENERAL] PostgreSQL & the BSD License
I'm confused here as to why pppl keep going to the "BSD license is
flawed" argument? The only "flaw" that I can see is that a) the copyright
ended '96 and b) it only covers "UNIVERSITY OF CALIFORNIA" ... all that is
being proposed *at this time* is to add in coverage for the period *since*
'96 and extend that coverage to include *all* developers, not just the
Univesrity of California ...
Now, a) is easily fixable by just extending the date to 2000, but that
still only covers "UNIVERSITY OF CALIFORNIA", and none of the actual
developers ...
If ppl feel that neither a) or b) above aren't considered flaws, then let
us leave well enough alone ...
The wording in the 'DEVELOPERS' section of what I sent out last night is a
little more verbose, so we could cut it down to be exactly the same as the
BSD one, and 'trim the fat' ... so that all we are "changing" is
"UNIVERSITY OF CALIFORNIA" to "DEVELOPERS", and leaving the rest of the
wording completely intact ... ?
My personal feeling is that if the BSD license itself was so flawed, there
are at least another dozen projects out there that deal with commercial
enterprises on a larger scale then we do that would have done changes also
... I don't want to change the wording, I would just like to see it
extended to cover the ppl that are actually doing development and not just
UNIVERSITY OF CALIFORNIA ...
make sense? or are we just sitting here discussing changes to a license
that doesn't need changing?
On Thu, 6 Jul 2000, John Daniels wrote:
> >On Thu, 6 Jul 2000, Tom Lane wrote:
> >
> > > The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > > > I would like to plug this in early next week, unless someone can
> > > > see something major that makes them feel uncomfortable ...
> > >
> > > What are you trying to do Marc, foreclose a full discussion? I
> > > think this is *way* premature.
> >
> >
> >
> >From the feeling I got from those that have posted to the lists, what
> >is in the one I posted last night is agreeable to *everyone*, both
> >American and non-American, since it doesn't change the gist of the BSD
> >license, it only extends the umbrella of warranty/liability over all
> >of us ...
> >
>
> IMO, it is difficult to say that this is a "BSD license" unless there is a
> general agreement by those who use the (current) BSD license to adopt it as
> *the* BSD license. I fear that unilaterally changing the license, even if
> that change is deemed necessary and correct, may cause unnecessary
> confusion, and tends toward a competitive rather than cooperative atmosphere
> for standard setting.
>
> If the BSD license is flawed, then most projects using it should logically
> want to change it along with everyone else. But without consulting
> with/working with other major BSD license users, it is possible that
> postgesql will face a situation where it will have to consider changing it's
> "PostgreSQL license" to a new "BSD" license because the other BSD-license
> users have established a standard license that adds to or modifies the
> "Postgres license".
>
> This comment is in line with several others that have voiced concern about
> "yet another license". It simply seems more productive to proactively build
> a consensus for a new standard by including other BSD license users in
> discussions sooner rather than later.
>
> Unless, of course, the license is so flawed that a new license needs to be
> implemented immediately, without a such a larger and inclusive discussion.
> Yet, the license has been flawed for years - and other BSD-license users are
> in the same boat - wouldn't it be in their best interest to adopt an interim
> license also?
>
> John
>
>
>
>
>
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
Re: [GENERAL] PostgreSQL & the BSD License
>Recently, Landmark/Great Bridge sent us a proposed revision to our >existing license that, from what I can tell, has two paragraphs that >pretty instantly none of the non-US developers felt comfortable with ... >and that I, personally, could never agree to. Sorry to jump in , but which two paragraphs were these and why were they objectionable ?
Re: [GENERAL] PostgreSQL & the BSD License
The Hermit Hacker <[EMAIL PROTECTED]> writes: > On Thu, 6 Jul 2000, Tom Lane wrote: >> The Hermit Hacker <[EMAIL PROTECTED]> writes: I would like to plug this in early next week, unless someone can see something major that makes them feel uncomfortable ... >> >> What are you trying to do Marc, foreclose a full discussion? I think >> this is *way* premature. > No ... what I posted as a replacement for our current COPYRIGHT is the > *base* that nobody disagrees with ... I don't care if everyone wants to > argue til their are blue in the face for the next 6 months concerning the > two paras that were drop'd, we can always add them in later, its just > removing stuff that is a pita ... It sounded a lot like you were trying to say "this is what we're going to do, end of discussion". I take it that wasn't what you meant, but it sure read that way from here ... regards, tom lane
Re: [GENERAL] Find all the dates in the calendar week?
> yes, my current to_char() is almost compatible with oracle, but I need > last two features --- IYYY (ISO-year) and IW (ISO-week). But I not explore > it exactly yet. I mean that current (PG's) week-of-year is like ISO or not? Yes. 'week' is "ISO week" (new for 7.0 afaicr). And it wasn't *entirely* trivial to implement, so you may want to steal code for to_char() ;) I just didn't implement the corresponding "year" code at least partly because I wasn't sure what to call it. 'iyear' seems like a pretty good choice, or should it be 'isoyear'? 'year' is already used, obviously, and if 'iyear' is chosen then perhaps I should change 'week' to 'iweek' for consistancy. Comments? - Thomas
Re: [GENERAL] Find all the dates in the calendar week?
On Thu, 6 Jul 2000, Thomas Lockhart wrote:
> > ISO-week: week that has more than 4 day and start in Sunday.
> > In future I try implement 'IW' that is ISO-week, but now I work on different
> > things.
> > In current 7.0 is probably better for week operations use
> > date_part('week', TIMESTAMP) than to_char().
>
> Note that the above returns ISO-week, not some Sun-Sat thing ('dow' ==
> "day of week" does that). I haven't yet implemented ISO-year (Karel?)
> which would seem to be an essential piece to use ISO-week effectively.
>
yes, my current to_char() is almost compatible with oracle, but I need
last two features --- IYYY (ISO-year) and IW (ISO-week). But I not explore
it exactly yet. I mean that current (PG's) week-of-year is like ISO or not?
But freely, I not pursue after date/time operations and calculations, it is
"alchemy" (I admire you Thomas)... I must between work on to_char() insert
work on some other things :-)
Karel
[GENERAL] Scrappy as Peacemaker...Thanks! (fwd)
I had sent this on to Marc as I did not want to fan the flames anymore
but on second thought - ah what the heck. Here goes. I'll take my
lumps! The cause seems just...
-- Forwarded message --
Date: Thu, 6 Jul 2000 08:41:23 -0400 (EDT)
From: Thomas Good <[EMAIL PROTECTED]>
To: The Hermit Hacker <[EMAIL PROTECTED]>
Subject: Scrappy as Peacemaker...Thanks!
On Thu, 6 Jul 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > I would like to plug this in early next week, unless someone can see
> > something major that makes them feel uncomfortable ...
>
> What are you trying to do Marc, foreclose a full discussion? I think
> this is *way* premature.
>
> regards, tom lane
Marc,
Thanks for trying to remain practical and sensible here. It seems
to this weary observer (who added his $.02 US twice too often) that
your compromise simply reflects the only feasible course of action.
One, I expect, Pg will adopt eventually anyway...
Personally, I'd like to get back to the *real* debate:
proving that the FreeBSD mascot is actually an agent of Satan.
Good luck with your peacemaking efforts!
Tom Good
SVCMC - Center for Behavioral Health
Thomas Good tomg@ { admin | q8 } .nrnet.org
IS Coordinator / DBA Phone: 718-354-5528
Fax: 718-354-5056
Powered by: PostgreSQL s l a c k w a r e FreeBSD:
RDBMS |-- linux The Power To Serve
Re: [GENERAL] proposed improvements to PostgreSQL license
Chris Bitmead wrote: > > > I would submit that most businesses don't know the difference. Perhaps > > they need some education. > > Are you volunteering? Of course. As the systems administrator for my company, I feel it's my responsibility to inform the principals who run this company about software licensing issues that may affect them. I would hope that anyone with similar duties at any other company would feel the same way. I would like to future proof any technology investments we make to the greatest degree possible. If I say "let's build our project management database using xyz", I would like to assure anyone buying into this proposal that I have some confidence in the future direction xyz will take. The current licensing debate surrounding PostgreSQL has greatly diminished my confidence in it's long term viability as an open source project. I may be very wrong here, but I really don't feel like taking unnecessary chances. The best argument so far as to how a BSD style license will maintain PostgreSQL's viability as an open source project is that if someone take the code proprietary, someone else can fork the code and continue development as an open source project. This has happened in PostgreSQL's own history. How long did it take for the project to get picked up again? How long did it take for the people who picked it up to familiarize themselves with the code? How long did it take before the community at large developed any confidence in the project's viability? How much talent was lost? How many ideas were lost? I believe developers assurances about their desire to maintain PostgreSQL as an open source project are sincere. But I am not going to continue investing my time in PostgreSQL unless those assurances are backed by contractually binding verbage. Ron Peterson [EMAIL PROTECTED]
[GENERAL] Humongous BUG in PostgreSQL/libpq?
If I declare a cursor in embedded SQL I get a strange error wich
doesn't occur if I declare it manually with psql!
the code is:
void setSQL(PGconn *conn){
PQexec(conn,"SET DATESTYLE=European;");
PQexec(conn,"BEGIN TRANSACTION;");
PQexec(conn,"SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;");
PQexec(conn,"DECLARE peop_cursor CURSOR FOR SELECT * FROM people;");
/*at this point while executing this last instruction pgsql give me:
"NOTICE: current transaction is aborted, queries are ignored until
the end of transaction"
but the error doesn't occur processing those instructions in psql
*/
}
what I have to do
HELP!
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this more palatable?
On Wed, Jul 05, 2000 at 11:13:45PM -0300, The Hermit Hacker wrote: > On Wed, 5 Jul 2000, Jim Wise wrote: > > > I'd like to point out a couple things that are _not_ wrong with the > > current license: > > > > 1.) With the current license, contributors to the code are not opened > > to legal liability for the code they contribute. The BSD license > > very clearly disclaims all warranty on the part of not only UCB but > > also all contributors > > Actually, this is the only thing that I do feel the current license is > missing ... unless I'm reading something wrong, it all focuses on > disclaming "UNIVERSITY OF CALIFORNIA"s liability ... that one is very > specific ... Since no-one else has mentioned this yet, I will: the Postgres license, i.e., the file COPYRIGHT at the top level of the distribution, isn't exactly identical to what's commonly known as "the BSD license". The Postgres copyright, the BSD 4.4 copyright (http://www.freebsd.org/copyright/license.html), and the FreeBSD copyright (http://www.freebsd.org/copyright/freebsd-license.html), are all differently worded in parts, although clearly the same in intent. The latter is almost identical to the BSD license template at http://www.opensource.org/licenses/bsd-license.html . All of them except ours say something like "REGENTS AND CONTRIBUTORS" when they're disclaiming warranties; we just have the University of California doing so. The simplest way to change our license if we want to make sure that it explicitly disclaims warranties on behalf of all contributors seems to be to add to the existing California paragraphs a dead standard BSD license with our contributors referred to collectively, which is what Marc has proposed. There may be people who for one reason or another (usually US law, as far as I can see) would like to see more changes, but I can't see what's objectionable about this one. Richard
Re: [GENERAL] proposed improvements to PostgreSQL license
At 10:19 6/07/00 -0400, Ron Peterson wrote: > >This has happened in PostgreSQL's own history. How long did it take for >the project to get picked up again? How long did it take for the people >who picked it up to familiarize themselves with the code? How long did >it take before the community at large developed any confidence in the >project's viability? How much talent was lost? How many ideas were >lost? > >I believe developers assurances about their desire to maintain >PostgreSQL as an open source project are sincere. But I am not going to >continue investing my time in PostgreSQL unless those assurances are >backed by contractually binding verbage. Short of employing the core developers directly, and giving them good enough conditions to ensure that they stay with you, I don't think you can acheieve your ends. No license change will help. All a licence does is tells you what *you* can do with the software. GPL or BSD, if someone buys up the core developers, their replacements will have a steep learning curve. Your only choice here is to invest local talent from your company in the development project so that if the core developers do leave, then there is a higher chance of a quick uptake. Or have I missed something? Did you have some kind of "contractually binding verbage" in mind? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.C.N. 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [GENERAL] PostgreSQL & the BSD License
On Thu, 6 Jul 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > On Thu, 6 Jul 2000, Tom Lane wrote:
> >> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> I would like to plug this in early next week, unless someone can see
> something major that makes them feel uncomfortable ...
> >>
> >> What are you trying to do Marc, foreclose a full discussion? I think
> >> this is *way* premature.
>
> > No ... what I posted as a replacement for our current COPYRIGHT is the
> > *base* that nobody disagrees with ... I don't care if everyone wants to
> > argue til their are blue in the face for the next 6 months concerning the
> > two paras that were drop'd, we can always add them in later, its just
> > removing stuff that is a pita ...
>
> It sounded a lot like you were trying to say "this is what we're going
> to do, end of discussion". I take it that wasn't what you meant, but
> it sure read that way from here ...
The more I think on this, the less I'm sure that we *should* be changing
anything though ... why hasn't FreeBSD (a primarily US based, BSD
licensed, Open Source Project) changed it? Has NetBSD? OpenBSD? Why is
it good enough for them, and all of their commercial clients and
affiliates, but not good enough for us? Actually, just took a look at the
COPYRIGHT that comes with FreeBSD ... shit, wait a second ... didn't the
BSD COPYRIGHT just *have* a change? ... ...
Ya, there was a recent change, that can be seen at:
ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change ... but, if
you look at the FreeBSD COPYRIGHT in /usr/src, I'm guessing that we've
never kept up with *any* of the changes to the BSD COPYRIGHT ... we just
used the one that came with Postgres95 originally and assumed that
Berkeley never changed it ...
===
# $FreeBSD: src/COPYRIGHT,v 1.4 1999/09/05 21:33:47 obrien Exp $
# @(#)COPYRIGHT 8.2 (Berkeley) 3/21/94
All of the documentation and software included in the 4.4BSD and
4.4BSD-Lite
Releases is copyrighted by The Regents of the University of California.
Copyright 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed by the University of
California, Berkeley and its contributors.
4. Neither the name of the University nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
there is more dealing with X and whatnot ... the ftp URL I gave above
removes clause 3 in the above:
=
> more README.Impt.License.Change
July 22, 1999
To All Licensees, Distributors of Any Version of BSD:
As you know, certain of the Berkeley Software Distribution ("BSD") source
code files require that further distributions of products containing all or
portions of the software, acknowledge within their advertising materials
that such products contain software developed by UC Berkeley and its
contributors.
Specifically, the provision reads:
" * 3. All advertising materials mentioning features or use of this software
*must display the following acknowledgement:
*This product includes software developed by the University of
*California, Berkeley and its contributors."
Effective immediately, licensees and distributors are no longer required to
include the acknowledgement within advertising materials. Accordingly, the
foregoing paragraph of those BSD Unix files containing it is hereby deleted
in its entirety.
William Hoskins
Di
Re: [GENERAL] responses to licensing discussion
The Hermit Hacker writes: > Personally, I'd like the whole thing weeded down to ... get rid of the > 'juristiction of ...' (which nobody outside of the US will agree to, from > what I've been seeing on the list) ... and get rid of "Any person who > contributes ..." paragraph, which several ppl have voiced a concern about, > and we might have something that non-US developers can agree to ... > > can someone also explain to me what ", NEED, OR QUALITY, AND ANY IMPLIED > WARRANTY FROM COURSE OF DEALING OR USAGE OF TRADE. IN ADDITION, THERE IS > NO IMPLIED WARRANTY AGAINST INTERFERENCE WITH ENJOYMENT OR AGAINST > INFRINGEMENT." is supposed to mean? what the hell is "INTERFERENCE WITH > ENJOYMENT OR AGAINST INFRINGEMENT"? It means if you don't enjoy it, you can't sue. :-) I don't see any point for not using the same BOLD (or the same text, for that matter) that the UCB used, as has been suggested a hundred times before. We'd make the extra point of "Licenses are so stupid, they make us write this twice." -- Peter Eisentraut Sernanders väg 10:115 [EMAIL PROTECTED] 75262 Uppsala http://yi.org/peter-e/Sweden
Re: [GENERAL] Find all the dates in the calendar week?
On Thu, 6 Jul 2000, Thomas Lockhart wrote: > > yes, my current to_char() is almost compatible with oracle, but I need > > last two features --- IYYY (ISO-year) and IW (ISO-week). But I not explore > > it exactly yet. I mean that current (PG's) week-of-year is like ISO or not? > > Yes. 'week' is "ISO week" (new for 7.0 afaicr). And it wasn't *entirely* > trivial to implement, so you may want to steal code for to_char() ;) My problem is not convert some data to char (in to_char()), but vice versa convert from char to timestamp. For example convert week-of-year number to real date. But yes, I steal you :-) > I just didn't implement the corresponding "year" code at least partly > because I wasn't sure what to call it. 'iyear' seems like a pretty good > choice, or should it be 'isoyear'? 'year' is already used, obviously, > and if 'iyear' is chosen then perhaps I should change 'week' to 'iweek' > for consistancy. Comments? For to_char() it is unambiguous, IW and IYYY. BTW --- I now planning for 7.2 some routine for measure unit conversion. For example 'km' to 'mile' ...etc. It will very good for PG international domination :-) Karel
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this more palatable?
On Thu, 6 Jul 2000, Richard Poole wrote: > On Wed, Jul 05, 2000 at 11:13:45PM -0300, The Hermit Hacker wrote: > > On Wed, 5 Jul 2000, Jim Wise wrote: > > > > > I'd like to point out a couple things that are _not_ wrong with the > > > current license: > > > > > > 1.) With the current license, contributors to the code are not opened > > > to legal liability for the code they contribute. The BSD license > > > very clearly disclaims all warranty on the part of not only UCB but > > > also all contributors > > > > Actually, this is the only thing that I do feel the current license is > > missing ... unless I'm reading something wrong, it all focuses on > > disclaming "UNIVERSITY OF CALIFORNIA"s liability ... that one is very > > specific ... > > Since no-one else has mentioned this yet, I will: the Postgres license, > i.e., the file COPYRIGHT at the top level of the distribution, isn't > exactly identical to what's commonly known as "the BSD license". Ya, I just clued into that ... throughout all the discussions, I never once thought to do a 'cat /usr/src/COPYRIGHT' on my machine :( > The > Postgres copyright, the BSD 4.4 copyright > (http://www.freebsd.org/copyright/license.html), and the FreeBSD copyright > (http://www.freebsd.org/copyright/freebsd-license.html), are all > differently worded in parts, although clearly the same in intent. The > latter is almost identical to the BSD license template at > http://www.opensource.org/licenses/bsd-license.html . All of them Damn, why didn't anyone ever actually look at this stuff before? And ya, I'm just as guilty as the rest ... > The simplest way to change our license if we want to make sure that it > explicitly disclaims warranties on behalf of all contributors seems to > be to add to the existing California paragraphs a dead standard BSD > license with our contributors referred to collectively, which is what > Marc has proposed. Quite frankly, I like the one that OpenSource.Org provides as standard for BSD License ... it encompasses everything as one Para instead of repeating things ... With wu-ftpd, each source file has this included, as well as a line consisting of "Copyright (c) , " for each developer that did work in that file ... My personal opinion is to replace the BSD License of 1996 with the BSD License of today (and keep up with changes to it), as it has been adopt'd by other Open Source Projects ... as is provided on http://www.opensource.org/licenses/bsd-license.html Something nice, simple and industry standard: ==[ README file ]=== PostgreSQL Data Base Management System (formerly known as Postgres95) This directory contains the ___ release of PostgreSQL, as well as various post-release patches in the patches directory. See INSTALL for the installation notes and HISTORY for the changes. We also have a WWW home page located at: http://www.postgreSQL.org =[ COPYRIGHT file ]=== Copyright (c) 1994-1996, Regents of the University of California Copyright (c) 1996-2000, various contributors (as identified in HISTORY) (collectively "Contributors") All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE UNIVERSITY AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ==
Re: [GENERAL] proposed improvements to PostgreSQL license
On Thu, 6 Jul 2000, Ron Peterson wrote: > This has happened in PostgreSQL's own history. How long did it take > for the project to get picked up again? How long did it take for the > people who picked it up to familiarize themselves with the code? How > long did it take before the community at large developed any > confidence in the project's viability? How much talent was lost? > How many ideas were lost? Huh? When? I, and several others, picked up Postgres95 from the University of California at Berkeley, following the graduate studies of Andrew and Jolly, in 1996 ... there has been no copyright change since then (wish someone had mentioned soon that alther we didn't do any copyright changes, Berkeley did *sigh*) ... Prior to that, Postgres95 was a graduate project, that, if I recall correctly, Andrea and Jolly took on to move Postgres from a PostQuel based to an SQL based server, but that part of the history I may be wrong on ... Since '96, there has only been one development effort on PostgreSQL ... that I'm aware of ...
Re: [GENERAL] proposed improvements to PostgreSQL license
Philip Warner wrote: > > At 10:19 6/07/00 -0400, Ron Peterson wrote: > > > >This has happened in PostgreSQL's own history. How long did it take for > >the project to get picked up again? How long did it take for the people > >who picked it up to familiarize themselves with the code? How long did > >it take before the community at large developed any confidence in the > >project's viability? How much talent was lost? How many ideas were > >lost? > > > >I believe developers assurances about their desire to maintain > >PostgreSQL as an open source project are sincere. But I am not going to > >continue investing my time in PostgreSQL unless those assurances are > >backed by contractually binding verbage. > > Short of employing the core developers directly, and giving them good > enough conditions to ensure that they stay with you, I don't think you can > acheieve your ends. No license change will help. All a licence does is > tells you what *you* can do with the software. > > GPL or BSD, if someone buys up the core developers, their replacements will > have a steep learning curve. Your only choice here is to invest local > talent from your company in the development project so that if the core > developers do leave, then there is a higher chance of a quick uptake. > > Or have I missed something? Did you have some kind of "contractually > binding verbage" in mind? Technically, you're right, of course. There are no absolutes here, just probabilities. Developers will come and go in either case. But in these days of multi-billion dollar mergers and acquisisitons, I would prefer team as a whole be working under a license that would discourage them from taking the code private. Losing any of the developers would be a loss. But losing a significant fraction of them could be tragic. By the way, I hope I'm not coming across as saying "thanks for all your hard work, now go eat peanuts." I have great appreciation for what PostgreSQL has become, and for the developers who have made it so. That is why I keep at this tired argument. I would like to know that this project will continue in a manner that benefits the little people, not just big corporate commercial interests. Perhaps some company _would_ like to pay the developers mucho dinero to continue PostgreSQL development. In fact I really hope so. I would just like to know that if that happened, there would be no obstacle to returning privately developed code to the public domain. Great Bridge has announced their intention to sell both products and services. What are the products? I'm going to bow out of this discussion. (applause!) Sorry if it sounds old and tired to the veterans among us. I'm a little green in the gills and I appreciate your sufferance. Ron Peterson [EMAIL PROTECTED]
Re: [GENERAL] PostgreSQL & the BSD License
>I'm confused here as to why pppl keep going to the "BSD license is >flawed" argument? The only "flaw" that I can see is that a) the copyright >ended '96 and b) it only covers "UNIVERSITY OF >CALIFORNIA" ... all that is being proposed *at this time* is to add in >coverage for the period *since* '96 and extend that coverage to >include *all* developers, not just the Univesrity of California ... > Plus the language about USE IN TRADE, LOSS OF ENJOYMENT, INFRINGEMENT, etc. This make three categories of changes: 1) extent the term to 2000, 2) cover all developers, 3) cover more types of possible liability. I agree with and understand your concern about terming the current BSD license "flawed". That term should certainly not be associated with the objective and spirit of the BSD license - and the BSD license itsself has met those objectives for many years. How about the license needs to be "updated?" >Now, a) is easily fixable by just extending the date to 2000, but that >still only covers "UNIVERSITY OF CALIFORNIA", and none of the actual >developers ... > >If ppl feel that neither a) or b) above aren't considered flaws, then let >us leave well enough alone ... > >The wording in the 'DEVELOPERS' section of what I sent out last night is a >little more verbose, so we could cut it down to be exactly the same as the >BSD one, and 'trim the fat' ... so that all we are "changing" is >"UNIVERSITY OF CALIFORNIA" to "DEVELOPERS", and leaving the rest of the >wording completely intact ... ? > >My personal feeling is that if the BSD license itself was so flawed, there >are at least another dozen projects out there that deal with commercial >enterprises on a larger scale then we do that would have done changes also >... I don't want to change the wording, I would just like to see it >extended to cover the ppl that are actually doing development and not just >UNIVERSITY OF CALIFORNIA ... > >make sense? or are we just sitting here discussing changes to a license >that doesn't need changing? > Well, I agree that logically the license *does* need to be "updated" and it might make sense to update the types of liabilities and other parts of the license also. This is probably best done in stages, first notifying other BSD projects that PostgreSQL will update the BSD license (on July xx) by extending coverage to all developers and extending the term of coverage to 2000, and inviting them to do the same. (It only makes sense for them to do likewise) Some might choose to cover "contributors" instead of "developers" or other minor changes but I would think that such a limited and straightforward changes could still qualify as a "BSD license" At the same time, postgresql could contact people from other major BSD projects asking them to review the language that covers additional potential liabilities. This review should be made know to all BSD projects with some letter or email explaining that any ultimate or proposed changes would be as conservative as possible and that a draft will be made avaialable on x date for public review. The major BSD projects should be committed to adopting whatever results from this process as the "BSD license" or "revised/updated BSD license standard" or what have you so that there is no backtracking, forking, or just plain waste of people's time and resources. Obviously this should all be done in the most practical and efficient possible way. A working committee of a few people from different major projects who collect info and set deadlines/milestones might need to be formed. In the end, it may be that everyone decides that change is unnecessary, or too problematic, but everyone will know that the issues have been properly addressed and that all opinions have been heard and considered. I know that this seems like more trouble than it should be, and that the license issue seems to balloon into an unmanageable beast, but IMO, it really needs to be addressed in a comprehensive way for all but the most minor or perfunctual changes (adding years to the copyright, for example, does not change the license). It is made more difficult by the fact that there is no central source for administering/updating the license (as the GPL as the FSF). John Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: [GENERAL] lztext and compression ratios...
[EMAIL PROTECTED] (Jan Wieck) writes: >> As long as you brought it up: how sure are you that the method you've >> used is not subject to any patents? > Now that you ask for it: I'm not sure. Could be. >> If you can show that this method uses no ideas not found in zlib, >> then I'll feel reassured > To do so I don't know enough about the algorithms used in > zlib. Is there someone out here who could verify that if I > detailed enough describe what our compression code does? After a quick look at the code, I don't think there is anything problematic about the data representation or the decompression algorithm. The compression algorithm is another story, and it's not real well commented :-(. The important issues are how you search for matches in the past text and how you decide which match is the best one to use. Please update the code comments to describe that, and I'll take another look. regards, tom lane
Re: [GENERAL] proposed improvements to PostgreSQL license
On Thu, 6 Jul 2000, Ron Peterson wrote:
> By the way, I hope I'm not coming across as saying "thanks for all
> your hard work, now go eat peanuts." I have great appreciation for
> what PostgreSQL has become, and for the developers who have made it
> so. That is why I keep at this tired argument. I would like to know
> that this project will continue in a manner that benefits the little
> people, not just big corporate commercial interests.
There are enough of us here who are commit'd to Open Source in general,
and PostgreSQL specifically, that that won't happen.
> Great Bridge has announced their intention to sell both products and
> services. What are the products?
>
> I'm going to bow out of this discussion. (applause!) Sorry if it
> sounds old and tired to the veterans among us. I'm a little green in
> the gills and I appreciate your sufferance.
>
>
> Ron Peterson
> [EMAIL PROTECTED]
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
RE: [GENERAL] Two questions in a row
> > 1. How do you remove one of two identical rows > > from a pgsql table ? > > DELETE FROM t1 WHERE wil do the stuff for you. If you don't know > the value into the duplicate field just export the database with pg_dump > create > a unique index onto this field and reimport all your data. Duplicate > data will > not be inserted. Another way could be to SELECT oid FROM table WHERE ...; and then delete based on that. However I believe it is possible to have two rows have the same oid but usually that isn't the case.
Re: [GENERAL] Find all the dates in the calendar week?
Stephane Bortzmeyer wrote: > > On Thursday 6 July 2000, at 18 h 5, the keyboard of "Andrew Snow" > <[EMAIL PROTECTED]> wrote: > > > SELECT event FROM events WHERE to_char(CURRENT_TIMESTAMP, 'ww') = > > to_char(eventdate, 'ww'); > > Sorry, I should have mentioned that I played with to_char and it seems the >documentation is wrong: > > conferences=> select * from conferences where to_char(CURRENT_TIMESTAMP, 'ww') = > conferences-> to_char(date_begin, 'ww'); > ERROR: No such function 'to_char' with the specified attributes > > Or it is a new feature of PostgreSQL 7? to_xxx are new to 7.0, thanks to Karel Zak. Mike Mascari
