Re: [pgsql-hackers] Patent issues and 8.1 - Mailing list pgsql-hackers

From Robert Treat
Subject Re: [pgsql-hackers] Patent issues and 8.1
Date
Msg-id 200501290954.50968.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: [pgsql-hackers] Patent issues and 8.1  (Josh Berkus <josh@agliodbs.com>)
Responses Re: [pgsql-hackers] Patent issues and 8.1
List pgsql-hackers
On Friday 28 January 2005 12:36, Josh Berkus wrote:
> Robert,
>
> > Read the law... willful vs. unknown infringement are two different
> > things.
>
> We're not infringing anything, yet.   That's a *pending* patent.
>

*sigh*  Thats understood.  But you were using the counter-argument that we 
might be infringing on patents we know nothing about now so why treat this 
one any different. I'm pointing out this one would be different because we 
know about it and the law treats these things seperatly.  

> > Um... thats the way our legal system works. You could do that to any
> > project if you had a patent they were infringing upon no matter how
> > stoic they tried to be about it. (By our I mean the U.S. system)
>
> You're not following me.  Imagine this:
> 1) Pervasive/Fujistsu/SRA/Mammoth PostgreSQL steals some big clients from
> Obsolete Proprietary Database Company (OPDC).
> 2) OPDC has someone dig through their piles of patents and finds something
> that looks like it might infringe on something PostgreSQL does.
> 3) OPDC gets a blogger or similar to post something "And in the latest
> patent infringment news ..."
> 4) -Hackers hears about it and we derail development for another 3 months
> in order to work around the patent.
> Net Cost to OPDC: couple $thousand, to delay a PG release by 3+ months.
>
> What's kept patent litigation from being used against OSS projects so far
> is the bad PR that would attach, the potential cost of litigation, the
> possibility of having the patent invalidated, and the dubvious prospect of
> compensation.  But if a competitor can disrupt an OSS project with a
> *threatened* patent, then the cost is minimal and the effect is huge.
>
> We will face this situation again -- at least, until software patents go
> away -- and both I and Bruce feel that it's important to set a precedent in
> dealing with them because you can bet this discussion is being read by
> people who are not in favor of the spread of PostgreSQL.    This isn't just
> about the ARC patent, it's about the next one after that.
>

I guess I don't understand your rational here?  You want to set a precendent 
that the PGDG only responds to lawsuits?  Seems we should be willing to 
address anyones patent concerns in a resonable manner...  but that will 
depend on the size of the changes needed and what point in the development 
cycle we are.  This is a good size change and it comes at a time in the dev 
cycle when we have all our options open (it would be different if we were 4 
months in with all kinds of new things already added) and it's a feature that 
*we all want to change anyway* so why not be agressive about it?

> > FWIW I've really only been advocating
>
> BTW, my last post wasn't specifically addressed at you, but at the
> viewpoint that we should drop everything and work on the ARC replacement to
> get it out the door in 4 months.
>
> > that we don't do the change in a
> > patch branch, which I'm afraid the "do nothing till the lawyers show up"
> > plan would eventually lead to. We wouldn't normally do things that way
> > on technical grounds, so I'd prefer not to be forced into doing things
> > that way for other reasons; enough so that I think we ought to have a
> > plan to address it now.
>
> It's not a choice between doing something and doing nothing; you're
> mischaracterizing.   It's a choice between:
>
> 1) Shall we begin development immediately on an 8.1 which does not include
> the ARC code and can be upgraded without initdb, for plans to release this
> version in 4 months or less?
>
> 2) Shall we work our regular 1-year development cycle, with plans to
> replace ARC with an improved memory management approach as part of the
> features of 8.1, keeping a reversion-to-LRU patch in reserve in case we
> have to release it as a patch in the 8.0.x series?
>
> I advocate (2), partly because I don't believe that (1) is really possible
> for us.   When's the last time we did a fast release?   What I do advocate
> doing *now* is:
>

I'm not mischarecterizing, I just feel that putting out an lru based 8.0.x 
release is such a bad idea that I'd rather do (1) than gamble on (2).  
Honestly I don't think anything will ever come of this, but if things go 
spectacularly bad, the fewer  arc-based releases out there the better.  Not 
to mention that the only downside I have seen to (1) is that people think it 
will disrupt development too much but I don't buy that.  We can branch 8.1 
and 8.2 now, with 2month dev planned for 8.1 and a 12 month dev for 8.2 and 
go about things.  This would also have the advantage of pushing out a lot of 
loose ends a bit sooner (do we really want to wait a year for things like 
typo friendly psql?) as people get more understanding of the new features 
made in 8.0.  

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


pgsql-hackers by date:

Previous
From: Bruno Wolff III
Date:
Subject: Re: Allowing VACUUM to time out when waiting for locks?
Next
From: Tom Lane
Date:
Subject: Re: Allowing VACUUM to time out when waiting for locks?