Contract Case Could Hurt Reverse Engineering 269
An anonymous reader writes "InfoWorld has an article about how a 'U.S. Supreme Court decision could call into question a common practice among software companies: studying competitors' products to improve their own offerings.'"
Errors replicated? (Score:5, Interesting)
So they play with the finished product and copy what they see (roughly) -> fine, as long as you don't violate anything protected by patents. No clause in a EULA could be upheld that would prevent that. It has nothing to do with what can be put in a EULA, but rather, what can be determined as permissible in such an off-hand context.
But to have errors duplicated in the system: I assure you would not be duplicated in a UI unless the coders copied the exact methods behind the UI. Hence they have legitimate claims that there is something fishy going on.
There's matching behavior, and then reimplementing without first understanding. The latter is 1) irresponsible 2) lazy, 3) contemptable, and those that practice should not be protected by reverse-engineering rights. I claim that shouldn't be called reverse-engineering, but something else.
He stole my GUI! (Score:5, Interesting)
Isn't this more of a issue of Look and Feel?
I also like how they say the GUI is a trade secret.
Re:It's about time (Score:4, Interesting)
From what I could understand from the article this was not a case of code decompilation, but rather looking at the program and seeing how it works, then reimplementing the features.
Idea theft maybe, but reverse engineering?
Algorithms should be public-domain (Score:5, Interesting)
But I still think algorithms should be public domain! If you own a company, and you have a particularly cool algorithm you want to hide, you should have to either obfuscate or encrypt the machine code. There is absolutely no reason that algorithms should be protected IP.
Computer Science is a weird mixture of science and engineering. A lot of the theoretical and some of the applied work is very scientific, while most systems work is very much engineering. Scientific discoveries are not generally patentable, inventions are.
The compromise I propose is this: allow source code to be copyrighted, but deny the patentabilty of algorithms. As anyone who has programed knows, even with a detailed algorithm and specification, there still is a lot of engineering required to complete a finished product. That engineering work would still be protected.
Bad Baystate... no cookie (Score:5, Interesting)
Bowers had offered to work with Baystate in the late '80s, but the company had rejected his offers [...] Baystate also pressured CAD software company Cadkey not to distribute Bowers' product, and later, Baystate purchased Cadkey and shut Bowers out of the market [...]
This sounds familiar; Find your biggest competitor, buy out their potential investors & then 'borrow' their technology. I do feel sorry for Bowers in all this! He mortgaged his house 10 years ago to fund the marketing of his software & he still hasn't received a dime from Baystate.
Meeker noted that Baystate had reproduced a handful of errors in Bowers program
Yup, that's a problem. It's hard to rationalize something like that... then again, judges aren't always tech savvy & they have been convinced that software DVD decoders must digitally copy [digitalspeech.org] a DVD in order to play it, thereby making DVD playback on a PC illegal. I'm sure Baystate's lawyers tried to argue that in making a 'similar' GUI to Bower's program, they ran into the same bugs by accident - or by design - or something else just as ludicrous.
Don't get me wrong, I'm all for capitalism; But decompiling your competitor's software is not the same as merely using ideas that seem to work well for your competitor.
Alternative Installers? (Score:5, Interesting)
I can see one way companies might get around this is to encrypt the software, and have decryption initiated by the 'I agree' button. The DMCA would then be invoked against anyone who wrote their own installation program. Even then, is it cut and dried whether an alternative installation system is covered by the DMCA?
Is installing a piece of software one has just bought an act of copyright circumvention? You're not circumventing copyright, just the contract the author has attached. One could argue that you can't use a work without agreeing to the author's contract, but hasn't the author already made a contract with you by accepting your money?
From the little info we have it sounds solid (Score:3, Interesting)
If, however, they take it apart and copy it right down to the included errors, that's theft, and not all right.
I have to assume that the evidence given proved the theft, and that's why it went through at least three judicial levels and came out the same each time.
Congratulations are due the winner.
--
Tomas
Huh? (Score:1, Interesting)
I know a guy who got accused of cheating because he left his assignments on an open share, and someone found them and turned 'em in as their own. What does this have to do with anything? Nothing at all.
The academic world has nothing to do with IP law. If you paid me to write an essay for you and you turn it in, it's called cheating. If you pay me to write an essay, and you print it and sell it, it's called publishing. If I let people copy my source code for their homework, it's cheating. If I let them copy my source code for their real work, it's called 'free software'.
Re:It's about time (Score:5, Interesting)
What is it that you are not meant to see? The are distributing it, and yet they dont want you to see it?
Tim, while i can see you are trying to express something here, I think you need to get some more fully formed thoughts out.
Lets begin, you claim companies have NDAs to prevent people from seeing their 'code'. I can only assume you mean source code, as when you send a product out the door everyone gets to see the object code. Now if a competitor is disassembling a product they not only (usually) haven't seen the code but aren't under NDA. So the point is moot.
As for theft, well this is a really different thing than what is generally termed 'reverse engineering' If they were 'pure theft' they would change all the names and release it as their own product (which sadly does happen). However R.E. is meant to dissect the inner workings as to recreate the 'black box' if you will. This has been decided to be legal a bunch of times.. please see Compaq vs IBM (PC bios) and Connectix vs sony (playstation emulator).
Technically speaking yes.. disassembly would be 'for their own benefit', the benefit of making a compatible system. Familiarity with the terms it really vital here.
Re:Huh? (Score:3, Interesting)
This would be great for SCO (Score:4, Interesting)
Lets hope for the best. The effects could be quite damaging. Compatibility would also be outlawed which SCO would attack any Unix around for that reason.
More about patents, less about reverse engineering (Score:5, Interesting)
However, if the patent didn't exist would Bower's have ultimately won this case based purely on the reverse engineering clauses in the EULA? I suspect not.
It seems that this case doesn't seem to offer a good precedent for preventing the common practice of reverse engineering through a EULA because so much of it is tied up in the patent infringement aspects of the case. Also, the article makes it seem that Baystate so closely copied the UI that they could have infringed copyrights as well which only serves to make the case even more ambiguous with regards to reverse engineering.
It would be more interesting if these other aspects of the case didn't exist and Bower's had simply tried to sue Baystate on the fact they violated the EULA by having two weeks of reverse engineering his product in their development schedule -- even if he couldn't point to specific trade secrets of his being used by Baystate in their product.
Therefore, I doubt this case will even put a dent in the common practice of reverse engineering competitors products.
BTW, IANAL so don't sue me if you get sued.
Re:Algorithms should be public-domain (Score:3, Interesting)
This is a very market-oriented approach. Are you sure the assumptions you make (people won't innovate without financial incentives, and firms are the source of most innovation) are correct in this case?
It seems to me that most algorithms are not invented in the private sector, but come out of places like academia. After all, if it were otherwise, shouldn't there be a lot of firms out there that specialize in doing nothing BUT researching algorithms? With the exception of RSA (a commercialized academic discovery, not a commercial invention), I can't think of one off the top of my head.
An alternate solution to strengthening copyright is the public funding of basic applied research, or using government clout in the market (government procurement has historically driven many software sectors) to promote open standards.
Re:La la la... (Score:3, Interesting)
No, by this logic, it only means you shouldn't reproduce the exact same mistakes your competitor made when you design your own car, otherwise it's going to look mightily suspicious.
Re:Algorithms should be public-domain (Score:4, Interesting)
It seems to me that most algorithms are not invented in the private sector, but come out of places like academia. After all, if it were otherwise, shouldn't there be a lot of firms out there that specialize in doing nothing BUT researching algorithms?
No, because it is quite difficult to market an algorithm. Developer: "We've got this really cool way of sortng lists of strings." CIO: "Ummm...does it do spam filtering?" Developer: "I guess it could." CIO: "Call me back when it does." The valuable part is usually not inventing an algorithm, but discovering a problem that it solves. If you know what problem it solves, you might as well go to market with a software product that is a complete solution that a customer can buy. You'll make a lot more money than if you have to convince some middleman that your algorithm could make a ton of money if only somebody put it in a product.
Re:It's what the consumers want. (Score:3, Interesting)
But where does it end? Where is the line? I'm going to bite the big one for this but how much is KDE starting to look like windows? If GUIs can enjoy protection, and what's to stop Microsoft from patenting a GUI in which the main menu can be accessed with a button containing the company's logo in the bottom left corner of the screen by default, and using icons to represent running programs along with a clock in the bottom right? I believe that yes, you can't copy a GUI bit for bit, but there has got to be some leeway allowed.
Right now as I sit here with Opera7 and IE6 opened, I notice that each has the sequence of buttons: back, forward, refresh, home in the same order. Is that a potential breech of copyright, though the buttons look nothing like each other? I'm saying that GUIs that let the user perform the same task should be protected from being exact replicas, but not protected to the point where having too many overlapping features will cause suspicion.
Reverse engineering economically inefficient. (Score:3, Interesting)
Re:It's what the consumers want. (Score:3, Interesting)
That's for the courts to answer. They will consider a range of issues including prior art (yes, even for Copyright) and substantial similarity. There are many more issues than Copyright to consider though.
Not much. Patents are different to Copyright. Can MS patent this? Maybe, I don't know. Adobe got patents on their GUI elements, but they could have (at some point) been considered innovative. Then again, so could the taskbar.
Certainly. In the end it comes down to cold cash. If you can't prove damage, you don't have a basis for delict, and you can't hold someone liable for patent, design or copyright infringement, or unfair competition.
So you have to ask yourself: is your interface using elements of another interface, either by intentionally copying the look and feel, or just because "it was a good idea"? Are those elements a novel or distinguishing feature, or are they recognised as standard practice in a UI? As a result of using these elements are you enriching yourself, and/or causing damage to the owner of the copyright in the other product? If "and" in the previous question, this may be unjust enrichment; otherwise it may be delictual liability. Is there copyright over the "original" work? Is there a patent or design reservation covering the elements in question? Are your products in competition (it is difficult to establish damage if they aren't)? And specifically, did you use the elements in order to gain a competitive edge, remove a competitive edge that the original product had over your's, or to make your product confusingly similar to the competition (all of which could be unfair competitive practice).
In short, there are numerous issues to be considered; Copyright is just one, and potentially the least powerful. Copyright covers the specific expression of an idea, and its derivatives. This is generally easy to determine with literary works, but very difficult with software, especially user interfaces. I would think that the notion of novelty will be considered: a thousand UIs designed in accordance with a HCI 101 textbook won't infringe on each other, because there is nothing to distinguish them from the general concept. A brand new UI idiom (if I could think of one I wouldn't tell you ;p ) may, on the other hand, be worthy of copyright on its own.
I am not a judge, but I would take into account factors like being able to redefine the toolbar(s), allowing you to present the buttons in whatever order is appropriate. The HTTP and HTML specifications in themselves and when read with commentary on their creation imply certain functionality, such as access to your hypertext traversal history (back, forward, history), and the need for caching and a mechanism to bypass caching (refresh). Also one would need to consider that a web browser's primary functionality is to display web pages, and there are recognised idioms for giving access to supporting functionality (menus and toolbars, and a status bar).
Re:It's about time (Score:2, Interesting)
However, what earlier cloners such as Phoenix and Compaq did was to have two teams work on the cloning project. The first team looked at the source code and documented all of the system calls. The second team read that documentation and produced clean-room code that would behave the same way as the IBM BIOS. The second team never saw, of course, the IBM source code.
The CAFC is the problem. (Score:3, Interesting)
You see the name "Court of Appeals of the Federal Circuit" and you assume, oh yeah that's part of our nations justice system. But it's an evil little fucker that got tacked on just a few decades ago by the administration of a vicious bastard named Ronny Raygun.
When people complain about the courts being pro-corporate or pro-patents or pro-copyrights, they're generally incorrect, but in the case of this court it's right on the money.
The CAFC was created by executive order and we damn well need to elect a president with the balls to get rid of it the same way.
Re:It's about time (Score:5, Interesting)
Here in Australia, reverse engineering of software is actually my legal right. [slashdot.org]
The only reason the competitor could possibly have for dissassembling the binary code would be to copy it for their own benefit.
Absolutely. And to be honest, why not? Fixing your software bugs (because you won't) and improving the interoperability of my software (with yours) are definitely for my benefit.
In regard to the wider issue, the courts here in Australia would by no means automatically agree to the legality of an EULA that placed 'undue restrictions' on my common law right, especially when those restrictions can be seen to be anti-competative. In this particular case however, after having read the article and assuming that the information given was accurate, I think the American courts made the right decision. To be honest, this actually appears to be more an issue of software component theft (exact reproduction of errors in a UI?), than one of reverse engineering.
It's even worse (Score:3, Interesting)
Second, this case isn't about reverse engineering, it's about contract law and copyright protection. While the issue on the surface was reverse engineering, the case was about allowing state contract law to overule the protections given to consumers in copyrights. Copyrights assign a number of rights to consumers. It was created so information would be shared. Once the information is published the publisher gets rights to the form of presentation (ie. a book) and the public gets to use the information presented. Reverse engineering is a way to understand the information given to the consumer. You are "reading" the "software". Apparently there are some books that if we read them we can't use that information. In fact, a publisher could publish a book, sell it in a shrink wrap, and place terms on what you can and can not do with the information in that book. By removing the shrinkwrap you agree to the terms!
Re:It's what the consumers want. (Score:1, Interesting)
No, copyright protection is intended to protect a creative implementation. Copyright law specifically does not protect functional elements of a work. A novel's plot and characters are generally protected, since they are creative choices - you could reuse the characters in a work of historical fiction since history has already determined the names and places of events. A computer game tends to have greater creative protection, since a game is, generally, nonfunctional. A CAD program, on the other hand, is primarily functional. A particular GUI may be better or worse, based on objective criteria such as how long it takes to learn, or how quickly an experienced user can make a new drawing. There already is case law describing the extent of copyright protection for user interfaces - one case involved copying and simulating the Lotus 1-2-3 menu system; another involved the layout of buttons on a VCR.
This case really seems to be more of a (worrisome) precedent in that it validated a significant term in most EULAs. Since just about every EULA on the planet includes a prohibition on reverse engineering, it could be generalized to imply that once you have used some type of program (a spreadsheet, a database, etc) you are permanently blocked from ever writing a competing product because you might use some ideas you gathered from using that program.
Re:This is about two things. (Score:3, Interesting)
Re:Errors replicated? (Score:3, Interesting)
Didn't programmers do this regularly years ago to prevent exactly this sort of thing? "In defendant's program, if you hold shift-alt-xzyacb, it brings up the same exact message as it does in our program, proving they copied the exact source from us, since there's no plausible reason for that to be in the program otherwise" type thing. Do they still do that?