Friday, May 7, 2010

Patently Ridiculous

Imagine you had an existing Java data model---a plain old one not based on EMF---that you wanted to map to an EMF model so you could take advantage of all of EMF's cool features. If your data model were a simple bean-style model, you could easily induce an Ecore model from its API; after all, that's what EMF's @model annotations do. You could then easily map instances of the plain old Java model to instances of your EMF model, perhaps using Java reflection, bringing together the old and the new.


What an exciting and innovative idea, you would exclaim to yourself, and to those around you, as you jumped for joy, reveling in your own brilliance.


Sorry to disappoint you, but don't bother. IBM has patented that: 7506303. The lesson learned? Just because something is simple and obvious doesn't mean you can't patent it. So run, don't walk, to your nearest patent lawyer, turn your obvious ideas into incomprehensible legal babel, file a claim, and then sue someone's assets right off their balance sheet, perhaps with the help of a patent troll. Surely such patented ridiculousness serves primarily to suck the lifeblood of the software sector much like collateralized debt objects did the vital stuff of the financial sector.

10 comments:

Federico Tomassetti said...

That is a shame. Fortunately in Europe we fought against them.

Jens v.P. said...

Something I always wanted to know about patents, but I was afraid to ask (until now): Eclipse has this more or less wonderful IP process, checking for problematic (C)s in submitted code. However, what about the (P)s? E.g., I was thinking about implementing nice dynamic layout algorithms in GEF3D, including something like coverflow ( (P) Apple). Thinking about these (P)-issues, I'm wondering if it's worth putting that much effort in solving some little (C)-issues...

Thomas Hallgren said...

I don't know. I just get really angry and frustrated when I read about things like this.

Unproductive, destructive, demotivating, and just plain stupid. And it's just getting worse.

Unknown said...

That's a great shame.Not as sophisticated as the patented IBM technology, but I've had some success using the excellent Topcased java UML reverse to get a UML model from plain java objects. Then I create EMF from the UML.

Madhu said...

This is ridiculous.

Mike Milinkovich said...

@Jens - The Eclipse Foundation IP due diligence process is entirely focused on checking for copyright and licensing issues. We do not do explicit patent searches because the cost, complexity and resource requirements of doing so would be astronomical. That said, the EPL does include a royalty-free patent license grant. So if a company has patented something and contributed the implementation to Eclipse you can make use of that code. (There are a few limitations on that statement, but that’s beyond the scope of a blog comment :-) )

Generally speaking, we do not spend any time at the Eclipse Foundation reading patents. And we won't be reading this one either.

Unknown said...

U.S. Patent office should be audited.

Miles Parker said...

@Mike - so, the EPL protects the user of an Eclipse tool because the developers of the tool have provided a license grant for any patents they hold, and have represented that no-on else has patent rights to the contribution. And it protects the contributor from losing IP for non-EPL usages. But what about the case where a contributor writes software that infringes on a patent (presumably) without knowing it? That is, what if the EMF team wrote the Java mapping without knowing, and IBM decided to enforce it? Then the contributor ends up carrying all of the liability burden even though they have provided open software in good faith? And how could the contributor respond effectively to notice of infringement?I guess this is the sot of thing that I should have looked into more closely before signing the contributor agreement. (Kidding..) Perhaps we could get a post from someone at EF giving contributors a better sense of where we stand with respect to liability in a case like that. Or perhaps there is already a good summary to look at. I've looked at the actual language, but its hard for me to figure out what all of the implications are.

Mike Milinkovich said...

@Miles

Re: "...and have represented that no-on (sic) else has patent rights to the contribution". I don't know where you see that representation. I don't think that's the case.

Re: "But what about the case where a contributor writes software that infringes on a patent (presumably) without knowing it?" Every one of us who writes software takes this risk every day. The problem is not unique to open source or Eclipse. It is symptomatic of the completely broken software patent regime.

wimjongman said...

Re: Patently Ridiculous