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: