You think you have just achieved the American dream and nothing can go wrong, right? Not exactly. You have to protect your dream first.
A lawsuit filed on Feb. 3 by SFB Market Systems, a Thorofare, N.J.-based software firm specializing in options symbology against the seven U.S. options exchanges and the Chicago-based Options Clearing Corp. provides a glaring example of just what can go wrong. And it offers lessons for how the software developer and its licensee can avoid finding themselves on opposite sides of a legal dispute.
Here’s the case in a nutshell: SFB alleges in its suit filed in U.S. District Court for the Southern District of New York in Manhattan that the options exchanges and OCC “reverse engineered” SFB’s copyrighted software for managing options symbols.
SFB claims the collaborators, in effect, took apart its code to see how it worked and then created their own version of the software with the same functions – to generate options series data and ensure they all have consistent options symbols.
SFB also alleges that by doing so, the seven options exchanges and OCC violated the terms of their licensing agreement for use of SFB’s software. The seven exchange customers of SFB are the International Securities Exchange; the Chicago Board Options Exchange; the Boston Options Exchange Group; NYSE Euronext’s NYSE Arca; NYSE Amex; the Nasdaq Stock Market and Nasdaq OMX Phlx.
SFB also claims that the exchanges and OCC misappropriated trade secrets that SFB owns although the trade secrets were not clearly identified in the suit. SFB says it was damaged by all of these actions and wants to be reimbursed. SFB is seeking big bucks and a jury trial.
The lawsuit comes amidst exhaustive preparations by the options industry to meet a Feb. 12 deadline to begin switching from five-character symbols currently used to identify U.S.-listed options to a 21-character description. No worries about business disruption. Intellectual property attorneys say it is unlikely SFB can get an injunction to prevent the exchanges and OCC from using their new software. SFB would have to prove its case before a judge and demonstrate irreparable harm that monetary damages wouldn’t fix.
While none of the intellectual property attorneys contacted by Securities Industry News would comment on the merits of the case, they did want software developers to be aware of good practices for protecting the intellectual property they have produced. That is, the code they write. They also wanted licensees to understand what they can and cannot do.
Lesson One: Software developers need to recognize that having a copyright alone won’t protect the software developer entirely from “reverse engineering,” according to Daren Orzechowski, an intellectual property attorney with White & Case in New York.
Registered with the Registrar of Copyrights in Washington DC., a copyright only protects a particular expression of an idea. For example, there can be several competing software products that offer similar functions (aka ideas) each of the companies could potentially have a copyright on its product.
To prove copyright infringement, the software developer has to actually show where the code was copied line for line; it’s similar to comparing the texts of two books or articles. And even if the software vendor can prove its client used some of the same code, the vendor still has to prove the client copied a portion of its software that was actually protectable under copyright law, says Orzechowski.
Bottom line: the copyright protects the code and not the underlying idea of the processes it expresses, says Ted Sabety, principle of Sabety & associates, a New York firm specializing in intellectual property law for computer software.
Lesson two: Copyrights aren’t quite as good as patents. In the case of a patent, it’s the actual invention that is patented. A software developer doesn’t have to prove that another party copied code to have violated the patent. According to Orzechowski, the patent owner simply needs to show that the infringer was making, using, importing or selling the invention – the functional idea. That means getting a patent on a software product rather than a copyright.
However, it’s far harder to get a patent than a copyright; it could take five years or more. That is because to get a patent, the software vendor has to prove to the U.S. Patent Office that it has a “novel” and “non-obvious” product over prior art. “Your own commercialization of the product more than a year before the date the patent is filed counts as prior art,” says Sabety.
Lesson three: If a software vendor can’t prove copyright infringement it may be able to prove that its client violated its contract. But that’s far harder than it sounds. “The language of licensing agreements typically includes what the licensee can and cannot do and that includes prohibitions on reverse engineering or using any part of the code as teaching for producing the same software,” says Sabety. If the contract isn’t explicit on what cannot be done, chances are the licensee will do it and get away with it.
Lesson four: An airtight contract doesn’t prohibit a licensee from cancelling its contract with a software company and developing its own software which performs the same function. And it doesn’t mean that it can’t use trade secrets, as represented by the software code.
Be the first to comment on this post using the section below.