Thread: Re: [pgsql-hackers] Patent issues and 8.1
Marc, Tom, Robert, Bruce, et al: > Bruce is advocating waiting until the Patent has been Granted, instead of > doing something about it now, when we know the patent is going through the > system (and will likely get granted) ... a "reactive" vs "proactive" > response to the problem. No, we're reactive regardless. Proactive would have been to investigate the ARC paper when it was published for outstanding patent applications, and again before feature freeze. Or even to have considered the fact that when an IBM person publishes a paper on new technology, IBM probably has a patent on it ... they're the largest patent-holder in the world, after all. It's a little late for that, and would probably not even have been a good idea, lest we let legal concerns paralyze development. > Basically, after the patent is granted, we are going to scramble to get > rid of the ARC stuff, instead of taking the time leadign up to the > granting to get rid of it so that when granted, it isn't something we have > to concern ourselves with ... We don't *have* to do anything when the patent is granted. When we *have* to do something is when IBM sends a cease-and-desist letter to a PostgreSQL user. Not before. Tangentally, but relevant: a few years ago I was facing a potential lawsuit from a customer who had changed management and was suing all their former vendors as a path out of bankruptcy. Never having been sued before, I was inclined to panic. I called a classmate of mine who was a litigation attorney, and retained his services, and asked what I should do."First off, don't panic," he said. "Have you been servedyet?""um, no""Then don't worry about it. You may not be served. If you are served, you are likely to be able to get this dismissed. The last thing you want to do is panic and try to bargain with them now; they'll see that you're a softie and go on the attack. You've retained me, that's all you need to do now."(as it turned out, I was never served) Take a look again at the posting by Nicholai -- someone with professional experience in patents. Last I checked, nobody else on this list is a patent attorney, clerk, or IP litigation professional. 1) The patent may not be granted for another year. 2) The patent may never be granted. 3) When/if the patent is granted, its terms may have changed and we may no longer be infringing, *IF* we are now, which I have yet to see an *attorney's* opinion on. 4) IBM may put this patent in its set of GPL patents, since we are not the only OSS project using ARC. This would be a licensing headache for some of our users, but not a catastrophe. 5) Even if IBM does not OSS this patent, they may choose not to enforce it against us or other OSS projects since it would mean massively bad PR for them. Given that we're planning on replacing/overhauling ARC anyway, I really don't see that we need to do more at this time. Except maybe keep Neil's LRU-reversion patch somewhere handy in case we need it, and build a variant version and run it through tests at OSDL to see what it breaks (it would be good to do this anyway to see what, if anything, ARC is gaining us in terms of performance). Now, if one of our commercial supporting companies is worried enough about this to do something -- such as funding a hacker for a 3-month intensive better-than-ARC development stint -- then let them step up to the plate. Many of our programmers are happy to accept commercial development dollars for what is a commercial concern. Let's not steer development based on protecting what we think is protecting our commercial sponsors, when they haven't even asked us! Heck, the idea of a pluggable memory manager tickles my funny bone, even though I don't think such a thing is possible. Like *any* other piece of major software, we probably infringe on 50 different patents which we don't know about, held by a variety of parties. If we let this one *potential* patent panic us into a response we may regret later -- such as derailing 8.1 development, or releasing an insufficiently tested new version -- then some other company will threaten us with patents with malicious intent to watch us jump and scramble again. Attorneys have already said that Linux infringes several dozen outstanding patents. Do you see Linus suddenly overhauling the kernel? Dropping everthing and rushing a non-infringing, under-tested 2.8 to release? No, you don't. -- Josh Berkus Aglio Database Solutions San Francisco
Josh, > >>Bruce is advocating waiting until the Patent has been Granted, instead of > >>doing something about it now, when we know the patent is going through > >> the system (and will likely get granted) ... a "reactive" vs "proactive" > >> response to the problem. > > Very well written Josh. Thanks. As you know, I'm getting a little sick of the chicken little act among many of the -hackers .... --Josh -- __Aglio Database Solutions_______________ Josh Berkus Consultant josh@agliodbs.com www.agliodbs.com Ph: 415-752-2500 Fax: 415-752-2387 2166 Hayes Suite 200 San Francisco, CA
Josh Berkus <josh@agliodbs.com> writes: > No, we're reactive regardless. Proactive would have been to investigate the > ARC paper when it was published for outstanding patent applications, and > again before feature freeze. Or even to have considered the fact that when > an IBM person publishes a paper on new technology, IBM probably has a patent > on it ... they're the largest patent-holder in the world, after all. It's a > little late for that, and would probably not even have been a good idea, lest > we let legal concerns paralyze development. That would actually be a bad idea. As several people have pointed out, actively seeking out patents you may be infringing is risky because it can open you up to liability and that can paralyze development. > We don't *have* to do anything when the patent is granted. When we *have* to > do something is when IBM sends a cease-and-desist letter to a PostgreSQL > user. Not before. That's untrue. I suggest you disregard all my comments as free legal advice is really only worth what you pay for it. IANAL and all that. But I also suggest you stop giving legal opinions like this. Moreover, the postgres development community is really not the concern here. Users of postgres who are aware of this issue (and many of them are on this list) will be the ones put at risk. -- greg
On Thu, 2005-01-27 at 12:51, Josh Berkus wrote:
> We don't *have* to do anything when the patent is granted. When we *have* to
> do something is when IBM sends a cease-and-desist letter to a PostgreSQL
> user. Not before.
>
With that attitude we don't have to do anything even then. We have a
good number of users that this patent claim will be unenforceable
on...right? We have the option of dealing with this now on our own
terms... if we gamble and lose we may have to deal with it in less
favorable conditions.
> Now, if one of our commercial supporting companies is worried enough about
> this to do something -- such as funding a hacker for a 3-month intensive
> better-than-ARC development stint -- then let them step up to the plate.
> Many of our programmers are happy to accept commercial development dollars
> for what is a commercial concern. Let's not steer development based on
> protecting what we think is protecting our commercial sponsors, when they
> haven't even asked us!
>
I'm not sure if your glossing over this on purpose or your just unaware,
but it is not just commercial support companies that will be getting
those letters if IBM ever heads that route. (I'd agree that I don't
think they will, but let's not kid ourselves if they do)
> Like *any* other piece of major software, we probably infringe on 50 different
> patents which we don't know about, held by a variety of parties.
Read the law... willful vs. unknown infringement are two different
things.
> If we let
> this one *potential* patent panic us into a response we may regret later --
> such as derailing 8.1 development, or releasing an insufficiently tested new
> version -- then some other company will threaten us with patents with
> malicious intent to watch us jump and scramble again.
>
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)
> Attorneys have already said that Linux infringes several dozen outstanding
> patents. Do you see Linus suddenly overhauling the kernel? Dropping
> everthing and rushing a non-infringing, under-tested 2.8 to release? No, you
> don't.
>
Well, I suppose if we had someone's who job was supported by dozens of
multi-billion dollar corporations who all had patent portfolio's that
totaled into the thousands we'd probably have more legs to stand on, but
we don't so the WWLD plan may not be best for us.
FWIW I've really only been advocating 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.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert, > Read the law... willful vs. unknown infringement are two different > things. We're not infringing anything, yet. That's a *pending* patent. > 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. > 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: a) someone (Simon? Sean? Neil? Jan?) should start hacking on a better-than-ARC buffer manager to have it for 8.1, and b) we should build an 8.0.1 with Neil's Revert-to-LRU patch, upload it to OSDL, and start hammering on it so that it will be tested in case we need it (and if there's no loss of performance or stability, maybe drop it in the update stream regardless of patent status). I also suggest that we might want to hit up one of the several well-funded parties involved in PostgreSQL, who have staff attorneys, for an opinion on the whole business, and some insight into what proprietary software companies do. That would be Pervasive, Fujitsu (assuming that AU has software patents, I don't know), OSDL, and CMD. Heck, there will be a panel of OSS attorneys at the Enterprise Linux Summit; I can ask them but of course it won't be an actual opinion unless money changes hands. -- Josh Berkus Aglio Database Solutions San Francisco
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Read the law... willful vs. unknown infringement are two > different things. You can't infringe on a non-existent patent. > FWIW I've really only been advocating 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. It's not "do nothing till the lawyers show up." At the very least, it's "do nothing until it actually becomes a patent." There are 1000s of pending patents out there. The bar is very low: all it takes is some money and some paperwork. Proving that it is novel and new is the tough part, and there is no guarantee that this particular one will get to that level. If it does, IBM could certainly donate it, or let the project use it, or decide that our implementation is sufficiently different. At any rate, they are not likely to go after an open source project, even if via our "customers." If and when they do, that's when we react, the same way with do with security fixes: make new branches, and release them. We look good, IBM looks bad, and we get lots of free publicity. Spending time on this is silly, IMO, unless there is a technical reason why the feature should be replaced. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200501282155 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFB+vtuvJuQZxSWSsgRAnB8AKDnUsQM7xb1tRF93ehT05xg6Bf6TwCeOYn9 JdP4di03yzuSB9aaVskXb5g= =U9HF -----END PGP SIGNATURE-----
"Greg Sabino Mullane" <greg@turnstep.com> writes:
> Spending time on this is silly, IMO, unless there is a technical reason
> why the feature should be replaced.
Well, people can validly have different opinions on how critical it is
to dodge the upcoming patent (and surely whether you live in the US or
not affects your viewpoint). But as to the second part of your comment,
the fact is that the ARC buffer management code has been underwhelming
and we were already looking around for something better. I believe Jan
already admitted that his original testing was flawed and that the
algorithm is not so much better than LRU as he thought. We are also
staring at the fact that ARC is not at all helpful when it comes to the
problem of reducing contention for the BufMgrLock. It uses an inherently
centralized, serialized data structure and the operations it requires
aren't notably cheap. So I was already feeling dissatisfied even before
the patent issue came up, and I'm all for getting rid of ARC as soon as
we can find (and test) something better.
regards, tom lane
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
Robert Treat <xzilla@users.sourceforge.net> writes:
> 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).
I don't understand why you think it's such a bad idea. We do have the
problem of getting adequate testing, but I think the answer to that
is to put the same patch into HEAD as well.
> 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.
I will resist that idea strongly. We have no experience as a community
with managing multiple active development branches, and I feel certain
that we'd mess it up (eg, commit things into the wrong branch, or fail
to commit things into both branches that need to be in both). Case in
point: Teodor has already, without discussion, committed 8.1 changes in
tsearch2 that should force an initdb. If we were taking the idea of a
backward-compatible 8.1 seriously we'd have to make him back that out of
8.1. I can't see trying to ride herd on all the committers to make sure
no one unintentionally breaks file-level compatibility over a whole dev
cycle, even a short one.
regards, tom lane
On Saturday 29 January 2005 11:33, Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
> > 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).
>
> I don't understand why you think it's such a bad idea. We do have the
> problem of getting adequate testing, but I think the answer to that
> is to put the same patch into HEAD as well.
>
The combination of inadequate testing, making support more difficult, and
general all around confusion that beta/rc's for a revision level release are
sure to cause. Not to mention that if the patent ever does materialize into a
problem, the scope of that problem will be that much greater the longer we
wait.
> > 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.
>
> I will resist that idea strongly. We have no experience as a community
> with managing multiple active development branches, and I feel certain
> that we'd mess it up (eg, commit things into the wrong branch, or fail
> to commit things into both branches that need to be in both). Case in
> point: Teodor has already, without discussion, committed 8.1 changes in
> tsearch2 that should force an initdb. If we were taking the idea of a
> backward-compatible 8.1 seriously we'd have to make him back that out of
> 8.1.
I think this is a false case since right now we are hanging in limbo, with
people unsure of what is proper to commit into what branch. If there had
been an official announcement that no initdb level changes were to go into
8.1 I think we'd be ok.
> I can't see trying to ride herd on all the committers to make sure
> no one unintentionally breaks file-level compatibility over a whole dev
> cycle, even a short one.
>
I think the key is to put someone in charge of either 8.1 or 8.2 and let them
be the primary gatekeeper for that release. It can work either way... people
develop against 8.1 and we have an 8.2 gatekeeper(s) responsible for patching
forward any new commits into 8.2 and handling file-level incompatible feature
commits. Conversly we can have folks develop against 8.2 and have someone in
charge of backpatching any non file-level incompatible changes backwards and
the ARC changes.
There are other upsides to this as well. If we could do this now it would
help move us to the ability to keep feature development going year round.
Rather than having to stop 4-5 months every year to do beta we could create a
new branch during beta and let people continue on with that... we already had
some rumblings of that idea during the 8.0 beta cycle, this would give us a
good test run.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Andrew, > On Thu, Jan 27, 2005 at 10:39:52AM -0800, Josh Berkus wrote: > > Thanks. As you know, I'm getting a little sick of the chicken little > > act among many of the -hackers .... > > I think this is a little bit of a mischaracterisation. Afilias is > already a customer of IBM. BTW, if you hadn't guessed, that comment was supposed to be off-list. Unfortunately, I discovered a bug with KMail and list management, the hard way ... And to be perfectly frank, I was mostly thinking of Marc when I said that. -- Josh Berkus Aglio Database Solutions San Francisco
Guys, > BTW, if you hadn't guessed, that comment was supposed to be off-list. > Unfortunately, I discovered a bug with KMail and list management, the hard > way ... Sigh. Just in case anyone wants to know, KMail 1.5.1 + has a bug where, if you have list management turned on, it sometimes sends stuff to the list instead of the To: line you see on the screen. Dammit! Any other Linux-friendly mail GUIs that have list management features and don't have this problem? -- Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus wrote: > Guys, > > >>BTW, if you hadn't guessed, that comment was supposed to be off-list. >>Unfortunately, I discovered a bug with KMail and list management, the hard >>way ... > > > Sigh. Just in case anyone wants to know, KMail 1.5.1 + has a bug where, if > you have list management turned on, it sometimes sends stuff to the list > instead of the To: line you see on the screen. > > Dammit! > > Any other Linux-friendly mail GUIs that have list management features and > don't have this problem? Evolution does although I haven't tried it in a while. J > -- Command Prompt, Inc., your source for PostgreSQL replication, professional support, programming, managed services, shared and dedicated hosting. Home of the Open Source Projects plPHP, plPerlNG, pgManage, and pgPHPtoolkit. Contact us now at: +1-503-667-4564 - http://www.commandprompt.com
Attachment
Marc, > And to be perfectly frank, I was mostly thinking of Marc when I said that. Sorry, that was uncharitable. I meant that (at the time) you were panicking. Now you have something different to panic about. How goes the server shuffle? -- Josh Berkus Aglio Database Solutions San Francisco
On Mon, 31 Jan 2005, Josh Berkus wrote: > Marc, > >> And to be perfectly frank, I was mostly thinking of Marc when I said that. > > Sorry, that was uncharitable. I meant that (at the time) you were panicking. Wait, I've not panic'd about all of this at any point ... the only 'chicken little' comment I made had to do with everyone panicking about a patent that doesn't yet exist, and comparing that to "chicken little and his 'the sky is falling'" ... *scratch head* ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, 31 Jan 2005, Josh Berkus wrote: > Now you have something different to panic about. How goes the server > shuffle? alot smoother today then it went yesterday ... and faster ... but, then again, *most* clients use <256MB of storage, so moving their VM around takes no time ... svr1 is @ ~13G :) Something like 3G is justin's mailbox alone ... and i miscalculated how long it would take to move it back over to neptune :( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc, > alot smoother today then it went yesterday ... and faster ... but, then > again, *most* clients use <256MB of storage, so moving their VM around > takes no time ... svr1 is @ ~13G :) Something like 3G is justin's mailbox > alone ... and i miscalculated how long it would take to move it back over > to neptune :( I doubt that's intentional, why don't you ask him to truncate it? I noticed that you used to grant @postgresql.org addresses as "unlimited", I changed the default to 5MB, which is what all the regional contacts now have. -- Josh Berkus Aglio Database Solutions San Francisco
A new organization called the "Software Freedom Law Center" was announced yesterday; that seems like it may be one of the best places open-source groups could go for questions like this ARC pending patent. Eben Moglen (The FSF's main lawyer and Columbia Law prof), Diane Peters (OSDL's general counsel), and Lawrence Lesseg (Stanford law prof behind Creative Commons) are behind this organization; so it seems to have pretty good credentials. http://news.com.com/2100-7344_3-5557962.html "The center said in a statement that it will employ two full-time intellectual property attorneys, who will help provide consulting services to nonprofit open-source organizations. The staff count is expected to expand to four later in 2005. The help they provide could include training lawyers, supporting litigation, dealing with licensing problems and keeping managing contributions to open-source projects, the center said. "