Thread: Re: ARC patent
> > FYI, IBM has applied for a patent on ARC (AFAICS the patent > > application is still pending, although the USPTO site is a > little hard to grok): > > http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220040098541%22.PGNR.&OS=DN/20040098541&RS=DN/20040098541 How will this affect the release of 8.0? Wasn't this implemented in the early stages of the 7.5 cycle, long before may 20? ... John
"John Hansen" <john@geeknet.com.au> writes:
> How will this affect the release of 8.0?
I don't think it needs to delay the release; the patent is only pending.
But we need to look into the problem.
regards, tom lane
On Mon, Jan 17, 2005 at 03:14:31AM -0500, Tom Lane wrote: > I don't think it needs to delay the release; the patent is only pending. > But we need to look into the problem. What will you do if the patent is granted, 8.0 is out there with the offending code, and you get a cease-and-desist letter from IBM demanding the removal of all offending code from the Net? The code would have to be yanked from CVS &c., in that case, no? (IANAL, but I think I may consult with one.) A -- Andrew Sullivan | ajs@crankycanuck.ca The fact that technology doesn't work is no bar to success in the marketplace. --Philip Greenspun
Andrew Sullivan wrote: > On Mon, Jan 17, 2005 at 03:14:31AM -0500, Tom Lane wrote: > > I don't think it needs to delay the release; the patent is only pending. > > But we need to look into the problem. > > What will you do if the patent is granted, 8.0 is out there with the > offending code, and you get a cease-and-desist letter from IBM > demanding the removal of all offending code from the Net? The code > would have to be yanked from CVS &c., in that case, no? (IANAL, but > I think I may consult with one.) We can modify the code slightly to hopefully avoid the patent. With the US granting patents on even obvious ideas, I would think that most large software projects, including commercial ones, already have tons of patent violations in their code. Does anyone think otherwise? However, I will grant that ARC is not an obvious idea. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
>We can modify the code slightly to hopefully avoid the patent. With the >US granting patents on even obvious ideas, I would think that most large >software projects, including commercial ones, already have tons of >patent violations in their code. Does anyone think otherwise? > >However, I will grant that ARC is not an obvious idea. > > Speaking from a commercial perspective, if the community has known patent violating code within its source tree, the community needs to remove and or modify as to not violate that patent before any continued release. The last thing I am sure that: RedHat Pervasive SRA Fufitsu PgSQL, Inc. and of course Command Prompt want is a call from IBM saying... hey we aren't going to go after the community but you need to pay up. The patent risk is just entirely too great and it can greatly hurt the community as a whole. Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment
On Mon, Jan 17, 2005 at 02:37:44PM -0500, Bruce Momjian wrote: > > We can modify the code slightly to hopefully avoid the patent. With the I guess what I'm very much worried about is that there is potentially-infringing code there, we know about it, and we may press ahead and release with it anyway. IBM would justifiably jump on us for that as a result. What I simply don't know is what they can require be done as a remedy. If merely modifying the code is good enough, fine. But given how widely the code base will be disseminated, I'm worried they might demand that we somehow track it down and get rid of it. That would be a significant distraction, I think. > US granting patents on even obvious ideas, I would think that most large > software projects, including commercial ones, already have tons of > patent violations in their code. Does anyone think otherwise? First, that's hardly a justification, and second, they're not all subject to inspection. Plus, this is a case where we _know_ about the potential violation, and have had it pointed out to us, before the code has been declared "released". > However, I will grant that ARC is not an obvious idea. Precisely, or we wouldn't be pleased with the implementation. A -- Andrew Sullivan | ajs@crankycanuck.ca I remember when computers were frustrating because they *did* exactly what you told them to. That actually seems sort of quaint now. --J.D. Baldwin
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Andrew Sullivan wrote:
>> What will you do if the patent is granted, 8.0 is out there with the
>> offending code, and you get a cease-and-desist letter from IBM
>> demanding the removal of all offending code from the Net?
> We can modify the code slightly to hopefully avoid the patent. With the
> US granting patents on even obvious ideas, I would think that most large
> software projects, including commercial ones, already have tons of
> patent violations in their code. Does anyone think otherwise?
I think there is zero probability of being sued by IBM in the near
future. They would instantly destroy the credibility and good
relationships they've worked so hard to build up with the entire
open source community.
However, I don't want to be beholden to IBM indefinitely --- in five
years their corporate strategy might change. I think that a reasonable
response to this is to plan to get rid of ARC, or at least modify the
code enough to avoid the patent, in time for 8.1. (It's entirely likely
that that will happen before the patent issues, anyway.)
regards, tom lane
>However, I don't want to be beholden to IBM indefinitely --- in five >years their corporate strategy might change. I think that a reasonable >response to this is to plan to get rid of ARC, or at least modify the >code enough to avoid the patent, in time for 8.1. (It's entirely likely >that that will happen before the patent issues, anyway.) > > regards, tom lane > > IBM makes 20% of their money from licensing patents. That alone makes this whole conversation scare the hell out of me. We should be as proactive as possible with this and remove the code (or modify as required). Sincerely, Joshua D. Drake >---------------------------(end of broadcast)--------------------------- >TIP 4: Don't 'kill -9' the postmaster > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment
Andrew Sullivan <ajs@crankycanuck.ca> writes:
> I guess what I'm very much worried about is that there is
> potentially-infringing code there, we know about it, and we may press
> ahead and release with it anyway. IBM would justifiably jump on us
> for that as a result.
With what? They have no patent, yet, and may never have one. If the
patent were already issued then I'd be much more concerned.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Andrew Sullivan wrote: > >> What will you do if the patent is granted, 8.0 is out there with the > >> offending code, and you get a cease-and-desist letter from IBM > >> demanding the removal of all offending code from the Net? > > > We can modify the code slightly to hopefully avoid the patent. With the > > US granting patents on even obvious ideas, I would think that most large > > software projects, including commercial ones, already have tons of > > patent violations in their code. Does anyone think otherwise? > > I think there is zero probability of being sued by IBM in the near > future. They would instantly destroy the credibility and good > relationships they've worked so hard to build up with the entire > open source community. > > However, I don't want to be beholden to IBM indefinitely --- in five > years their corporate strategy might change. I think that a reasonable > response to this is to plan to get rid of ARC, or at least modify the > code enough to avoid the patent, in time for 8.1. (It's entirely likely > that that will happen before the patent issues, anyway.) We may already have modified the code enough to avoid the patent. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: > Andrew Sullivan <ajs@crankycanuck.ca> writes: > > I guess what I'm very much worried about is that there is > > potentially-infringing code there, we know about it, and we may press > > ahead and release with it anyway. IBM would justifiably jump on us > > for that as a result. > > With what? They have no patent, yet, and may never have one. If the > patent were already issued then I'd be much more concerned. One big question is why we pulled so directly from ideas on an IBM web site? That is very atypical of us. Because we used it, I assumed the ideas were available for all to use without patent restriction. Obviously not. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: >Bruce Momjian <pgman@candle.pha.pa.us> writes: > > >>Andrew Sullivan wrote: >> >> >>>What will you do if the patent is granted, 8.0 is out there with the >>>offending code, and you get a cease-and-desist letter from IBM >>>demanding the removal of all offending code from the Net? >>> >>> > > > >>We can modify the code slightly to hopefully avoid the patent. With the >>US granting patents on even obvious ideas, I would think that most large >>software projects, including commercial ones, already have tons of >>patent violations in their code. Does anyone think otherwise? >> >> > >I think there is zero probability of being sued by IBM in the near >future. They would instantly destroy the credibility and good >relationships they've worked so hard to build up with the entire >open source community. > >However, I don't want to be beholden to IBM indefinitely --- in five >years their corporate strategy might change. I think that a reasonable >response to this is to plan to get rid of ARC, or at least modify the >code enough to avoid the patent, in time for 8.1. (It's entirely likely >that that will happen before the patent issues, anyway.) > > > > There's a very recent paper at http://carmen.cs.uiuc.edu/~zchen9/paper/TPDS-final.ps on an alternative to ARC which claims superior performance ... Maybe this will give us added impetus to make the 8.1 cycle short, as has been suggested previously. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes: > There's a very recent paper at > http://carmen.cs.uiuc.edu/~zchen9/paper/TPDS-final.ps on an alternative > to ARC which claims superior performance ... Personally, I'd prefer a very *old* paper ;-) > Maybe this will give us added impetus to make the 8.1 cycle short, as > has been suggested previously. Agreed. If we have a plan to replace the code in three-to-six months I think we are all right, especially seeing that this is only a pending patent and not enforceable yet. To those who say "you can't release with a potential patent problem" I would say that we already have. There are lots of people running 8.0 beta and RC releases --- if history is any guide, many of them will continue running those releases for a long time, rather than update to final. We can never erase all trace that we ever touched ARC (would you have us retroactively edit our CVS history?) and AFAIK we would not be required to do so anyway. The legal requirement would be to cure the breach going forward, ie, get it out of our future releases. That we can and should do, but there's no need for panic. regards, tom lane
On Jan 17, 2005, at 2:57 PM, Joshua D. Drake wrote: > > We should be as proactive as possible with this and remove > the code (or modify as required). > Perhaps a member of -CORE should contact IBM. The ball is out there now due to the discussion on this list that we know we might have infringing code. Might as well try to play "good citizen" and talk with them, perhaps they'll give us some sort of indemnity for 8.0 so we can get something perhaps better for 8.1. -- Jeff Trout <jeff@jefftrout.com> http://www.jefftrout.com/ http://www.stuarthamm.net/
On Mon, Jan 17, 2005 at 02:48:46PM -0500, Tom Lane wrote: > I think there is zero probability of being sued by IBM in the near > future. They won't sue the project. They'll send corporate users a bill, instead, for a license. A -- Andrew Sullivan | ajs@crankycanuck.ca A certain description of men are for getting out of debt, yet are against all taxes for raising money to pay it off. --Alexander Hamilton
On Mon, Jan 17, 2005 at 02:58:33PM -0500, Tom Lane wrote: > Andrew Sullivan <ajs@crankycanuck.ca> writes: > > ahead and release with it anyway. IBM would justifiably jump on us > > for that as a result. > > With what? They have no patent, yet, and may never have one. If the > patent were already issued then I'd be much more concerned. With a team of lawyers which we can't match. They may never have a patent, or they may get it next month. I'd feel more comfortable if I knew what sort of remedies they could demand (I have a call open to a lawyer I believe will give me a conservative answer about that). What I can say, for sure, is that no responsible corporate user will be able to use this code with the threat hanging over. The recent SCO stuff ought to be a lesson here: their claims appear to have been completely baseless, but companies still spent a pile of time and money on the issue. It'll be far worse in a case where the infringment is real and, yet worse, intentional. A -- Andrew Sullivan | ajs@crankycanuck.ca When my information changes, I alter my conclusions. What do you do sir? --attr. John Maynard Keynes
> I think there is zero probability of being sued by IBM in the near > future. They would instantly destroy the credibility and good > relationships they've worked so hard to build up with the entire > open source community. > > However, I don't want to be beholden to IBM indefinitely --- in five > years their corporate strategy might change. I think that a reasonable > response to this is to plan to get rid of ARC, or at least modify the > code enough to avoid the patent, in time for 8.1. (It's entirely likely > that that will happen before the patent issues, anyway.) > If PostgreSQL 8.0 is released with ARC, and then PostgreSQL 8.1 is released without ARC, and then the patent is granted to IBM, would everyone be fine if they just all switched to 8.1 at that time? Or would we have some kind of retroactive problem? Would people that are still using 8.0 in production, but not distributing it, have difficulty? Regards,Jeff
>If PostgreSQL 8.0 is released with ARC, and then PostgreSQL 8.1 is >released without ARC, and then the patent is granted to IBM, would >everyone be fine if they just all switched to 8.1 at that time? Or would >we have some kind of retroactive problem? Would people that are still >using 8.0 in production, but not distributing it, have difficulty? > > The biggest problem is going to be that if we release 8 with the patented stuff, then for a minimum of 3 years there will be liability for anyone running 8. We still have people running 7.1 and once you get something into production you typically don't just "change" it. Basically I think the fact that we are even considering leaving the knowingly infringing code in 8 is presenting a horrible face to the community. Sincerely, Joshua D. Drake >Regards, > Jeff > > > >---------------------------(end of broadcast)--------------------------- >TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment
Andrew Sullivan wrote: > With a team of lawyers which we can't match. They may never have a > patent, or they may get it next month. I'd feel more > comfortable if I knew what sort of remedies they could demand (I have > a call open to a lawyer I believe will give me a conservative answer > about that). > > What I can say, for sure, is that no responsible corporate user will > be able to use this code with the threat hanging over. The recent > SCO stuff ought to be a lesson here: their claims appear to have been > completely baseless, but companies still spent a pile of time and > money on the issue. It'll be far worse in a case where the > infringment is real and, yet worse, intentional. You want scarey --- forget the IBM patent. Find an Oracle or Microsoft patent that is similar to something in our code. It will might not be exact, but our ARC isn't exact either. Basically any organization that wants to produce patent-free code would need one lawyer for every five programmers, and even then it isn't 100%. The method I have heard to find infringement sounds pretty imprecise. The remedy for patent infringment I think is usually to stop using the patented idea, rather than punitive damages, unlike copyright. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> >> FYI, IBM has applied for a patent on ARC (AFAICS the patent application > >> is still pending, although the USPTO site is a little hard to grok): > > > >> > http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220040098541%22.PGNR.&OS=DN/20040098541&RS=DN/20040098541 > > > > Ugh. We could hope that the patent wouldn't be granted, but I think > > it unlikely, unless Jan is aware of prior art (like a publication > > predating the filing date). I fear we'll have to change or remove > > that code. > > > > regards, tom lane > > Unfortunately no. The document that inspired me to adapt ARC for > PostgreSQL is from the USENIX File & Storage Technologies Conference > (FAST), March 31, 2003, San Francisco, CA. > > I am seriously concerned about this and think we should not knowingly > release code that is possibly infringing a patent. I thought IBM granted the right to use these methods in OSS software. PostgreSQL is OSS software, thus only such entities relicensing pg need to worry about the patent. Also the algo is probably sufficiently altered already to not be subject to the patent, no ? Andreas
"Joshua D. Drake" <jd@commandprompt.com> writes:
> The biggest problem is going to be that if we release 8 with
> the patented stuff, then for a minimum of 3 years there will
> be liability for anyone running 8.
Do you honestly think that this is the only patented algorithm anywhere
in there?
Now that we've been made aware that there is a pending (one more time:
pending, not issued) patent on it, we will work on removing the affected
code in an orderly fashion. I don't think there is need for panic.
regards, tom lane
Zeugswetter Andreas DAZ SD wrote: > > > >> FYI, IBM has applied for a patent on ARC (AFAICS the patent application > > >> is still pending, although the USPTO site is a little hard to grok): > > > > > >> > > http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220040098541%22.PGNR.&OS=DN/20040098541&RS=DN/20040098541 > > > > > > Ugh. We could hope that the patent wouldn't be granted, but I think > > > it unlikely, unless Jan is aware of prior art (like a publication > > > predating the filing date). I fear we'll have to change or remove > > > that code. > > > > > > regards, tom lane > > > > Unfortunately no. The document that inspired me to adapt ARC for > > PostgreSQL is from the USENIX File & Storage Technologies Conference > > (FAST), March 31, 2003, San Francisco, CA. > > > > I am seriously concerned about this and think we should not knowingly > > release code that is possibly infringing a patent. > > I thought IBM granted the right to use these methods in OSS software. > PostgreSQL is OSS software, thus only such entities relicensing pg > need to worry about the patent. ARC wasn't in the 500 patents released to open source. Also, I don't think the offer extends to companys like Pervasive and Command Prompt that ship commercial versions of PostgreSQL. > Also the algo is probably sufficiently altered already to not be subject > to the patent, no ? I hope so. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> > Unfortunately no. The document that inspired me to adapt ARC for > > PostgreSQL is from the USENIX File & Storage Technologies > Conference > > (FAST), March 31, 2003, San Francisco, CA. Ahemm,... Isn't the patent lodged on may 20, 2004, AFTER you read the document from the above conference? ... John
> You want scarey --- forget the IBM patent. Find an Oracle or Microsoft > patent that is similar to something in our code. It will might not be > exact, but our ARC isn't exact either. > > Basically any organization that wants to produce patent-free code would > need one lawyer for every five programmers, and even then it isn't 100%. > The method I have heard to find infringement sounds pretty imprecise. > > The remedy for patent infringment I think is usually to stop using the > patented idea, rather than punitive damages, unlike copyright. > Is that for all kinds of patent infringement, or only the didn't-know-better kind? Right now I don't think we can claim "didn't-know-better". Also, does "stop" mean stop distributing the patented process, or stop using all installations? Regards,Jeff Davis
On Mon, Jan 17, 2005 at 05:04:36PM -0400, Marc G. Fournier wrote: > > I thought the patnt was only pending, not granted? That's right, and it's what gives Tom's arguments some weight. A -- Andrew Sullivan | ajs@crankycanuck.ca Information security isn't a technological problem. It's an economics problem. --Bruce Schneier
On Mon, 17 Jan 2005, Andrew Sullivan wrote: > On Mon, Jan 17, 2005 at 02:37:44PM -0500, Bruce Momjian wrote: >> >> We can modify the code slightly to hopefully avoid the patent. With the > > I guess what I'm very much worried about is that there is > potentially-infringing code there, we know about it, and we may press > ahead and release with it anyway. IBM would justifiably jump on us > for that as a result. I thought the patnt was only pending, not granted? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> ARC wasn't in the 500 patents released to open source.
... because it isn't a patent, yet.
regards, tom lane
Jeff Davis wrote: > > > You want scarey --- forget the IBM patent. Find an Oracle or Microsoft > > patent that is similar to something in our code. It will might not be > > exact, but our ARC isn't exact either. > > > > Basically any organization that wants to produce patent-free code would > > need one lawyer for every five programmers, and even then it isn't 100%. > > The method I have heard to find infringement sounds pretty imprecise. > > > > The remedy for patent infringment I think is usually to stop using the > > patented idea, rather than punitive damages, unlike copyright. > > > > Is that for all kinds of patent infringement, or only the > didn't-know-better kind? Right now I don't think we can claim > "didn't-know-better". Didn't know better has no status for patents. Copyright stuff is pretty easy to avoid --- just don't copy stuff and you are OK, and most companies are good at enforcing that part. > Also, does "stop" mean stop distributing the patented process, or stop > using all installations? Not sure. The PostgreSQL development group doesn't have installations, do we? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > ARC wasn't in the 500 patents released to open source. > > ... because it isn't a patent, yet. Yea, but IBM has thousands of patents. The odds that this particular patent would have been in the 500 if it was granted is unlikely, no? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Tue, Jan 18, 2005 at 08:03:01AM +1100, John Hansen wrote: > Ahemm,... Isn't the patent lodged on may 20, 2004, AFTER you read > the document from the above conference? No, the patent application is filed on 14 November 2002, according to the URL that Neil posted. A -- Andrew Sullivan | ajs@crankycanuck.ca This work was visionary and imaginative, and goes to show that visionary and imaginative work need not end up well. --Dennis Ritchie
John Hansen wrote: >>>Unfortunately no. The document that inspired me to adapt ARC for >>>PostgreSQL is from the USENIX File & Storage Technologies >>> >>> >>Conference >> >> >>>(FAST), March 31, 2003, San Francisco, CA. >>> >>> > >Ahemm,... Isn't the patent lodged on may 20, 2004, AFTER you read the document from the above conference? > > The patent claim was filed on *November 14, 2002 according to the docs. It might have been updated in May 2004, or some other action, but the filing date is the one that counts. You can certainly trust IBM not to let their guys preclude a patent they intend to file by doing prior publication. cheers andrew *
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>> ARC wasn't in the 500 patents released to open source.
>> ... because it isn't a patent, yet.
> Yea, but IBM has thousands of patents. The odds that this particular
> patent would have been in the 500 if it was granted is unlikely, no?
That's hard to say. But the reason we know without looking that it's
not in that list is that they can't have released a patent they don't
have yet.
regards, tom lane
"John Hansen" <john@geeknet.com.au> writes:
>> Unfortunately no. The document that inspired me to adapt ARC for
>> PostgreSQL is from the USENIX File & Storage Technologies
>> Conference (FAST), March 31, 2003, San Francisco, CA.
> Ahemm,... Isn't the patent lodged on may 20, 2004, AFTER you read the document from the above conference?
No, the filing date was in 2002. I'm not sure what the May/04 date means;
possibly the date of the last activity in that patent file?
regards, tom lane
Greetings, I would like to contribute my $.02 to this issue. I speak as not a lawyer but as someone tho worked one and a half year in a patent bureau and even got a certificate from WIPO (http://academy.wipo.int/ those who interested may attend the course too, it is free). First, the whole point of USPTO's publishing patents which are pending is to get it publicly reviewed and collect objections before final decision. So, those of you who live in US file and objection based on "USENIX File & Storage Technologies Conference (FAST), March 31, 2003, San Francisco, CA" mentioned by Jan Wieck. Filing and objection should be not be too expensive though you may need help of professional lawyer form a patent bureau co compose a solid objection. I will call my old friends from Patent Bureau tomorrow to get a professional advise on this matter. Second, a pending patent is not a granted patent, one is not infringing anything by distributing technology based in a pending patent. As soon as patent is granted AND "Cease and Desist" letter form IBM is received removing offending code, removing offending versions from download and and notifying customers to upgrade to a new version is sufficient. I am not sure about CVS, apparently it need to be cleared out too. A vaguely similar issue happened between Pixar, the developer of Renderman and Exluna the developer of BMRT, a free (but not open source) raytracing 3D renderer. Pixar sued Exluna for willful patent infringement. Exluna released a new version of BMRT - 2.6 without offending technology and ensured that version 2.5 is removed from all mirrors. For quite a lot of time -and even now- one of the most valuable things a 3D designer may own is a copy of BMRT version 2.5. Exluna was intended to defend themselves in court but soon ran out of money, settled with Pixar and was swallowed by nVidia. A sad story indeed. A story of how a big company squashes a small one using patents. Read more at: http://www.renderman.org/RMR/OtherLinks/blackSIGGRAPH.html The point here is that IBM may force PostgreSQL Global Development Group to remove offending version if patent is granted. But, lastly, as it was pointed out before it would be a very bad publicity for IBM and, in my opinion, very good publicity for PostgreSQL. IBM will admit that PostgreSQL is a worthy competitor. Thus, in my personal opinion IBM will never threat PostgreSQL. We can remove offending code but host patches to introduce the code in a country that does accept software patents. It would be even better for publicity. IBM can NEVER sue customers for using infringing code before first informing them of infringement and giving reasonable time to upgrade to uninfringing version. So, in short my advise is: 1. File an objection with USPTO. And maybe an informative letter to IBM legal department mentioning USENIX paper. 2. Ifpatent is granted, contact IBM and request an unlimited, perpetual license to use the technology 3. If IBM refuses, removethe offending code, clean up CVS and shout from the rooftops about the hypocrisy of IBM. Hope it helps make up your mind, Best regards, Nicolai Tufar P.S. But if filing date really is 2002 and there is no prior art me may skip step 1.
The previous snipped wording was very insightful, thank you. > >IBM can NEVER sue customers for using infringing >code before first informing them of infringement and >giving reasonable time to upgrade to uninfringing >version. > > I can see it now: We won't sue you (customer) but you have to upgrade to DB2 ;) Sincerely, Joshua D. Drake >So, in short my advise is: > > 1. File an objection with USPTO. And maybe an informative > letter to IBM legal department mentioning USENIX paper. > 2. If patent is granted, contact IBM and request > an unlimited, perpetual license to use the technology > 3. If IBM refuses, remove the offending code, clean up > CVS and shout from the rooftops about the hypocrisy of > IBM. > >Hope it helps make up your mind, >Best regards, >Nicolai Tufar > >P.S. But if filing date really is 2002 and there >is no prior art me may skip step 1. > >---------------------------(end of broadcast)--------------------------- >TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment
Tom Lane <tgl@sss.pgh.pa.us> writes: > "John Hansen" <john@geeknet.com.au> writes: > >> Unfortunately no. The document that inspired me to adapt ARC for > >> PostgreSQL is from the USENIX File & Storage Technologies > >> Conference (FAST), March 31, 2003, San Francisco, CA. > > > Ahemm,... Isn't the patent lodged on may 20, 2004, AFTER you read the document from the above conference? > > No, the filing date was in 2002. I'm not sure what the May/04 date means; > possibly the date of the last activity in that patent file? Was the USENIX paper published from IBM? Was it the first publication of the ARC algorithm? They have to file for the patent within 1 year of the first publication. If it was published prior to Nov 2001 then perhaps an objection could be filed on that issue. Also, as far as I know the "we didn't know better" is in fact precisely an issue with patents. If we didn't know about the ARC patent then IBM's only remedy once the patent is issued would be to insist users stop using it. Only if users refused (say because 8.1 still hadn't been released) could IBM then start asking for damages. It's clear Postgres developers know of the potential infringement so when and if that patent is issued Postgres users will have to upgrade immediately to avoid remedies that could include liability. Whereas for the myriad of potential infringements on vaguely worded patents there's no risk beyond having to cease the infringement. Any idea what kind of timescale the patent application is on? Will it be another year or two before it's issued or is it possible it'll be issued prior to 8.1 being released? Though I suppose it would always be possible to release an 8.0.x with ARC removed for users like Fujitsu or SRA concerned with liability. -- greg
On Mon, 17 Jan 2005 14:02:14 -0800, Joshua D. Drake <jd@commandprompt.com> wrote: > > >IBM can NEVER sue customers for using infringing > >code before first informing them of infringement and > >giving reasonable time to upgrade to uninfringing > >version. > I can see it now: > We won't sue you (customer) but you have to upgrade > to DB2 ;) More like downgrading, actually ;) > Sincerely, > Joshua D. Drake
> >IBM can NEVER sue customers for using infringing > >code before first informing them of infringement and > >giving reasonable time to upgrade to uninfringing > >version. That's not true. If you *knowingly* violated a patent IBM can sue you for the damages caused. If you weren't aware of the patent then IBM can only ask you to cease the infringement and can only then sue for damages caused after that point in time. Though in the given situation I don't see how IBM could argue any damages. It's not like they have any licensing business for ARC nor would anyone be willing to pay for a license to ARC. There are plenty of other algorithms that are perfectly passable. Of course, IANAL and all that. But I'm sure legal advice from this mailing list is worth every penny you've paid for it :) "Joshua D. Drake" <jd@www.commandprompt.com> writes: > I can see it now: > > We won't sue you (customer) but you have to upgrade > to DB2 ;) Heh. -- greg
Tom Lane wrote: > "John Hansen" <john@geeknet.com.au> writes: > >>>Unfortunately no. The document that inspired me to adapt ARC for >>>PostgreSQL is from the USENIX File & Storage Technologies >>>Conference (FAST), March 31, 2003, San Francisco, CA. > > >>Ahemm,... Isn't the patent lodged on may 20, 2004, AFTER you read the document from the above conference? > > > No, the filing date was in 2002. I'm not sure what the May/04 date means; > possibly the date of the last activity in that patent file? Sounds to me like US conferences need to get a disclaimer signed by any speakers - "best of my knowledge...covered by no patents/claims/...". It's like having a bowl of sweets labelled "help yourself" and putting the price sticker inside the wrapper. -- Richard Huxton Archonet Ltd
Nicolai Tufar <ntufar@gmail.com> writes: > I would like to contribute my $.02 to this issue. > I speak as not a lawyer but as someone tho worked > one and a half year in a patent bureau and even > got a certificate from WIPO (http://academy.wipo.int/ > those who interested may attend the course too, it > is free). > [ much good stuff snipped ] Many thanks for the informed commentary. I'd like to make another point, which is that it's quite unclear what the patent will end up covering. Claim 1 essentially claims using two lists to manage a cache. That's not going to withstand scrutiny as an independent claim --- heck, we've got prior art for that in our own code (see catcache.c, which has done something of the sort since Berkeley days). Somewhere between claim 1 and claim 61 there is a sufficiently specific concept to be patentable, but we won't know what that is until the final patent is issued. There's no moral turpitude in wanting to see what the issued patent looks like before deciding whether we violate it or what to do about it. That's not to say that we shouldn't be proactive in doing something as soon as we conveniently can. It's to say that we don't have to panic into not releasing 8.0. regards, tom lane
Nov 2002 is the date of filing the patent application, while May 2004 is the publish date. For regular patent application,the USPTO will treat that application with secrecy for the first 18 months of the examining process. About 18months after the application, the USPTO will publish the patent application. For most companies with deep pocket, they never publish new papers/ideas without filing a regular or provisional patent applicationfirst. -----Original Message----- From: Andrew Dunstan [mailto:andrew@dunslane.net] Sent: Monday, January 17, 2005 3:14 PM To: John Hansen Cc: Zeugswetter Andreas DAZ SD; Jan Wieck; Tom Lane; Neil Conway; pgsql-hackers Subject: Re: [HACKERS] ARC patent John Hansen wrote: >>>Unfortunately no. The document that inspired me to adapt ARC for >>>PostgreSQL is from the USENIX File & Storage Technologies >>> >>> >>Conference >> >> >>>(FAST), March 31, 2003, San Francisco, CA. >>> >>> > >Ahemm,... Isn't the patent lodged on may 20, 2004, AFTER you read the document from the above conference? > > The patent claim was filed on *November 14, 2002 according to the docs. It might have been updated in May 2004, or some other action, but the filing date is the one that counts. You can certainly trust IBM not to let their guys preclude a patent they intend to file by doing prior publication. cheers andrew * ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
Nicolai Tufar wrote: > Second, a pending patent is not a granted patent, > one is not infringing anything by distributing > technology based in a pending patent. Given the patents the USPTO has been granting in recent times, if a patent is pending, it's almost certainly going to be granted. Especially if it comes from an entity such as IBM (the USPTO wouldn't want to upset its biggest paying customers, would it?), and especially if it's on something that isn't completely trivial. For that reason, I think it's quite reasonable to treat any pending patent from IBM as if it were a granted patent. The only way I could see the patent not being granted is if some large corporate entity like Microsoft filed an objection. That's possible, I suppose, but not something I would want to count on. But objections raised by small entities such as individuals will almost certainly be dropped on the floor, because such entities don't matter to the USPTO (or the rest of the government, for that matter), unless they are flush with cash. > IBM can NEVER sue customers for using infringing > code before first informing them of infringement and > giving reasonable time to upgrade to uninfringing > version. This is the United States. People (and especially large corporations) can sue anybody for anything anytime they wish. And they do. Reason doesn't enter into it. Only money. See the SCO debacle for proof, and note that they're not suing in any other countries. If I sound bitter and cynical, well, there's lots of good reason for it. You need only look around, at least if you're in the U.S. -- Kevin Brown kevin@sysexperts.com
On Mon, 2005-01-17 at 12:30 -0800, Joshua D. Drake wrote: > The biggest problem is going to be that if we release 8 with > the patented stuff, then for a minimum of 3 years there will > be liability for anyone running 8. > > We still have people running 7.1 and once you get something > into production you typically don't just "change" it. Keep in mind that it would be conceivable to ship an 8.0.x release which replaces ARC with another algorithm. That would be a somewhat non-trivial change, but there's no reason we need to wait for a major release (i.e. 8.1 or 8.2) to replace ARC. > Basically I think the fact that we are even considering leaving > the knowingly infringing code in 8 is presenting a horrible > face to the community. I agree with Tom -- this shouldn't be an impediment to releasing 8.0, but it definitely warrants attention in the future. -Neil
On Mon, 2005-01-17 at 14:02 -0800, Joshua D. Drake wrote: > >IBM can NEVER sue customers for using infringing > >code before first informing them of infringement and > >giving reasonable time to upgrade to uninfringing > >version. > > > I can see it now: > > We won't sue you (customer) but you have to upgrade > to DB2 ;) This is panic and is wrong-headed. They haven't even sent a letter yet... If we believe in this project, then ultimately, we should be aware that the future *is* litigation, just like with Linux. Successful people/projects/companies will at some point have to play hardball. That's nothing to run scared of, unless you feel you have or will do some harm to another. Tom's view seems correct. IBM have *applied* for a patent; the community is now aware of this and must plan accordingly. I see no reason to contact IBM; they have no basis to complain as yet. If they had wished to protect their patent they could have done so earlier - the dev process here is open and visible, so there is a reasonable onus on them to perform some form of minimum attentiveness on us if they see us as competition. I have no reason to believe they do and our current understanding is that IBM supports Open Source and therefore this project. We support AIX, Linux on PowerPC, Linux on S/390, jdbc on WAS to name but a few things IBM would be very happy with. The patent has not yet been granted and seems to have been pending for at least 18 months. We therefore have reason to believe there is some chance it may not be granted, related prior art on buffer management stretching back more than 30 years. By taking reasonable actions now we will buy ourselves reasonable time should it ever be granted. It seems clear that anybody on 8.0.0ARC after the patent had been granted could potentially be liable to pay damages. At best, the community would need to do a "product recall" to ensure patents were not infringed. So, it also seems clear that 8.0.x should eventually have a straight upgrade path to a replacement, assuming the patent is granted. We should therefore plan to: 1. improve/replace ARC for 8.1 2. backport any replacement directly onto 8.0STABLE as soon as any patent is granted Point 1 was going to happen anyway, so there is really less to worry about. ARC is a better idea; it is likely there are even better ones. ARC says nothing of how to clean the LRUs of dirty pages, nor does it specify how to scale the algorithm to multiple CPUs. The code already supports such a migration from 8.0.0 to 8.0.x If any community members are planning selling products derived from PostgreSQL 8.0.0 then it might be in your interest to put some money in the pot for a legal fund and also to fund dev of a new buffer management strategy. If those community members wish to delay release of their own derived products then that's up to them. -- Best Regards, Simon Riggs
Simon Riggs wrote: >On Mon, 2005-01-17 at 14:02 -0800, Joshua D. Drake wrote: > > >>>IBM can NEVER sue customers for using infringing >>>code before first informing them of infringement and >>>giving reasonable time to upgrade to uninfringing >>>version. >>> >>> >>> >>I can see it now: >> >>We won't sue you (customer) but you have to upgrade >>to DB2 ;) >> >> > >This is panic and is wrong-headed. They haven't even sent a letter >yet... > > Simon please note that it was a joke :) Thus the ;). Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment
> We won't sue you (customer) but you have to upgrade > to DB2 ;) ^^ For the smiley impaired, I think it pretty clear that Mr. Drake was joking.
Neil Conway <neilc@samurai.com> writes:
> Keep in mind that it would be conceivable to ship an 8.0.x release which
> replaces ARC with another algorithm. That would be a somewhat
> non-trivial change, but there's no reason we need to wait for a major
> release (i.e. 8.1 or 8.2) to replace ARC.
It's not that we couldn't fold a non-ARC algorithm into the 8.0.x
release series, it's that it'd be a fairly fundamental change in
some critical code. Critical from both the reliability and performance
standpoints. I would be comfortable with developing a replacement
algorithm as part of the 8.1 development cycle, and then considering
a back-patch after 8.1 is out and has shown that it's not completely
broken. But to replace it with less testing than that would be
irresponsible, at least by the standards we have customarily used for
minor releases.
This is assuming that we conclude we need a whole new algorithm to
dodge the patent. Another line of attack should be to see whether we
can make minor tweaks to avoid it. I'm pessimistic about that, but
it deserves some amount of investigation before we go down the wholesale
replacement path.
We already had been considering a short development cycle for 8.1, and
I think that this issue will set that decision in stone. What I'm
currently thinking about is a couple of months development and the same
for beta, which would allow a release in June or so. I have already
suggested to core that we should insist on 8.1 not requiring an initdb,
so as to ensure that people will migrate up to it easily from 8.0.
Aside from the ARC issue, we have already one significant Windows
porting issue (%$n in message strings) and I'm sure we will find more
once 8.0 is out and getting some real use. I would expect us to focus
on fixing issues of that caliber and probably being pretty stingy on
new features.
(Of course, if we do take this approach, it's questionable whether we'd
need to bother with a back-patch.)
regards, tom lane
Simon Riggs wrote: >So, it also seems clear that 8.0.x should eventually have a straight >upgrade path to a replacement, assuming the patent is granted. > >We should therefore plan to: >1. improve/replace ARC for 8.1 >2. backport any replacement directly onto 8.0STABLE as soon as any >patent is granted > > > > One of the reasons for Postgres' well deserved reputation for stability and reliability is that stable branches are ... stable. Backporting a large item like cache replacement mechanism doesn't seem to fit that too well. I wouldn't want to do that except as a complete last resort. cheers andrew
On Mon, 2005-01-17 at 15:30 -0800, Joshua D. Drake wrote: > Simon Riggs wrote: > > >On Mon, 2005-01-17 at 14:02 -0800, Joshua D. Drake wrote: > > > > > >>>IBM can NEVER sue customers for using infringing > >>>code before first informing them of infringement and > >>>giving reasonable time to upgrade to uninfringing > >>>version. > >>> > >>I can see it now: > >> > >>We won't sue you (customer) but you have to upgrade > >>to DB2 ;) > >> > >> > > > >This is panic and is wrong-headed. They haven't even sent a letter > >yet... > > > Simon please note that it was a joke :) Thus the ;). Sue me. :-) But read the rest of my posting first. -- Best Regards, Simon Riggs
On Tue, 2005-01-18 at 10:15 +1100, Neil Conway wrote: > On Mon, 2005-01-17 at 12:30 -0800, Joshua D. Drake wrote: > > The biggest problem is going to be that if we release 8 with > > the patented stuff, then for a minimum of 3 years there will > > be liability for anyone running 8. > > > > We still have people running 7.1 and once you get something > > into production you typically don't just "change" it. > > Keep in mind that it would be conceivable to ship an 8.0.x release which > replaces ARC with another algorithm. That would be a somewhat > non-trivial change, but there's no reason we need to wait for a major > release (i.e. 8.1 or 8.2) to replace ARC. Agreed. > > Basically I think the fact that we are even considering leaving > > the knowingly infringing code in 8 is presenting a horrible > > face to the community. > > I agree with Tom -- this shouldn't be an impediment to releasing 8.0, > but it definitely warrants attention in the future. > Agreed. -- Best Regards, Simon Riggs
On Mon, 2005-01-17 at 18:51 -0500, Andrew Dunstan wrote: > > Simon Riggs wrote: > > >So, it also seems clear that 8.0.x should eventually have a straight > >upgrade path to a replacement, assuming the patent is granted. > > > >We should therefore plan to: > >1. improve/replace ARC for 8.1 > >2. backport any replacement directly onto 8.0STABLE as soon as any > >patent is granted > > > One of the reasons for Postgres' well deserved reputation for stability > and reliability is that stable branches are ... stable. Backporting a > large item like cache replacement mechanism doesn't seem to fit that too > well. I wouldn't want to do that except as a complete last resort. I agree... but I see no alternative to my point (2) though; I would welcome additional options. -- Best Regards, Simon Riggs
I think the ARC issue is the same with any other patent ... Recently somebody pointed me to a nice site showing some examples: http://www.base.com/software-patents/examples.html Looking at the list briefly I can find at least five patent problems using any operating system with PostgreSQL. From my point of view having the ARC in there is just as safe / unsafe as using "Hello World" and compile it with GCC. I don't think it possible to sue a community anyway. Best regards and have fun reading those examples, Hans -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/660/816 40 77 www.cybertec.at, www.postgresql.at
Andrew Dunstan <andrew@dunslane.net> writes: > Simon Riggs wrote: > >>So, it also seems clear that 8.0.x should eventually have a straight >>upgrade path to a replacement, assuming the patent is granted. We >>should therefore plan to: 1. improve/replace ARC for 8.1 2. backport >>any replacement directly onto 8.0STABLE as soon as any patent is >>granted > > One of the reasons for Postgres' well deserved reputation for > stability and reliability is that stable branches are > ... stable. Backporting a large item like cache replacement mechanism > doesn't seem to fit that too well. I wouldn't want to do that except > as a complete last resort. Exactly, which is why it probably won't happen. Tom's got the right idea. Simply release 8.0, and then start planning for 8.1. If and when IBM gets this patent approved, and if and when IBM starts sending out letters then PostgreSQL will be prepared with non-infringing versions. The *real* moral of the story, however, is that it is not smart for developers to go poking through patent databases. The real problems with patents begin when the patent holder can prove that you *knew* about an *approved* patent and still released the software anyhow. So don't browse through the patent databases, and for heaven's sake, if you find a patent that PostgreSQL *might* be infringing whatever you do don't post about it on the PostgreSQL mailing lists. I am not a lawyer, but I think that the only sane thing to do is to follow the lead of the Linux kernel developers and stay away from any sort of patent research. You really don't want to know how many patents PostgreSQL is infringing, and you certainly don't want to talk about it on a public forum (or anywhere else). My guess is that IBM isn't likely to be interested in spending millions of dollars litigating agains the PostgreSQL project and various PostgreSQL end users. Suing customers (and potential customers) is always bad form, and chasing after a Free Software project is likely to be a PR disaster. However, even if IBM were interested in "cashing in" on this patent, they can't do that until the patent is actually granted. Jason
On Mon, 2005-01-17 at 15:11 -0500, Andrew Dunstan wrote: > There's a very recent paper at > http://carmen.cs.uiuc.edu/~zchen9/paper/TPDS-final.ps on an alternative > to ARC which claims superior performance ... >From a quick glance, this doesn't look applicable. The authors are discussing buffer replacement strategies for a multi-level cache hierarchy (e.g. they would call the DBMS buffer cache "L1", and the kernel I/O cache "L2" -- note that despite the terminology, this has little in common with L1/L2 caches in processors). They don't really address caching for the L1-only case -- they're concerned with proposing algorithms to manage the L2 cache (with or without explicit knowledge about the content of the L1 cache). A few years ago Tom implemented the LRU-K replacement policy[1], but AFAIK the performance results from that weren't very positive (since the implementation of LRU-K requires a heap and is therefore logarithmic rather than constant time, that makes sense). The 2Q algorithm looks like it might be worth investigating[2]. -Neil [1] http://citeseer.ist.psu.edu/16869.html [2] http://citeseer.ist.psu.edu/63909.html
On Mon, 2005-01-17 at 18:43 -0500, Tom Lane wrote: > I have already > suggested to core that we should insist on 8.1 not requiring an initdb, > so as to ensure that people will migrate up to it easily from 8.0. So is it firm policy that changes that require a catversion update cannot be made during the 8.1 cycle? (Needless to say, it would be good to get this sorted out early on in the 8.1 development cycle, to avoid the need to revert patches at some point down the line. For those of us working on large projects that will definitely require an initdb, it would also be good to know -- as this policy will likely prevent that work from getting into 8.1) -Neil
On Wed, Jan 19, 2005 at 10:48:00AM +1100, Neil Conway wrote: > On Mon, 2005-01-17 at 18:43 -0500, Tom Lane wrote: > > I have already > > suggested to core that we should insist on 8.1 not requiring an initdb, > > so as to ensure that people will migrate up to it easily from 8.0. > > So is it firm policy that changes that require a catversion update > cannot be made during the 8.1 cycle? Hmm. That means my shared dependency patch cannot go in, nor anything I do about shared row locking. Fortunately that leaves the multitable truncate and the C "install" replacement free to be applied. -- Alvaro Herrera (<alvherre[@]dcc.uchile.cl>) You liked Linux a lot when he was just the gawky kid from down the block mowing your lawn or shoveling the snow. But now that he wants to date your daughter, you're not so sure he measures up. (Larry Greenemeier)
Neil Conway <neilc@samurai.com> writes:
> On Mon, 2005-01-17 at 18:43 -0500, Tom Lane wrote:
>> I have already
>> suggested to core that we should insist on 8.1 not requiring an initdb,
>> so as to ensure that people will migrate up to it easily from 8.0.
> So is it firm policy that changes that require a catversion update
> cannot be made during the 8.1 cycle?
Not yet --- I suggested it but didn't get any yeas or nays. I don't
feel this is solely core's decision anyway ... what do the assembled
hackers think?
> (Needless to say, it would be good to get this sorted out early on in
> the 8.1 development cycle, to avoid the need to revert patches at some
> point down the line. For those of us working on large projects that will
> definitely require an initdb, it would also be good to know -- as this
> policy will likely prevent that work from getting into 8.1)
Yes, it has to be decided one way or the other soon.
One way to have our cake and eat it too would be for someone to
resurrect pg_upgrade during this devel cycle. Anyone feel like
working on that?
regards, tom lane
On Tue, 2005-01-18 at 23:26 -0500, Tom Lane wrote: > Not yet --- I suggested it but didn't get any yeas or nays. I don't > feel this is solely core's decision anyway ... what do the assembled > hackers think? I'm not sure it's a great idea. I'm not aware of a recent example of short development cycles working well in this project. That isn't to say we *can't* do one effectively, just that history is not on our side (does anyone recall the plans to finish off Win32 in 7.5 and get it out the door quickly?) The primary justification I've heard for the no-initdb policy is that it would provide a smooth upgrade path for 8.0 users if/when the ARC patent is granted. I don't think this is the best way to deal with the ARC issue: it seems silly to handicap an entire development cycle because of one (potential) problem. Not to mention that it's not even certain whether an ARC replacement will be needed: we might be able to adapt the existing code to workaround the patent, the patent might not be granted, or IBM might grant us a license to use it. It's also worth emphasizing that this would be a rather severe limitation on what kind of new developments can go into 8.1. I think the proper fix for the ARC issue is an 8.0.x release with a new replacement policy. To avoid introducing instability into 8.0, we should obviously test the new buffer replacement policy *very* carefully. However, I think the ARC replacement should *not* be a fundamental change in behavior: the algorithm should still attempt to balance recency and frequency, to adjust dynamically to changes in workload, to avoid "sequential flooding", and to allow constant-time page replacement. Ideally the ARC replacement would do something similar to ARC but via a different means. If such a patch were developed, I don't think it would be a herculean task to include it in an 8.0.x release after a lot of careful testing and code review. -Neil
Neil Conway <neilc@samurai.com> writes:
> On Tue, 2005-01-18 at 23:26 -0500, Tom Lane wrote:
>> Not yet --- I suggested it but didn't get any yeas or nays. I don't
>> feel this is solely core's decision anyway ... what do the assembled
>> hackers think?
> I'm not aware of a recent example of short development cycles working
> well in this project.
Granted, but we haven't tried very hard either.
> I think the proper fix for the ARC issue is an 8.0.x release with a new
> replacement policy. To avoid introducing instability into 8.0, we should
> obviously test the new buffer replacement policy *very* carefully.
That testing isn't going to magically appear from somewhere. Unless the
proposed fix is only a very small variation on what we have (which seems
unlikely to get around the patent), I wouldn't have any confidence in it
until it's at least survived an 8.1 beta cycle. So I don't believe in
the concept of a near-term 8.0.x fix while 8.1 slides along on a slow
devel schedule.
What this really boils down to is whether we think we have
order-of-a-year before the patent is issued. I'm nervous about
assuming that. I'd like to have a plan that will produce a tested,
credible patch in less than six months.
regards, tom lane
> ... not even certain whether an ARC replacement will be needed: > we might be able to adapt the existing code to workaround the > patent, the patent might not be granted, or IBM might grant > us a license to use it. It's also worth emphasizing that this How about contacting IBM to see where they stand on the issue...? You never know,... We might get the licence and be able to put the dusussion to rest! ... John
On Wed, 2005-01-19 at 16:25 +1100, Neil Conway wrote: > On Tue, 2005-01-18 at 23:26 -0500, Tom Lane wrote: > > Not yet --- I suggested it but didn't get any yeas or nays. I don't > > feel this is solely core's decision anyway ... what do the assembled > > hackers think? > > I'm not sure it's a great idea. It's not, but may still be required. We should defer any changes for a month, just to see if its feasible to do that. > I think the proper fix for the ARC issue is an 8.0.x release with a new > replacement policy. To avoid introducing instability into 8.0, we should > obviously test the new buffer replacement policy *very* carefully. Agreed. I prefer a plan that, if required, back ports NewStrategy to 8.0.x than one that hobbles 8.1, just in case. > However, I think the ARC replacement should *not* be a fundamental > change in behavior: the algorithm should still attempt to balance > recency and frequency, to adjust dynamically to changes in workload, to > avoid "sequential flooding", and to allow constant-time page > replacement. Agreed: Those are the requirements. It must also scale better as well. All of which have sufficient prior art that they could never be seen to in-themselves form the basis of a patent. > If such a patch were developed, I don't > think it would be a herculean task to include it in an 8.0.x release > after a lot of careful testing and code review. Agreed. -- Best Regards, Simon Riggs
> > On Mon, 2005-01-17 at 18:43 -0500, Tom Lane wrote: > >> I have already > >> suggested to core that we should insist on 8.1 not requiring an > >> initdb, so as to ensure that people will migrate up to it > easily from 8.0. > > > So is it firm policy that changes that require a catversion update > > cannot be made during the 8.1 cycle? > > Not yet --- I suggested it but didn't get any yeas or nays. > I don't feel this is solely core's decision anyway ... what > do the assembled hackers think? An idea around this would be to plan never to release 8.1. Instead, direct HEAD towards 8.2 with a normal dev cycle (or rather, let's aim for a short one, but in reality short may not be all that short..). Then the eventual ARC replacment (assuming there is one) gets backpatched to the 8.1 branch which is basically only contains all patches from 8.0.x plus the ARC stuff. It's a bit more to fiddle around with, but it lets people continue working on features that requires initdb. Just a thought... //Magnus
> > There's a very recent paper at > > http://carmen.cs.uiuc.edu/~zchen9/paper/TPDS-final.ps on an alternative > > to ARC which claims superior performance ... > > From a quick glance, this doesn't look applicable. The authors are > discussing buffer replacement strategies for a multi-level cache > hierarchy (e.g. they would call the DBMS buffer cache "L1", and the Yes, it might not matter however. Another algorithm that was written by university folk (thus probably not patent prone) that looks promising is: http://www.cs.wm.edu/hpcs/WWW/HTML/publications/papers/TR-02-6.pdf http://parapet.ee.princeton.edu/~sigm2002/papers/p31-jiang.pdf (same, but better typeset) It even seems to slightly beat ARC according to the MQ paper. Andreas
Tom Lane wrote: > > What this really boils down to is whether we think we have > order-of-a-year before the patent is issued. I'm nervous about > assuming that. I'd like to have a plan that will produce a tested, > credible patch in less than six months. Why not having a beta on an 8.0.x version if ARC replacement has to be released shortly? Regards, Andreas
On Wed, 19 Jan 2005 10:53:14 +0100 "Magnus Hagander" <mha@sollentuna.net> wrote: > An idea around this would be to plan never to release 8.1. Instead, > direct HEAD towards 8.2 with a normal dev cycle (or rather, let's aim > for a short one, but in reality short may not be all that short..). > Then the eventual ARC replacment (assuming there is one) gets > backpatched to the 8.1 branch which is basically only contains all > patches from 8.0.x plus the ARC stuff. Personally I prefer the 8.0.1 route for two reasons. 1. We don't know when (or if) the patent will be granted. 8.0.1 fits in no matter what and it doesn't sound like we are going backwards. 2. From a marketing standpoint it is easier to sell our bosses/clients that 8.0.1 is exactly the same as they have running and tested but without a legal constraint than 8.1 which sounds more like a new version. -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > Neil Conway <neilc@samurai.com> writes: > > So is it firm policy that changes that require a catversion update > > cannot be made during the 8.1 cycle? > > Not yet --- I suggested it but didn't get any yeas or nays. I don't > feel this is solely core's decision anyway ... what do the assembled > hackers think? Don't know if I count, but I've noticed a number of things that people are working on that require initdb's and I think they'd be nice to allow in 8.1 unless the 8.1 cycle is *very* short. I'd also like to get group ownership & roles in soon, if possible (and if I find enough time to finish and properly test it). > One way to have our cake and eat it too would be for someone to > resurrect pg_upgrade during this devel cycle. Anyone feel like > working on that? Of course, this would be really nice too.. Stephen
On Jan 19, 2005, at 4:54 AM, Zeugswetter Andreas DAZ SD wrote: > Another algorithm that was written by > university folk (thus probably not patent prone) that looks promising > is: > http://www.cs.wm.edu/hpcs/WWW/HTML/publications/papers/TR-02-6.pdf > http://parapet.ee.princeton.edu/~sigm2002/papers/p31-jiang.pdf (same, > but better typeset) Do not assume that University algorithms are not patent protected. They definitely may be and I know they sometimes are. Princeton has an office dedicated to the issue: http://www.princeton.edu/patents/ -Travis
Tom Lane wrote: >Neil Conway <neilc@samurai.com> writes: > > >>So is it firm policy that changes that require a catversion update >>cannot be made during the 8.1 cycle? >> >> > >Not yet --- I suggested it but didn't get any yeas or nays. I don't >feel this is solely core's decision anyway ... what do the assembled >hackers think? > My personal goal for 8.1 is to get autovacuum integrated into the backend. The patch I submitted during the 8.0 dev cycle required a new system table for autovacuum data. Anyway we could get around that without bumping catversion? Perhaps the vacuum daemon could add the table if it's not found?
Ühel kenal päeval (esmaspäev, 17. jaanuar 2005, 23:22+0000), kirjutas Simon Riggs: > On Mon, 2005-01-17 at 14:02 -0800, Joshua D. Drake wrote: > > >IBM can NEVER sue customers for using infringing > > >code before first informing them of infringement and > > >giving reasonable time to upgrade to uninfringing > > >version. ... > It seems clear that anybody on 8.0.0ARC after the patent had been > granted could potentially be liable to pay damages. At best, the > community would need to do a "product recall" to ensure patents were not > infringed. > > So, it also seems clear that 8.0.x should eventually have a straight > upgrade path to a replacement, assuming the patent is granted. > > We should therefore plan to: > 1. improve/replace ARC for 8.1 "improved" ARC still needs licence from IBM if they get the patent and our "improved" one infringes any claims in it. Actually getting patents on all useful improvements on existing patent has been a known winning strategy in corporate patent hardball - you force the original patent holder to negotiate, as he's rendered unable to improve his design without infringing your patents. IIRC some early electronic consumer devices were wrangled out of single company control that way. We could consider donating our improvements to some free patent foundation to be patented for this kind of action plan. -- Hannu Krosing <hannu@tm.ee>
Ühel kenal päeval (esmaspäev, 17. jaanuar 2005, 11:57-0800), kirjutas Joshua D. Drake: > >However, I don't want to be beholden to IBM indefinitely --- in five > >years their corporate strategy might change. I think that a reasonable > >response to this is to plan to get rid of ARC, or at least modify the > >code enough to avoid the patent, in time for 8.1. (It's entirely likely > >that that will happen before the patent issues, anyway.) > > > > regards, tom lane > > > > > IBM makes 20% of their money from licensing patents. OTOH they make >80% of their goodwill in OS community out of being nice to opensource projects. Or at least avoiding being seen as downright unfair. So I expect at least some civility from them if and when thei get the patent. I'm also suspect that PG "possibly infringes" on enough already granted patents (some likely owned by IBM) to at least get it into as much trouble as SCO has caused to IBM. The reason we havent seen any IBM lawyers is that demanding royalties from "PostgreSQL Global Development Group" would be bad publicity, not thet they could not have done it if PG were a product of "Mom&Pop Software Startup Co". What comes to companies that take PG source, rebrand it and sell as closed-source product, then they have several options :1) just wait and hope that the public version evolves past ARC patent before the patent is granted.2) licence the patent from IBM, if and when it is granted3) rewrite the part that usesARC (and if they're really paranoid, then parts bordering it) in their commercial version.4) hire some core developersto do 3) in the public version -- Hannu Krosing <hannu@tm.ee>
Ühel kenal päeval (esmaspäev, 17. jaanuar 2005, 14:48-0500), kirjutas Tom Lane: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Andrew Sullivan wrote: > >> What will you do if the patent is granted, 8.0 is out there with the > >> offending code, and you get a cease-and-desist letter from IBM > >> demanding the removal of all offending code from the Net? > > > We can modify the code slightly to hopefully avoid the patent. With the > > US granting patents on even obvious ideas, I would think that most large > > software projects, including commercial ones, already have tons of > > patent violations in their code. Does anyone think otherwise? > > I think there is zero probability of being sued by IBM in the near > future. They would instantly destroy the credibility and good > relationships they've worked so hard to build up with the entire > open source community. Agreed > However, I don't want to be beholden to IBM indefinitely --- in five > years their corporate strategy might change. I think that a reasonable > response to this is to plan to get rid of ARC, or at least modify the > code enough to avoid the patent, in time for 8.1. (It's entirely likely > that that will happen before the patent issues, anyway.) I'd rather like a solution where the cache replacement policy has clean- enough interface to have many competing algorithms/implementations, probably even selactable at startup (or even runtime ;). Firstly, I'm sure that there is no single best strategy (even ARC) for all kinds of workloads - think OLTP v.s.OLAP. Secondly, some people might want to use ARC even if and when IBM gets the patent, even badly enough to license it from IBM. (We are not obliged to design an interfaces that prevents usage of patented stuff as this is generally impossible.) Thirdly, having it as a well-defined component/API might encourage more research on different algorithms - see how many schedulers linux 2.6 has, both for processes and disk io. -- Hannu Krosing <hannu@tm.ee>
Ühel kenal päeval (kolmapäev, 19. jaanuar 2005, 00:39-0500), kirjutas Tom Lane: > What this really boils down to is whether we think we have > order-of-a-year before the patent is issued. I'm nervous about > assuming that. I'd like to have a plan that will produce a tested, > credible patch in less than six months. Can't this thing be abstracted out like so many other things are (types, functions, pl-s) or should be/were once (storage managers) ? Like different scheduling algorithms in the linux kernel ? What makes this inherently so difficult to do ? Is it just testing or something for fundamental? Most likely also the gathering of information needed to decide on replacement policy. If just testing, we could move fast to supplying two algos LRU/ARC , selectable at startup. This has extra benefit of allowing easily testing other algorithms - I guess that for unpredictable workloads a random policy in 80% tail of LRU cache should not do too badly, probably better than 7.x's seqscan polluteable LRU ;) -- Hannu Krosing <hannu@tm.ee>
Simon Riggs wrote: >>However, I think the ARC replacement should *not* be a fundamental >>change in behavior: the algorithm should still attempt to balance >>recency and frequency, to adjust dynamically to changes in workload, to >>avoid "sequential flooding", and to allow constant-time page >>replacement. > > Agreed: Those are the requirements. It must also scale better as well. On thinking about this more, I'm not sure these are the right goals for an 8.0.x replacement algorithm. For 8.1 we should definitely Do The Right Thing and develop a complete ARC replacement. For 8.0.x, I wonder if it would be better to just replace ARC with LRU. The primary advantage to doing this is LRU's simplicity -- if we're concerned about introducing regressions in stability into 8.0, this is likely the best way to reduce the chance of that happening. Furthermore, LRU's behavior with PostgreSQL is well-known and has been extensively tested. A complex ARC replacement would receive even less testing than ARC itself has received -- which isn't a whole lot, in comparison with LRU. Of course, the downside is that we lose the benefits of ARC or an ARC-like algorithm in 8.0. That would be unfortunate, but I don't think it is a catastrophe. The other bufmgr-related changes (vacuum hints, bgwriter and vacuum delay) should ensure that VACUUM still has a much reduced impact on system performance. Sequential scans will still flood the cache, but I don't view that as an enormous problem. In other words, I think a more intelligent replacement policy would be nice to have, but at this point in the 8.0 development cycle we should go with the simplest solution that we know is likely to work -- namely, LRU. -Neil
On Thu, 2005-01-20 at 23:17 +1100, Neil Conway wrote: > Simon Riggs wrote: > >>However, I think the ARC replacement should *not* be a fundamental > >>change in behavior: the algorithm should still attempt to balance > >>recency and frequency, to adjust dynamically to changes in workload, to > >>avoid "sequential flooding", and to allow constant-time page > >>replacement. > > > > Agreed: Those are the requirements. It must also scale better as well. > > For 8.1 we should definitely Do The > Right Thing and develop a complete ARC replacement. Agreed. That would be my focus. > For 8.0.x, I wonder > if it would be better to just replace ARC with LRU. The primary > advantage to doing this is LRU's simplicity -- if we're concerned about > introducing regressions in stability into 8.0, this is likely the best > way to reduce the chance of that happening. Furthermore, LRU's behavior > with PostgreSQL is well-known and has been extensively tested. A complex > ARC replacement would receive even less testing than ARC itself has > received -- which isn't a whole lot, in comparison with LRU. > > Of course, the downside is that we lose the benefits of ARC or an > ARC-like algorithm in 8.0. That would be unfortunate, but I don't think > it is a catastrophe. The other bufmgr-related changes (vacuum hints, > bgwriter and vacuum delay) should ensure that VACUUM still has a much > reduced impact on system performance. Sequential scans will still flood > the cache, but I don't view that as an enormous problem. In other words, > I think a more intelligent replacement policy would be nice to have, but > at this point in the 8.0 development cycle we should go with the > simplest solution that we know is likely to work -- namely, LRU. Agree with everything apart from the idea that seq scan flooding isn't an issue. I definitely think it is. -- Best Regards, Simon Riggs
Simon Riggs wrote: > On Thu, 2005-01-20 at 23:17 +1100, Neil Conway wrote: > (snippage) >>For 8.0.x, I wonder >>if it would be better to just replace ARC with LRU. >> >> Sequential scans will still flood >>the cache, but I don't view that as an enormous problem. > > Agree with everything apart from the idea that seq scan flooding isn't > an issue. I definitely think it is. > Is it feasible to consider LRU + a free-behind or seqscan hint type of replacement policy? regards Mark
On Fri, 2005-01-21 at 01:26 +0000, Simon Riggs wrote: > Agree with everything apart from the idea that seq scan flooding isn't > an issue. I definitely think it is. I agree it's an issue, I just don't think it's an issue of sufficient importance that it needs to be solved in the 8.0.x timeframe. In any case, I'll take a look at developing a patch to replace ARC with LRU. If it's possible to solve sequential flooding (e.g. via some kind of hint-based approach) without too much complexity, we could add that to the patch down the line. -Neil
How about LRU + "learning" --> something like the optimizer? It might be nice also to be able to pin things in memory. -----Original Message----- From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Mark Kirkwood Sent: Thursday, January 20, 2005 6:55 PM To: Simon Riggs Cc: Neil Conway; Tom Lane; Joshua D. Drake; Jeff Davis; pgsql-hackers Subject: Re: [HACKERS] ARC patent Simon Riggs wrote: > On Thu, 2005-01-20 at 23:17 +1100, Neil Conway wrote: > (snippage) >>For 8.0.x, I wonder >>if it would be better to just replace ARC with LRU. >> >> Sequential scans will still flood >>the cache, but I don't view that as an enormous problem. > > Agree with everything apart from the idea that seq scan flooding isn't > an issue. I definitely think it is. > Is it feasible to consider LRU + a free-behind or seqscan hint type of replacement policy? regards Mark ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Ühel kenal päeval (neljapäev, 20. jaanuar 2005, 23:17+1100), kirjutas Neil Conway: > Simon Riggs wrote: > >>However, I think the ARC replacement should *not* be a fundamental > >>change in behavior: the algorithm should still attempt to balance > >>recency and frequency, to adjust dynamically to changes in workload, to > >>avoid "sequential flooding", and to allow constant-time page > >>replacement. > > > > Agreed: Those are the requirements. It must also scale better as well. > > On thinking about this more, I'm not sure these are the right goals for > an 8.0.x replacement algorithm. For 8.1 we should definitely Do The > Right Thing and develop a complete ARC replacement. For 8.0.x, I wonder > if it would be better to just replace ARC with LRU. The primary > advantage to doing this is LRU's simplicity -- if we're concerned about > introducing regressions in stability into 8.0, this is likely the best > way to reduce the chance of that happening. Furthermore, LRU's behavior > with PostgreSQL is well-known and has been extensively tested. If we are going the "simple" way, i have two simple suggestions: 1) We should do something about seqscans polluting LRU - perhaps insert pages brought into memory by seqscan near the end of LRU list. Or just swich off postgresqls internal cachin alltogether when doing seqscans and rely on underlying systems caching entirely (as we cant switch it off anyway) 2) Another simple, but nondeterministic, hack would be using randomness, i.e. 2.1) select a random buffer in LR side half (or 30% or 60%) of for replacement. 2.2) dont last accessed pages to top of LRU list immediately, just push them uphill some amount, either random, or perhaps 1/2 the way to top at each access. This should be quite qood strategy for avoiding disastrous failings on specific pathological workloads, at the cost of less than optimal behaviour in easily analysed standard cases. > Of course, the downside is that we lose the benefits of ARC or an > ARC-like algorithm in 8.0. That would be unfortunate, but I don't think > it is a catastrophe. The only case this would be a catastrophe, is for production OLTP workloads that did fine with ARC but get overloaded when using LRU. > The other bufmgr-related changes (vacuum hints, > bgwriter and vacuum delay) should ensure that VACUUM still has a much > reduced impact on system performance. Sequential scans will still flood > the cache, but I don't view that as an enormous problem. Has anobody some insight, how does linux kernel level disk cache solve this "sequencial scan/read pollutes cache" problem ? -- Hannu Krosing <hannu@tm.ee>
On Fri, 21 Jan 2005 02:31:40 +0200, Hannu Krosing <hannu@tm.ee> wrote: >2) Another simple, but nondeterministic, hack would be using randomness, >i.e. > > 2.1) select a random buffer in LR side half (or 30% or 60%) of > for replacement. > > 2.2) dont last accessed pages to top of LRU list immediately, > just push them uphill some amount, either random, or > perhaps 1/2 the way to top at each access. Sounds good, but how do find the middle of a linked list? Or the other way round: Given a list element, how do you find out its position in a linked list? So the only approach that is easily implementable is 2.3) If a sequential scan hint flag is set, put the buffer into the free list at a random position. ServusManfred
Tom Lane wrote: > Neil Conway <neilc@samurai.com> writes: > > On Mon, 2005-01-17 at 18:43 -0500, Tom Lane wrote: > >> I have already > >> suggested to core that we should insist on 8.1 not requiring an initdb, > >> so as to ensure that people will migrate up to it easily from 8.0. > > > So is it firm policy that changes that require a catversion update > > cannot be made during the 8.1 cycle? > > Not yet --- I suggested it but didn't get any yeas or nays. I don't > feel this is solely core's decision anyway ... what do the assembled > hackers think? I am not in favor of adjusting the 8.1 release based solely on this patent issue. I think the probability of the patent being accepted and enforced against anyone using PostgreSQL to be very unlikely. I would also like to come up with a procedure that would scale to any other patent problems we might have. What if someone finds another patent problem during 8.1 beta? Do we shorten the 8.2 development cycle too? What I would like to do is to pledge that we will put out an 8.0.X to address any patent conflict experienced by our users. This would include ARC or anything else. This way we don't focus just on ARC but have a plan for any patent issues that appear, and we don't have to adjust our development cycle until an actual threat appears. One advantage we have is that we can easily adjust our code to work around patented code by just installing a new binary. (Patents that affect our storage format would be more difficult. A fix would have to perhaps rewrite the on-disk data.) One problem in working around the GIF format patent is that you had to create a file that was readable by many of the existing GIF readers. With PostgreSQL, only we read our own data files so we can more easily make adjustments to avoid patents. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Folks, Asking this again as it seems my question got lost, or at least unanswered. Why not just contact IBM, and get their opinion? As I said before, we might just get a promise of a full licence for if/when the patent is granted. ... John
John Hansen wrote: >Folks, > >Asking this again as it seems my question got lost, or at least unanswered. > >Why not just contact IBM, and get their opinion? > > 1. We don't have attorneys to do so. 2. The PostgreSQL community is not a legal entity it can license to. 3. It would take weeks if not months to get an answer 4. The patent isn't issed yet. Sincerely, Joshua D. Drake >As I said before, we might just get a promise of a full licence for if/when the patent is granted. > >... John > >---------------------------(end of broadcast)--------------------------- >TIP 4: Don't 'kill -9' the postmaster > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment
We could still get their opinion. I have a couple aquaintances at IBM that I can try to contact about it. Rather than assume what IBM will do, why not just ask them? If they don't respond, they don't respond. If they do respond, it's better than us guessing. Yes, it's only going to matter if the patent is issued, but why not make an effort to get some info from them? Joshua D. Drake wrote: > John Hansen wrote: > >> Folks, >> >> Asking this again as it seems my question got lost, or at least >> unanswered. >> >> Why not just contact IBM, and get their opinion? >> >> > 1. We don't have attorneys to do so. > 2. The PostgreSQL community is not a legal entity it can license to. > 3. It would take weeks if not months to get an answer > 4. The patent isn't issed yet. > > Sincerely, > > Joshua D. Drake > > >> As I said before, we might just get a promise of a full licence for >> if/when the patent is granted. >> >> ... John >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 4: Don't 'kill -9' the postmaster >> >> > > >---------------------------(end of broadcast)--------------------------- >TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > >
Jonah H. Harris wrote: > We could still get their opinion. > > I have a couple aquaintances at IBM that I can try to contact about > it. Rather than assume what IBM will do, why not just ask them? If > they don't respond, they don't respond. If they do respond, it's > better than us guessing. > > Yes, it's only going to matter if the patent is issued, but why not > make an effort to get some info from them? Well I believe it is Core's decision to make. Sincerely, Joshua D. Drkae > > > Joshua D. Drake wrote: > >> John Hansen wrote: >> >>> Folks, >>> >>> Asking this again as it seems my question got lost, or at least >>> unanswered. >>> >>> Why not just contact IBM, and get their opinion? >>> >>> >> 1. We don't have attorneys to do so. >> 2. The PostgreSQL community is not a legal entity it can license to. >> 3. It would take weeks if not months to get an answer >> 4. The patent isn't issed yet. >> >> Sincerely, >> >> Joshua D. Drake >> >> >>> As I said before, we might just get a promise of a full licence for >>> if/when the patent is granted. >>> >>> ... John >>> >>> ---------------------------(end of >>> broadcast)--------------------------- >>> TIP 4: Don't 'kill -9' the postmaster >>> >>> >> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 2: you can get off all lists at once with the unregister command >> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >> >> > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment
"Joshua D. Drake" <jd@commandprompt.com> writes: > John Hansen wrote: > > >Folks, > > > >Asking this again as it seems my question got lost, or at least unanswered. > > > >Why not just contact IBM, and get their opinion? > > > 1. We don't have attorneys to do so. > 2. The PostgreSQL community is not a legal entity it can license to. > 3. It would take weeks if not months to get an answer > 4. The patent isn't issed yet. Don't forget: 5. They would also have to license everyone else who might want to repackage or use Postgres. Such as Fujitsu, a big competitorof theirs. -- greg
John Hansen wrote: > Folks, > > Asking this again as it seems my question got lost, or at least > unanswered. > > Why not just contact IBM, and get their opinion? > > As I said before, we might just get a promise of a full licence for > if/when the patent is granted. I doubt we can get a license that would cover companies that package PostgreSQL. While I don't think they would attack them I also don't think they can give a blanket approval in writing. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
"Jonah H. Harris" <jharris@tvi.edu> writes:
> I have a couple aquaintances at IBM that I can try to contact about it.
> Rather than assume what IBM will do, why not just ask them? If they
> don't respond, they don't respond. If they do respond, it's better than
> us guessing.
People seem to be assuming that asking IBM is a zero-risk thing. It's not.
If they are forced to deal with the issue, they might well feel that
they have to take action that we'd not like; whereas as long as it's not
officially in front of them, they can pretend to ignore us.
This is not a whole lot different from our situation today: now that the
issue of the pending patent is officially in front of us, we have to
deal with it.
regards, tom lane
Ühel kenal päeval (reede, 21. jaanuar 2005, 15:42+0100), kirjutas Manfred Koizar: > On Fri, 21 Jan 2005 02:31:40 +0200, Hannu Krosing <hannu@tm.ee> wrote: > >2) Another simple, but nondeterministic, hack would be using randomness, > >i.e. > > > > 2.1) select a random buffer in LR side half (or 30% or 60%) of > > for replacement. > > > > 2.2) dont last accessed pages to top of LRU list immediately, > > just push them uphill some amount, either random, or > > perhaps 1/2 the way to top at each access. > > Sounds good, but how do find the middle of a linked list? Ok, we are back to using 2 lists - one for 1st and one for 2nd half and spill the tail of 1st list over to 2nd when it growns. But the fundamental fact of using two lists seems to be the first claim in IBM's patent ;( Not that I think that using 2 lists to know where the midpoint of linked list is is patentable, but if we deside start acting scared of all things in patent applications then we should be aware of it. > Or the other > way round: Given a list element, how do you find out its position in a > linked list? To know an *approximate* position, we could 1) have an independent periodic process that just scans the list and records the position 2) each node inserted at head or tail is recorded true position 3) each node inserted in middle is given the same position as its predecessor. This would not be too expensive, but OTOH I can't think of a way to use this onfo right now. An additional array of node pointers in list order populated in step 1) could have more use. > So the only approach that is easily implementable is > > 2.3) If a sequential scan hint flag is set, put the buffer into the > free list at a random position. -- Hannu Krosing <hannu@tm.ee>
On Fri, Jan 21, 2005 at 03:42:38PM +0100, Manfred Koizar wrote: > On Fri, 21 Jan 2005 02:31:40 +0200, Hannu Krosing <hannu@tm.ee> wrote: > >2) Another simple, but nondeterministic, hack would be using randomness, > >i.e. > > > > 2.1) select a random buffer in LR side half (or 30% or 60%) of > > for replacement. > > > > 2.2) dont last accessed pages to top of LRU list immediately, > > just push them uphill some amount, either random, or > > perhaps 1/2 the way to top at each access. > > Sounds good, but how do find the middle of a linked list? Or the other > way round: Given a list element, how do you find out its position in a > linked list? So the only approach that is easily implementable is > > 2.3) If a sequential scan hint flag is set, put the buffer into the > free list at a random position. > If we use the clock algorithm as an approximation to LRU, we can avoid a lot of the MRU/LRU churn. Then the seq. scan hint could just be another type of clock bit. Ken
> -----Original Message----- > From: Marian POPESCU [mailto:softexpert@libertysurf.fr] > Sent: Friday, April 01, 2005 8:06 AM > To: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] ARC patent > > >>>Neil Conway <neilc@samurai.com> writes: > >>> > >>> > >>>>FYI, IBM has applied for a patent on ARC (AFAICS the > >>>>patent application is still pending, although the USPTO > >>>>site is a little hard to grok): > >>> > >>>Ugh. We could hope that the patent wouldn't be granted, > >>>but I think it unlikely, unless Jan is aware of prior art > >>>(like a publication predating the filing date). I fear we'll > >>>have to change or remove that code. Why not just ask IBM for a free license first? After all, they put 1,000+ patents in the public domain or something, didn't they? I realize that they might use this technology in DB2, and don't want to encourage competitors. But IBM seems a lot more friendly to OSS than most companies, and it doesn't seem like it would hurt to ask. At the worst they say "no" and you just proceed as you would have originally. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129
Dave Held wrote: > > -----Original Message----- > > From: Marian POPESCU [mailto:softexpert@libertysurf.fr] > > Sent: Friday, April 01, 2005 8:06 AM > > To: pgsql-hackers@postgresql.org > > Subject: Re: [HACKERS] ARC patent > > > > >>>Neil Conway <neilc@samurai.com> writes: > > >>> > > >>> > > >>>>FYI, IBM has applied for a patent on ARC (AFAICS the > > >>>>patent application is still pending, although the USPTO > > >>>>site is a little hard to grok): > > >>> > > >>>Ugh. We could hope that the patent wouldn't be granted, > > >>>but I think it unlikely, unless Jan is aware of prior art > > >>>(like a publication predating the filing date). I fear we'll > > >>>have to change or remove that code. > > Why not just ask IBM for a free license first? After all, they put > 1,000+ patents in the public domain or something, didn't they? I > realize that they might use this technology in DB2, and don't want > to encourage competitors. But IBM seems a lot more friendly to OSS > than most companies, and it doesn't seem like it would hurt to ask. > At the worst they say "no" and you just proceed as you would have > originally. The problem is that they would have to license all commercial, closed-source distributions of PostgreSQL too, and I doubt they would do that. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: Friday, April 01, 2005 10:23 AM > To: Dave Held > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] ARC patent > > > Dave Held wrote: > > > -----Original Message----- > > > From: Marian POPESCU [mailto:softexpert@libertysurf.fr] > > > Sent: Friday, April 01, 2005 8:06 AM > > > To: pgsql-hackers@postgresql.org > > > Subject: Re: [HACKERS] ARC patent > > > > > > >>>Neil Conway <neilc@samurai.com> writes: > > > >>> > > > >>> > > > >>>>FYI, IBM has applied for a patent on ARC (AFAICS the > > > >>>>patent application is still pending, although the USPTO > > > >>>>site is a little hard to grok): > > > >>> > > > >>>Ugh. We could hope that the patent wouldn't be granted, > > > >>>but I think it unlikely, unless Jan is aware of prior art > > > >>>(like a publication predating the filing date). I fear we'll > > > >>>have to change or remove that code. > > > > Why not just ask IBM for a free license first? After all, they put > > 1,000+ patents in the public domain or something, didn't they? I > > realize that they might use this technology in DB2, and don't want > > to encourage competitors. But IBM seems a lot more friendly to OSS > > than most companies, and it doesn't seem like it would hurt to ask. > > At the worst they say "no" and you just proceed as you would have > > originally. > > The problem is that they would have to license all commercial, > closed-source distributions of PostgreSQL too, and I doubt > they would do > that. Why would they have to do that? Why couldn't they just give a license for OSS distributions of PostgreSQL, and make commercial distributions obtain their own license for the ARC code? Doesn't IBM hire lawyers exactly for the purpose of writing complicated legal documents of this nature? ;> Or is it that the Postgres team wouldn't use an algorithm that wasn't freely available to everyone? __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129
Dave Held wrote: > Why would they have to do that? Why couldn't they just give a license > for OSS distributions of PostgreSQL, and make commercial distributions > obtain their own license for the ARC code? Doesn't IBM hire lawyers > exactly for the purpose of writing complicated legal documents of this > nature? ;> Or is it that the Postgres team wouldn't use an algorithm > that wasn't freely available to everyone? Right. We wouldn't be fully BSD licensed if there was a patent restriction on making commercial versions of our software. And, if you don't think commercial versions are important, consider all the commercial developer help we are getting because our license is so business-friendly. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Dave Held said: >> -----Original Message----- >> From: Marian POPESCU [mailto:softexpert@libertysurf.fr] >> Sent: Friday, April 01, 2005 8:06 AM >> To: pgsql-hackers@postgresql.org >> Subject: Re: [HACKERS] ARC patent >> >> >>>Neil Conway <neilc@samurai.com> writes: >> >>> >> >>> >> >>>>FYI, IBM has applied for a patent on ARC (AFAICS the >> >>>>patent application is still pending, although the USPTO >> >>>>site is a little hard to grok): >> >>> >> >>>Ugh. We could hope that the patent wouldn't be granted, >> >>>but I think it unlikely, unless Jan is aware of prior art >> >>>(like a publication predating the filing date). I fear we'll have >> >>>to change or remove that code. > > Why not just ask IBM for a free license first? After all, they put > 1,000+ patents in the public domain or something, didn't they? I > realize that they might use this technology in DB2, and don't want to > encourage competitors. But IBM seems a lot more friendly to OSS than > most companies, and it doesn't seem like it would hurt to ask. At the > worst they say "no" and you just proceed as you would have > originally. > Please read the record of the very recent discussion on this before rehashing it. I'm sure you can find it on Google. cheers andrew
>> -----Original Message----- >> From: Marian POPESCU [mailto:softexpert@libertysurf.fr] >> Sent: Friday, April 01, 2005 8:06 AM >> To: pgsql-hackers@postgresql.org >> Subject: Re: [HACKERS] ARC patent >> >> >>>Neil Conway <neilc@samurai.com> writes: >> >>> >> >>> >> >>>>FYI, IBM has applied for a patent on ARC (AFAICS the >> >>>>patent application is still pending, although the USPTO >> >>>>site is a little hard to grok): >> >>> >> >>>Ugh. We could hope that the patent wouldn't be granted, >> >>>but I think it unlikely, unless Jan is aware of prior art >> >>>(like a publication predating the filing date). I fear we'll >> >>>have to change or remove that code. > > Why not just ask IBM for a free license first? After all, they put > 1,000+ patents in the public domain or something, didn't they? Did you ever get the feeling you've seen or done something before? It's like dejavu all over again. :-) It is april 1st, after all.