subject:"\[HACKERS\] ARC patent"

Ühel kenal päeval (esmaspäev, 17. jaanuar 2005, 23:22+), 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 [EMAIL PROTECTED]

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] ARC patent

Ü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 [EMAIL PROTECTED]

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

Re: [HACKERS] ARC patent

Ü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 MomPop
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 granted
 3) rewrite the part that uses ARC (and if they're really paranoid, 
then parts bordering it) in their commercial version.
 4) hire some core developers to do 3) in the public version

-- 
Hannu Krosing [EMAIL PROTECTED]


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] ARC patent

Ü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 [EMAIL PROTECTED]

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] ARC patent

2005-01-20 Thread 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. 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
---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] ARC patent

2005-01-20 Thread Simon Riggs

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


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] ARC patent

2005-01-20 Thread Mark Kirkwood

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

Re: [HACKERS] ARC patent

2005-01-20 Thread Neil Conway

On Fri, 2005-01-21 at 01:26 +, 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



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

Re: [HACKERS] ARC patent

2005-01-20 Thread Dann Corbit

How about LRU + learning -- something like the optimizer?

It might be nice also to be able to pin things in memory.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] ARC patent

2005-01-19 Thread Simon Riggs

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


---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] ARC patent

2005-01-19 Thread Magnus Hagander

  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

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] ARC patent

2005-01-19 Thread Zeugswetter Andreas DAZ SD


  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

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] ARC patent

2005-01-19 Thread Andreas Pflug

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

Re: [HACKERS] ARC patent

2005-01-19 Thread D'Arcy J.M. Cain

On Wed, 19 Jan 2005 10:53:14 +0100
Magnus Hagander [EMAIL PROTECTED] 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.

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] ARC patent

2005-01-19 Thread Stephen Frost

* Tom Lane ([EMAIL PROTECTED]) wrote:
 Neil Conway [EMAIL PROTECTED] 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


signature.asc
Description: Digital signature

Re: [HACKERS] ARC patent

2005-01-19 Thread Travis P

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
---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] ARC patent

2005-01-19 Thread Matthew T. O'Connor

Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] 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?



---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] ARC patent

2005-01-18 Thread Hans-Jürgen Schönig

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
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] ARC patent

2005-01-18 Thread jearl

Andrew Dunstan [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] ARC patent

2005-01-18 Thread Neil Conway

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


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] ARC patent

2005-01-18 Thread Neil Conway

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



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

Re: [HACKERS] ARC patent

2005-01-18 Thread Alvaro Herrera

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 ([EMAIL PROTECTED])
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)

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] ARC patent

2005-01-18 Thread Tom Lane

Neil Conway [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] ARC patent

2005-01-18 Thread Neil Conway

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



---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] ARC patent

2005-01-18 Thread Tom Lane

Neil Conway [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] ARC patent

2005-01-18 Thread John Hansen

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

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] ARC patent

2005-01-17 Thread John Hansen

  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=PTO1Sect2=HITOFFd=PG01p=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmlr=1f=Gl=50s1=%2220040098541%22.PGNR.OS=DN/20040098541RS=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

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] ARC patent

John Hansen [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] ARC patent

2005-01-17 Thread Simon Riggs

On Mon, 2005-01-17 at 01:15 -0500, Tom Lane wrote:
 Neil Conway [EMAIL PROTECTED] 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):
 
  http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PG01p=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmlr=1f=Gl=50s1=%2220040098541%22.PGNR.OS=DN/20040098541RS=DN/20040098541

On Mon, 2005-01-17 at 01:15 -0500, Tom Lane wrote:
 I fear we'll have to change or remove
 that code.

At very least, ARC should not be further mentioned in any press release
or beta history files until we resolve where we are. There'll be less
need for a retraction if the buffer strategy is not publicised.

The code separation of bufmgr.c and freelist.c means that changes can be
done later without too much of a problem. Any required changes can be
made under the covers without external recall-notices or such.

Well, considering the BufMgrLock problems, it was likely that some
changes would need to be be made to that algorithm anyway. 

ARC may be optimal in lab tests, but I'm beginning to think that it's
not optimal in multi-processing environments. It also takes no direct
account of the workload it is being asked to support, so ISTM that we
should be able to use workload hints, along the lines of
StrategyHintVacuum, to get a more responsive algorithm suited
specifically to PostgreSQL - which would be harder to claim rights on.

-- 
Best Regards, Simon Riggs


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] ARC patent

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  | [EMAIL PROTECTED]
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] ARC patent

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, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] ARC patent


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 - [EMAIL PROTECTED] - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
begin:vcard
fn:Joshua Drake
n:Drake;Joshua
org:Command Prompt, Inc.
adr:;;PO Box 215 ;Cascade Locks;OR;97014;US
email;internet:[EMAIL PROTECTED]
title:Consultant
tel;work:503-667-4564
tel;fax:503-210-0334
x-mozilla-html:FALSE
url:http://www.commandprompt.com
version:2.1
end:vcard


---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] ARC patent

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  | [EMAIL PROTECTED]
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

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

Re: [HACKERS] ARC patent

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

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] ARC patent

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, Pennsylvania 19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] ARC patent


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 - [EMAIL PROTECTED] - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
begin:vcard
fn:Joshua Drake
n:Drake;Joshua
org:Command Prompt, Inc.
adr:;;PO Box 215 ;Cascade Locks;OR;97014;US
email;internet:[EMAIL PROTECTED]
title:Consultant
tel;work:503-667-4564
tel;fax:503-210-0334
x-mozilla-html:FALSE
url:http://www.commandprompt.com
version:2.1
end:vcard


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] ARC patent

2005-01-17 Thread Jan Wieck

On 1/17/2005 1:15 AM, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] 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):

http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PG01p=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmlr=1f=Gl=50s1=%2220040098541%22.PGNR.OS=DN/20040098541RS=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.

If we need a different cache algorithm again, we might want to yank out 
the ARC part right away now and work on another one for 8.1.

Jan
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.  #
#== [EMAIL PROTECTED] #
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] ARC patent

Andrew Sullivan [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] ARC patent

Tom Lane wrote:
 Andrew Sullivan [EMAIL PROTECTED] 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, Pennsylvania 19073

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

Re: [HACKERS] ARC patent

Jan Wieck wrote:
 On 1/17/2005 1:15 AM, Tom Lane wrote:
  Neil Conway [EMAIL PROTECTED] 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):
  
  http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PG01p=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmlr=1f=Gl=50s1=%2220040098541%22.PGNR.OS=DN/20040098541RS=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.

Oh, OK.  Good news!

 I am seriously concerned about this and think we should not knowingly 
 release code that is possibly infringing a patent.
 
 If we need a different cache algorithm again, we might want to yank out 
 the ARC part right away now and work on another one for 8.1.

If you want to poke around for 2 hours, I bet you wil find more patent
infringements.  And not looking doesn't protect you from patent
violations.  What is the point of removing this one.  Just because Neil
did some legwork.  Anyone could do some legwork and find some in any
software, I bet.

-- 
  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, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] ARC patent


If you want to poke around for 2 hours, I bet you wil find more patent
infringements.  And not looking doesn't protect you from patent
violations.  What is the point of removing this one.  Just because Neil
did some legwork.  Anyone could do some legwork and find some in any
software, I bet.
 

Well from one perspective... Digging for patent infringement
is expensive just look at the SCO suit. However, this is a
public list.
We have just admitted that we knowingly may infringe upon
an IBM patent. That really is a different thing than,
We have some really smart people that came up with something,
like this other technology.
The reality I would bet is that IBM could give a flying roosters
butt whether or not PostgreSQL infringes on their patents. However
they will care very much, if Fujitsu or SRA does and we (the
community) may have insured that.
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 - [EMAIL PROTECTED] - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
begin:vcard
fn:Joshua Drake
n:Drake;Joshua
org:Command Prompt, Inc.
adr:;;PO Box 215 ;Cascade Locks;OR;97014;US
email;internet:[EMAIL PROTECTED]
title:Consultant
tel;work:503-667-4564
tel;fax:503-210-0334
x-mozilla-html:FALSE
url:http://www.commandprompt.com
version:2.1
end:vcard


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] ARC patent

2005-01-17 Thread Andrew Dunstan


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
---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] ARC patent

On Mon, Jan 17, 2005 at 02:58:33PM -0500, Tom Lane wrote:
 Andrew Sullivan [EMAIL PROTECTED] 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  | [EMAIL PROTECTED]
When my information changes, I alter my conclusions.  What do you do sir?
--attr. John Maynard Keynes

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] ARC patent

Andrew Dunstan [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] ARC patent

2005-01-17 Thread Jeff

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 [EMAIL PROTECTED]
http://www.jefftrout.com/
http://www.stuarthamm.net/
---(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

Re: [HACKERS] ARC patent

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  | [EMAIL PROTECTED]
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

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

Re: [HACKERS] ARC patent

2005-01-17 Thread Jeff Davis


 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



---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] ARC patent


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 [EMAIL PROTECTED]
 


--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
begin:vcard
fn:Joshua Drake
n:Drake;Joshua
org:Command Prompt, Inc.
adr:;;PO Box 215 ;Cascade Locks;OR;97014;US
email;internet:[EMAIL PROTECTED]
title:Consultant
tel;work:503-667-4564
tel;fax:503-210-0334
x-mozilla-html:FALSE
url:http://www.commandprompt.com
version:2.1
end:vcard


---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] ARC patent

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, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] ARC patent

2005-01-17 Thread Zeugswetter Andreas DAZ SD


  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=PTO1Sect2=HITOFFd=PG01p=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmlr=1f=Gl=50s1=%2220040098541%22.PGNR.OS=DN/20040098541RS=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

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] ARC patent

Joshua D. Drake [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] ARC patent

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=PTO1Sect2=HITOFFd=PG01p=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmlr=1f=Gl=50s1=%2220040098541%22.PGNR.OS=DN/20040098541RS=DN/20040098541

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, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] ARC patent

2005-01-17 Thread John Hansen

  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

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

Re: [HACKERS] ARC patent

2005-01-17 Thread Jeff Davis


 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


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] ARC patent

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  | [EMAIL PROTECTED]
Information security isn't a technological problem.  It's an economics
problem.
--Bruce Schneier

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] ARC patent

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, Pennsylvania 19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] ARC patent

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

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] ARC patent

2005-01-17 Thread Marc G. Fournier

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: [EMAIL PROTECTED]   Yahoo!: yscrappy  ICQ: 7615664
---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org

Re: [HACKERS] ARC patent

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, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] ARC patent

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  | [EMAIL PROTECTED]
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well. 
--Dennis Ritchie

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

Re: [HACKERS] ARC patent

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

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] ARC patent

2005-01-17 Thread Andrew Dunstan


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

Re: [HACKERS] ARC patent

John Hansen [EMAIL PROTECTED] 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

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

Re: [HACKERS] ARC patent

2005-01-17 Thread Nicolai Tufar

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

Re: [HACKERS] ARC patent

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 - [EMAIL PROTECTED] - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
begin:vcard
fn:Joshua Drake
n:Drake;Joshua
org:Command Prompt, Inc.
adr:;;PO Box 215 ;Cascade Locks;OR;97014;US
email;internet:[EMAIL PROTECTED]
title:Consultant
tel;work:503-667-4564
tel;fax:503-210-0334
x-mozilla-html:FALSE
url:http://www.commandprompt.com
version:2.1
end:vcard


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] ARC patent

2005-01-17 Thread Greg Stark

Tom Lane [EMAIL PROTECTED] writes:

 John Hansen [EMAIL PROTECTED] 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


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] ARC patent

2005-01-17 Thread Nicolai Tufar

On Mon, 17 Jan 2005 14:02:14 -0800, Joshua D. Drake
[EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] ARC patent

2005-01-17 Thread Greg Stark



 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 [EMAIL PROTECTED] writes:

 I can see it now:
 
 We won't sue you (customer) but you have to upgrade
 to DB2 ;)

Heh.

-- 
greg


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] ARC patent

2005-01-17 Thread Richard Huxton

Tom Lane wrote:
John Hansen [EMAIL PROTECTED] 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
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly

Re: [HACKERS] ARC patent

Nicolai Tufar [EMAIL PROTECTED] 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

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

Re: [HACKERS] ARC patent

2005-01-17 Thread Calvin Sun

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 18 months 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 application first.


-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
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

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

Re: [HACKERS] ARC patent

2005-01-17 Thread Neil Conway

On Mon, 2005-01-17 at 12:15 -0800, Joshua D. Drake wrote:
 We have just admitted that we knowingly may infringe upon
 an IBM patent. That really is a different thing than,
 We have some really smart people that came up with something,
 like this other technology.

The code is clear that it implements the Adaptive Replacement Cache,
which is an algorithm proposed by IBM; the code probably references some
IBM papers on the topic -- and if not, discussions of ARC on -hackers
certainly do. I don't see how there could be any reasonable grounds for
arguing that, prior to this thread, we just came up with something
really, really similar.

-Neil



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] ARC patent

2005-01-17 Thread Kevin Brown

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   [EMAIL PROTECTED]

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] ARC patent

2005-01-17 Thread Neil Conway

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



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] ARC patent

2005-01-17 Thread 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.
 
 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


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] ARC patent