Contract Case Could Hurt Reverse Engineering
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.'"
DMCA is already crippling enough.
What about for making things compatible with it, or for research? What if someone slaps a EULA on a virus, and then sues anti-virus researchers?
Meeker noted that Baystate had reproduced a handful of errors in Bowers program. Kann, Baystate's lawyer, said all the errors came from Bowers' user interface, not the underlying code.
"I assumed blithely that there were no elves out there in the darkness"
If consumers go out and buy software to preform a certain sort of task, doesn't everyone involved have the right to make their own product like that to try and compete? Ford gave us the car, but other companies could take a look at it and try to improve upon it. How many resturants and burger joints are their in existance? How many computer operating systems are there? How many web browsers? How many things or places that do or offer the same thing as others, just at a different price, or in a different form, look, shape, etc.
Unless it's so blatant that the company took everything down to the GUI in reverse engineering, it's just trying to better the same service, thus helping out competition, lowering prices, so on, so forth.
SecondPageMedia - Wha
This is the equivalent of stating that the only reason for knowing what voltage your mains power runs at is so you can steal it. While theft is *one* reason for reverse-engineering there are many others. If you want your IP protected don't rely on it being hard to see.
This is pure R&D People. It's been happening for hundreds if not thousands of years. You have to find out the weaknesses and strength's of an opponent, and improve upon both. Not only has this been happenening for a long time, it has moved our economy ahead by setting a standard for companies to adhere to. If Product A dosen't do as much as Product B, it's obvious Product A is going to win the battle.
And why did you staple the trout to the RAM?
Poor baby.
By this logic, you should be able to take apart your car to see what kind of pieces it's made of. God forbid.
It's not the disassembly that's bad, it's when you use it to create a competing product. OTH, if it works exactly the same, the original designers will be able to see that it's bug-compatible (including race conditions), and thus be able to invoke some flavor of IP violation.
And when your oh-so-precious product crashes my systems and I want to single step through it to see what you fucked up, what tools will I be able to use besides these illegal tools to give you a point to start debugging at?
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Not necessarily.
The company that I used to work for was making a router-type product for the cable internet industry. Seeing as Cisco is considered the industry leader, it was highly desirable to copy the Cisco CLI commands, down to the exact command syntax (where possible).
The reverse engineering in my particular case involved typing in commands at the Cisco CLI, and then looking at either the configuration file, or SNMP MIBs to see the results (which is considered reverse engineering, even though I didn't look at any Cisco code).
Now, suppose I put in a very counter-intuitive command, or even a command which was considered to be "in error" (i.e. confusing syntax, whatever). Would you say that something fishy is going on? We're just trying to keep the interface as similar to Cisco as possible.
The article said that the error looked to be in the UI and not in any underlying code. Of course, the question is, were both programs done in the same language, use the same GUI toolkit, etc? Look and feel alone do not constitute full-blown "code-ripping", as we used to call this years ago.
-- Joe
(snip) ...Baystate claims it looked only at Bowers' user interface in order to improve its CAD software product. "There was no evidence of cracking encrypted source code or anything of that nature," said Bob Kann, Baystate's lawyer, of Bromberg and Sunstein, in Boston. "This may cause havoc in the industry. Before this case, it was perfectly legal to evaluate a competitor's product."
... you put in a contract with another company so that they can't reverse engineer the trade secret out of the product. That software took years to develop."(/snip)
But Bowers' lawyer countered that Baystate had two weeks in its development schedule to examine Bowers' software, giving the software vendor time to look at more than the user interface. "They had two weeks to reverse engineer his software," countered Bowers' lawyer, Frederic Meeker, of Banner and Witcoff, of Washington, D.C. "Two weeks is a long time -- that's a lot of looking."
...
"From a small software company's perspective, it's virtually impossible to recover your investment without some sort of protection," Meeker said. "That's a standard provision
Ok, so this boils down to a question of fact, which is a question for a jury to decide. The burden of proof ["preponderence of the evidence" in this case, IIRC] rests squarly on the plantiff.
That question is -- did Baystate decompile Bower's cad program to make their own. If so, they are guilty. If Baystate did not - if they wrote their program to match the look, feel, and usabilty of Bower's program, then they are obviously not guilty, shrinkwrap license not withstanding. I don't think you could possibly claim having a certain user-interface or user-available options are trade secrets, merely how you implement them.
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
wait just a second, just what is ment by "studying competitors' products"?
does this mean that if i have used M$ office say, at my college, i am unable to contribute to open office, or some other office type project?
this is incredibly stupid in my (uneducated) opinion. whats next, are we going to tell authors they cannot write books about a subject if they read a different book on the subject beforehand?
fantastic, only people completly uneducated in a subject will be able to do anything in the field. this should make for some fantastic inovation!!
-matt
To atone for your sins, you need to take a cue from Senator Hatch and physically destroy your machine. Now.
Allowing a license like this to stop reverse engineering/product evaluation is probably one of the worst things you can do to the software industry today. What if MS or Apple had done just that while releasing Windows/MacOS? Would the maker of any window manager that had window title bar, or a start menu, be sued for reverse engineering?
Spending two weeks reviewing the competition's product seems like a perfectly reasonable amount of time to learn its strengths and weaknesses. The only way to compete in an already established market is to build a better product than your competitors (cheaper/better/faster). How are we supposed to do that w/o being able to analyze the competitors' product?
Also, if reverse engineering can be banned, why try to patent anything? Patents eventually expire. A "trade secret" like, lets say, your basic UI design, that is only communicated to your customers after you've accepted the license, seems to me just as good protection as a patent, since anyone copying has broken your license, but offers no expiration date.
Hopefully the next time someone is set to court for something like this the result will be different. Reverse engineering is key to allow competition, the key principle to our economy. Undermine competition, and you are undermining one of the key foundations of our society. I just hope the next judge undestands that
>Reverse engineering is nothing more than the common theft of intelectual property.
Please show me how, when I draw a schematic diagram of my motherboard ABiT's intellectual property has been removed from their presence, never to be replaced, and has entered mine. Show me how they will no longer be able to manufacture this motherboard if I made duplicates, as they would no longer have the design for it. Show me how nVidia's design documents would be magically transported into my home if I should reverse engineer their nForce2 chipset.
Theft (in the sense you are using the word) cannot ocurr without a loss:
theft
\Theft\, n. [OE. thefte, AS. [thorn]i['e]f[eth]e, [thorn][=y]f[eth]e, [thorn]e['o]f[eth]e. See Thief.] 1. (Law) The act of stealing; specifically, the felonious taking and removing of personal property, with an intent to deprive the rightful owner of the same; larceny.
Note: To constitute theft there must be a taking without the owner's consent, and it must be unlawful or felonious; every part of the property stolen must be removed, however slightly, from its former position; and it must be, at least momentarily, in the complete possession of the thief. See Larceny, and the Note under Robbery.
Source: Webster's Revised Unabridged Dictionary, © 1996, 1998 MICRA, Inc.
Next time, use the word steal. Then at least you can suggest reverse engineering that intellectual property was like "stealing a kiss" (which is never a bad thing, so if you were to rebut me as such, I'd leave it at that).
Either that, or get off the soap box and use the words people in a real court have to use: Violation of the right of the plaintiff to enjoy monopoly status on a copyrighted design or patent.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
"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."
;-)
Correct. That term would be "copying" and please let's not get into that area? I've seen enough on copy protection lately...
Karma? What's that again?
The point is not so much that reverse engineering - it's more the whole thing about the EULA. Here's a quote:
The legality of this practice, called reverse engineering, is in question after a lower court found that a software company had violated a shrink-wrapped license contract when it reverse-engineered a competitor's piece of software.
Another quote:
Although the breach of contract ruling applies only to the U.S. Court of Appeals for the Federal Circuit, the Supreme Court's lack of action could embolden other software companies to prohibit reverse engineering or take away other fair use rights allowed under copyright law by including such prohibitions in an end user license agreement, said Karen Copenhaver, a patent and intellectual property lawyer with Testa, Hurwitz and Thibeault, of Boston.
.. and another:
The impact of the case, said Copenhaver, is that end user license agreements could become more restrictive. "Saying you can reserve that [reverse engineering prohibition] in a shrink-wrap license is saying a company can put virtually anything in a shrink-wrap," Copenhaver said. "Now there are very few limitations on what people will try to put on a shrink-wrap."
The EULA terms are unavailable at the time of purchase, so you might be buying software you can't even use! This was the reason that Germany decided that such licences are not legally binding (which avoids the other problem entirely). What other rights will they to take away from us?
Does the US have a concept of inalienable rights? (i.e. rights that can't be taken away, for those who don't speak such good English) Even if reverse engineering is not inalienable, I'd be trying to show that the buyer was forced to give legal rights, without being able to find out about it before purchasing.
-- Steve
As a licensed user of Bower's software in the late 80's I was never very impressed with the program. I keep hoping that it would turn into a useful tool but it never did and Bowers wouldn't take any input from his users. I eventually discontinued my subscription (that's how it was distributed). Honestly, I'm surprised anyone would want to steal it -- it's hard to imagine something that could have been worse. Most likely the reason he went out of business is because his software, um, sucked.
I thought one of Microsoft's arguments in the anti-trust case was that competitors could always reverse engineer the Win APIs (I'm not MS bashing, I just can't think of any other cases).
Next, there are patents. I know this is a difficult one (especially at /.), but when you have developped some groundbraking application, in my opinion, you have the right for a patent as a reward. Should it be 20 years? That's another question.
In this way, there's no problem with reverse engineering, as there are no trade secrets anymore.
And what's next? Some rule that I am not allowed to open my computer to look what's inside and check what additional piece of hardware I need? And that this is enforced by putting all hardware in mould (same stuff they use for ICs)?
In my opinion, software (plus processor) is nothing more than a flexible way of setting up technical stuff; what you can do in software is also possible in hardware. Why treat software different and prohibit reverse engineering?
My guess is that the appellate court upheld the trial results in their entirety. As I did not read the appellate court opinion, who knows. The Supreme Court did nothing. They did not agree or disagree. They just chose not to hear the case.
The patent claim was probably pretty clear. But I suspect that the breach of contract claim was a tougher one, as the common law concept of reverse engineering is pretty well accepted. I would hope if reverse engineering bans in EULAs become common practice, the courts in general will apply the long standing common law rights of reverse engineering.
As the article pointed out, the plaintiff is very sympathetic in this case (just like in the McDonald's spilled hot coffee case).
We will see what happens.
Actually, my justification was not I did it in school and got away with it. My justification was more that algorithms are more mathematical discoveries than inventions. I guess the same could be said of many inventions (medecines are just biochemical discoveries).
I just really think it would benefit society most if algorithms were public domain. Let's face it most algorithms are developed in academia and fall into the public domain if the university doesn't patent them, but most of the funding for this research comes from government and corporate grants not from patent-royalties. Besides, I think code encryption and obfuscation provide plenty of protection for corporations.
Hmmm. Performer protocol, not bad...
Actually, that's somewhat similar to an idea I had...
It might greatly benefit society if the government applied eminent domain to IP. Suppose I make an invention that could greatly benefit society, but I'm not liscensing it cheaply enough to benefit many people. The government could pay me a fair price and then place my invention in the public domain. I definitely think the government should do this with the AIDS drugs so that people in Afric/Russia/etc. can afford them.
http://yetanotherpoliticalrant.blogspot.com
It's a good theory, but it's not applicable to this case. It's obvious from the article that the original programmer of this application wasn't the industry leader. May be there is another perfectly good explanation to copy his errors, but personally I just don't see it.
From the article:
'Bowers' lawyer countered that Baystate had two weeks in its development schedule to examine Bowers' software, giving the software vendor time to look at more than the user interface. "They had two weeks to reverse engineer his software," countered Bowers' lawyer, Frederic Meeker, of Banner and Witcoff, of Washington, D.C. "Two weeks is a long time -- that's a lot of looking."'
These guys obviously don't know anything about software or software engineers. Two weeks is barely enough time to do the project plan. It would take months to execute a serious reverse on a product like this.
Reverse engineering does not require that you look at the source code. To make reverse engineering legal, you specifically should *not* look at the source code. The idea originated with the original IBM chip clone, where basically an engineer with no prior affiliation with IBM products would feed information into the chip and document what came out; by dint of careful testing, they were able to reproduce the functions of the chip without actually knowing what the insides looked like.
It's good for end users of a particular product (in my case, 3D software), when the authors of your favorite software can at least play around with the competitor's software. As long as they're not cracking code, this ability to look at the competition doesn't guarantee that they'll be able to beat them out or even match them, but it does help them compete.
What's next? Are we going to start telling auto manufacturers that they can't look at each other's cars when they're driving down the road?
"Give a man fire, and he'll be warm for a day; set a man on fire, and he'll be warm for the rest of his life
At the rate we're going, Ford won't be allowed to take apart Chevys to see how they work... McDonald's employees will be jailed when they eat at Burger King... and software engineers who look at competitor's interfaces will be blinded with hot irons.
OK, who the heck modded this Funny? There's nothing funny about the world that we're building for ourselves, where the very act of thought becomes illegal because it's based on some other thought. I want a +1 Scary, or +1 Orwellian-But-True. That would be more accurate than +1 Funny.
--GrouchoMarx
Card-carrying member of the EFF, FSF, and ACLU. Are you?
This is just another good argument for the US to adopt some sort of fair use legislation. Fair use in some countries include reverse engineering and copying copyrighted material for own use. For instance, in Norway those who have bought a copyrighted material have rights which cannot be limited by any license agreement. Some forms of reverse engineering are protected under this legislation.
When is the US going to start living up to its original ideals and protect the freedom of individuals? These days it sounds much more like the "Land of the Properly Set Up Free" to me!
Since is *my* hardware and I paid for it, I should be allowed to reverse engineer it. So what if the competitiors reverse engineer your stuff? It only stimulates companies to do better stuff. Just embed everything into a monolithic structure if you want to protect your stuff. I'm not talking about huge integrated circuits, but the whole thing embeded into some kind of plastic/whatever mass. No need for a court decision here. No need for lawyers to collect more fees.
Remember when development was about innovation rather than litigation?
I'm sick of it. I'm sick of having to pay IP lawyers to review everything I do. I'm sick of seeing farcical lawsuits over copied binaries (c.f. Blizzard versus bnetd), when any competent engineer knows that decompiling a binary gives you an incomprehensible, unmaintainable clusterfuck that you'd be insane to use (errors and all) rather than implementing your own solution. I'm sick of hearing about David versus Goliath confrontations as though we're all supposed to be rooting for David. And most of all I'm sick of reading mealy mouthed legalese arguing (for twelve years!) over the exact meaning and applicability of sub-paragraph 67b/6, rather than a court simply asking what's right.
If you were blocking sigs, you wouldn't have to read this.
have you ever heard of being bug compatible with another program? When you emulate an interface, you need to be not only copying what is considered "properly running interface", but you also must be emulating any errors of the interface. The reason is that you don't know what are errors and what is a desired effect. If you were to release a clone of a program, and you want the interface to be the same, then their interface bugs should show up in your code. If not by accident (not usualy) then intentionally (usually how it happens in a reverse engineering project).
Two infinite things: your stupidity and mine. But I'm not sure about the latter. If my sig offends you, I'm sorry.
Better information available at techlaw
[Set Cain on fire and steal his lute.]
At the rate we're going, Ford won't be allowed to take apart Chevys to see how they work... McDonald's employees will be jailed when they eat at Burger King... and software engineers who look at competitor's interfaces will be blinded with hot irons.
Not exactly funny since there actually is a case of a Coke delivery driver being sacked after being caught drinking a Pepsi. (Or possibly vice versa.)
One of the justifications for medicinal patents is that medicines are not Just biochemical discoveries. In fact, in order to be a useful medicine we do not necessarily need to know the exact molecular makeup.
Two things are necessary:
- A process for manufacturing the medicine practically, which may be extremely complicated and non-obvious.
- Knowlege about how to apply the medicine to best effect, which requires painstaking experimentation.
In pure patent theory, what the patent protect is the first one, and theoretically you can make the same medicine in a different manner and patent it yourself. Realistically in the current environment, I wouldn't recommend that.For medicine, you also need FDA approval, but that doesn't apply to most things.
Neither of the major concerns apply to software; if you know the algorithm, implementation is typically trivial, a matter of transliteration (as opposed to even translation; there's a difference). And figuring out how to best apply the algorithm is usually trivially obvious in what it does. (Now, noticing there's a better algorithm isn't always so easy...) So algorithms aren't like other physical inventions, since physical inventions typically require a description of how to practically create them.
Don't you know that all car companies do more than this? They don't just buy a competitor's vehicle and drive around for awhile, they tear the thing down to the component parts.
Ford (or GM or Honda or you name it) buys a competitor's car and completely takes the thing apart, looking for changes since the last model, looking for ideas for their next model, seeing how the thing works.
An equivalent software practice would be dissassembling the code, finding parts you like and recreating them so they work with your code. We aren't just talking gross interface elements (like steering wheels), though they do that too.
The major difference here is the place that software has lawfully. Software, in practice, acts like a tool, but lawfully isn't treated that way. For example a text editor is more or less functionally equivalent to a type writer, but you don't own software (EULAs say so); you pay for usage. Software is protected by copyrights, while physical tools aren't. It probably stems from the fact that the plans for the tool (the source) isn't all that different from the tool itself (the distributed program).
Does anyone know if the compiler generated code or just the source is copyrighted?
Patenting things which are fundamental *atoms* of information technology should not be allowed. It would be like patenting algebra or the number pi.
Of course, because patenting an algebraic function is just silly. Right?
Let's get this straight. Software can now be "protected" by copyright, patents, and arbitrary EULAs, but despite just being an advanced mathematical notation, it's not really considered speach because it can have a functional aspect?
"Communism is like having one [local] phone company " - Lenny Bruce
Of course algorithms should be patentable - suppose I come up with a great new video codec tomorrow, much better than anything else, but I can't patent it, I can only copyright the source code.
Now, I'm faced with a choice. I could develop closed-source software implementing the codec, and refrain from publishing my new algorithm, thus protecting my innovation with the copyright I'm allowed - if I do this, I'll probably make myself a tidy profit (assuming I know someone who knows the least bit about marketing), and be quite happy with the situation.
Or, I could publish the details of my algorithm, ensuring that no one will be willing to pay for my implementation (well, almost no one) - I can't get paid for my innovation, and the companies that already dominate the market will get my R&D efforts for free. They'll put their own implementation into their products, and pocket the proceeds.
Let's say I'm a noble minded researcher; I don't really care whether or not I get rich off my invention - on the other hand, I'm not stupid, I don't want anyone else getting rich off of it if I'm not getting some of the pie. Clearly, I'm going to keep my source closed, I'm not going to publish. This prevents my algorithm from being used in open-source products, blocks other researchers from extending and improving my results and generally holds back progress.
On the other hand, suppose that I can patent my great new codec. Now I have a third option. I can patent it, and set up a reasonable licensing scheme: you're free to implement my for private non-commercial use, research, etc. If you're getting paid from your implementation, then I want a cut of it, too. Now I can publish, its possible for the open-source and academic communities to use my great new invention, it's available for more research work, and at the same time, I can prevent other people from getting rich off of my work without also compensating me. This is *exactly* why patents exist: to allow people to profit from their work without impeding the flow of "progress".
Now, am I a loony git who thinks that *any* algorithm should be patentable? of course not. There's a reasonable standard, and it's illustrated perfectly by my previous example. An algorithm should be patentable only if the difficulty/effort in creating the algorithm sufficiently exceeds the difficulty/effort in implementing the algorithm.
Why this standard? If the "implementation cost" far exceeds the "invention cost", then no one's going to want to use their own implementation; they'll happily pay for mine, and a mere copyright on the source will suffice to protect me. Furthermore, the fact that the implementation cost far exceeds the invention cost is a strong indication that the algorithm in question fails to qualify as something that most people in the field wouldn't have thought up in the same situation (this should be a necessary standard for ALL patents - they should be INNOVATIVE).
On the other hand, if the "invention cost" exceeds the "implementation cost", then everyone else will develop their own implementations rather than use mine if the algorithm itself isn't protected; Conversely, since the invention cost/difficulty/effort/etc was so substantial, my invention is exactly the sort of thing that should be protected as innovative - something that the average person in the field wouldn't have thought of.
It should be noted that this requirement that the cost of invention far exceed the cost of implementation would actually eliminate the vast, vast bulk of software patents - which is a good thing. Patents such as "one-click ___", where you see it in operation without any knowledge of its guts and immediately know how it works, or the marching cubes algorithm (patented by HP, I believe), which is just what any sensible person with some background in computational geometry or algorithms would do, without much thought, should be gotten rid of. In all likelihood, this standard should be applied across the board, not just in software/algorithms. But should patents be done away with entirely, even in a restricted field? Of course not, and I think my example establishes that pretty clearly.