Red Hat Claims Patent On SOAP Over CGI 191
WMGarrison writes "US Patent 7453593 claims command-line processing by a web server of SOAP requests, resulting in XML responses, from and to a remote client. The HTTP Common Gateway Interface (CGI) operates precisely as described in Claim 1. If you POST a SOAP document and return an XHTML response or a SOAP document, this infringes Claim 2, since both XHTML and SOAP are XML languages. This patent thus claims to own the processing of SOAP documents by CGI programs."
This is a patent I can get behind (Score:5, Insightful)
If this results in the abandonment of SOAP, I'm all for it.
Fix the patent laws with anti cancer drugs (Score:5, Insightful)
OK, to save companies time and money (except for the Trolls and parasites), just get rid of software patents already. It's not good for buyers or sellers. It's not good for employees. It only benefits lawyers and patent troll parasites. Patent reform shouldn't take years, it should take days. I don't want to see another story like this ever again.
Patent for "Talking" (Score:4, Insightful)
Perhaps I should patent Talking. A means of transferring information between people. If you submit audible sounds to a individual and get audible sounds back, then you are infringing. :-) For a follow up I'll patent political speeches.
When will the madness end?
Defensive patents (Score:5, Insightful)
Re:Patent Troll (Score:2, Insightful)
Yes. (Score:3, Insightful)
Of course they are. Of course they are. It's not bad when "we" do it.
prior art (Score:1, Insightful)
Scanning the patent briefly I saw the earliest date was 2005.
In 2003/2004 I wrote a CGI script that greps a csv file pipes it to sed to generate xml and returns that xml to the client.
Does this count as prior art?
Actually I am writing a (client side focused) Ajax course now and intend to use a toy cgi service that greps a csv file and returns the data in not XML but JSON. That is not XML pfew I do not infring the patent.
Re:Yes. (Score:5, Insightful)
You're post reads as if you're being sarcastic. You are aware that if Red Hat were to prevent other people from using their patents in GPLv2 or later software then they would lose the ability to distribute GPLv2 or later software, right?
They could go after proprietary vendors I suppose but I find it far more likely that these are defensive patents.
Re:So what? (Score:5, Insightful)
Therein lies the problem. I'm a one-developer shop. Even if a claim is 100% bunk, I can't afford to defend myself from a legion of lawyers who would simply drag out a court case forever - SCO style. Since I'd like to actually work instead of spend my life in court, I'd be forced to settle - giving said patent a bit of legitimacy. It's not a protection now, it's a business model equivalent to a protection racket.
Someone had to... (Score:4, Insightful)
Face it- if Red Hat hadn't done it, M$ probably would have. It's likely a "defensive" patent they are unlikely to use unless provoked. It's all just a game. A big, high-stakes, unfortunate game.
Re:Defensive patents (Score:3, Insightful)
That's what they are doing by promising not to sue Open Source projects for using THEIR patented intellectual property. It's still THEIR patented intellectual property, and they'll sue closed source projects for using it.
What's even worse is they renig on their promise if an Open Source project tries to challenge Red Hat's claim to the IP. "Our Promise does not extend to any party who institutes patent litigation against Red Hat with respect to a patent applicable to software (including a cross-claim or counterclaim to a lawsuit)."
That means that any project that wants to use any of Red Hat's licensed IP can't challenge ANY of Red Hat's patents for any reason, even patents that they shouldn't have because that open source project has provable, existing prior art in the area.
Red Hat isn't defending anyone but themselves.
Re:Defensive patents (Score:2, Insightful)
Re:Yes. (Score:3, Insightful)
Let's say some corporation applies for a patent on garbage collection or XML or image editors or something like that. Someone has to prevent them from doing it.
Who would be in a better position to present prior art? Who has obvious standing in this case at all? And which one has legal parity that would be obvious to any Windows user charged with making a judgment on this? A corporation with a similar patent, or a loosely-knit but idealistic bunch of Slashdot lawyers?
In principle it goes against everything to be relying on a single private party to shield obvious processes from frivolous patent claims on things we do every day. It places too much trust in one party. But legally and in a pragmatic sense I would be inclined to let Red Hat deal with these people. They have patent lawyers. Otherwise geeks have to keep coming out of the woodwork to make prior art claims.
Re:Patent Troll (Score:3, Insightful)
We have know for a long time that Red Hat is a patent troll. They make IBM look like noobs.
Ok, c'mon now... Redhat (IBM as well) is part of OIN [openinventionnetwork.com]... Press Release [openinventionnetwork.com] here... How about we wait until they actually do something trollish before throwing around accusations like they were government bailout money...
Re:Yes. (Score:3, Insightful)
so all this 'defensive patents' is nonsense -- they just want to get some leverage to 'wrestle' others wrt other companies' patents if/when such "others" will try to go after redhat
That's the whole point of a defensive patent portfolio. Some other company has patents over stuff you're selling (considering all the software in RHEL, this is certain) so you take out patents on stuff that other companies are likely to be selling.
Its the same logic as the cold war where you have nukes because everyone else has them - nobody would ever go after anyone with patents because the other guy could just counter-sue. The problem is patent trolls, they are the equivalent to terrorist groups with nuclear bombs: they have nothing to lose.
Re:So what? (Score:3, Insightful)
You hit a small shop first to gain that legitmacy. The next place you sue(slightly larger), you show that you've succeeded in court before, and that either gets them to settle or influences the judge in deciding for you. You continue up the chain until you get smacked or start making serious money. If you get any resistance, you drop it as soon as possible and go on the next company. While you may have had success as an individual, most of these cases would either avoid you initially after you pushed back or smack you into the ground later through accumulated successes.
As for you reducing this discussion to teenagers stealing games, that is quite bizarre. Many of us are reliant on IP laws, whether to using hacks to get around the limitations(GPL, BSD, Creative Commons) or working in the system(standard copyright, extra rights/limits through contracts, etc).
I don't hate IP wholesale, I need it as a backdrop to the extra rights I grant those who use my software. Otherwise everything uses the WTFPL without the name change requirement. What I hate are those who take advantage of a system that is sorely out-of-date for purposes that contradict what the system was supposed to do.
Re:This is a patent I can get behind (Score:2, Insightful)
I'm not sure what SOAP solves. What does that complexity buy me? I've written to API's in XML, fixed width files, serialized objects, url encoded, cgi post, shared memory, named pipes and others.
All SOAP manages to do is make object instantiation and invocation look nothing like what is going on.
SOAP is not abstraction it is misdirection.
COBOL files were typically well defined. Writing a parser and validator for them would take less time than setting up the same for SOAP. I'm not suggesting we go back to COBOL, I'm saying that SOAP doesn't win us anything by making parsing and validating available to something made unnecessarily complex.
Re:This is a patent I can get behind (Score:4, Insightful)
That is insane. Have you ever actually tried that stuff? Firewalls, cache, all these things don't behave well with GET. Furthermore, there are arbitrary limits to GET string length.
At the very least, any browser/server communication format must be able to handle arbitrarily complex datastructures of arbitrary length... unless you're writing toy apps.
You're so very wrong. The HTTP protocol does not define a max length for the GET query string. Any complex data structure can be represented by XML and you can return 100gb of XML if you want. Simpler structures can even be represented by JSON which might be even easier.
As for firewall and cache, well... stop setting up idiotic solutions. Your public API is exposed via HTTP. So your firewall and caching solutions need to represent this. If it doesn't, that's because you did something wrong and missed the point. HTTP is highly scalable and that's the point. If your public API are serving massive requests very frequently, throw squid infront of your HTTP server. If you want some obfuscation set your port to something other than 80. Your excuses for firewall and caching don't make a lot of sense.
Re:This is a patent I can get behind (Score:5, Insightful)
As to GET and PUT limitations: http://support.microsoft.com/kb/208427 [microsoft.com]
As to browser cache and proxy behavior: You are assuming app developers have control over their users' browsers and proxy servers. That's a false assumption. You just failed to meet the minim requirements for the project (working on ie6 with ghettoproxy 0.1).
You don't know what you're talking about. Who mentioned browsers? Since when do browsers make direct SOAP calls to SOAP-based web services? They don't. Applications make SOAP-based requests to web services and then serves up views based on the data models the web service returns. The problem with SOAP is that SOAP reinvented HTTP. HTTP is perfectly geared to handle this notion of a centralized API with many applications using the same API. You can use this setup with ANY KIND OF APPLICATION, whether it be a desktop app, a web app, a command line app. You don't even need the internet.
If you somehow see a problem with this, then you're working in the wrong job.