Hacker News new | past | comments | ask | show | jobs | submit login
Reverse engineering of competitor’s software cost company big (internetcases.com)
280 points by sidcool on Oct 25, 2017 | hide | past | web | favorite | 149 comments

This decision does not lie well with me.

Of course, the competitor agreed not to reverse engineer the software - under the definition "attempting to produce a copy", they definitely did reverse engineer.

But does that mean that re-implementing the same interface is reverse-engineering? That would be scary and terrible for competition.

No software with a reverse-engineering clause could have a clone. Does Windows have one? If yes, Wine developers could not compare if a game works under Wine correctly.

What about APIs? Is it forbidden for US citizens to create NVIDIA CUDA clones now? If someone found a way to reproduce some Photoshop image filter, is it forbidden to compare the resuls? MS Word-produced files?

I really don't like where this is going. Thankfully, reverse engineering cannot be forbidden in the EU (unless I'm wrong).

EDIT: I guess my main gripe is that if the owners of proprietary "standards" which achieved monopoly can effectively forbid any alternatives, cementing the monopolies.

The main point here is that they acquired a license for the software with explicit purpose reverse engineering the language, even though the license forbid that.

If they had "just" implemented a clone without getting a licence from SAS, then they likely wouldn't be in trouble.

"Is it forbidden for US citizens to create NVIDIA CUDA clones now" No, but if you download a free piece of software with a license that forbids you from using it to create a clone of NVIDIA CUDA, and you agree to the license and you do just that... well then you breach the license you agreed to. It's not a blanket ban on every case of reverse engineering, just a case of WPL shooting themselves in the foot in an obvious manor.

So you're just saying it's effectively illegal to reverse engineer pretty much anything. So long as the company in question put a magical paragraph of text in their EULA?

I just don't buy this. There is literally no way to build a CUDA clone without testing output against both your clone and CUDA itself.

With this reading, EULA's have effectively banned cloning any form of software.

> There is literally no way to build a CUDA clone without testing output against both your clone and CUDA itself.

Not necessarily. You might be able to get by only testing against third-party products that use CUDA.

We did something like that at Interactive Systems Corporation in the '80s when we wrote a 286 Xenix emulator to run on 386 System V. If I am remembering correctly, we never actually had a 286 Xenix system to compare to. We just had a bunch of system call level test programs, and a few big applications like word processors.

Yes - I think clean reverse engineering is still possible in this model, but it really limits a lot of what software re-implementation people do day to day. For example, if I were making a spreadsheet application like Google Sheets, I'd have to build a repository of customer Excel documents and validate that my formula compiler output the same data as was present in the document, without ever opening Excel to quickly check an output or asking someone to open Excel and produce a spreadsheet containing specific inputs/outputs - because either one would be considered EULA-breaking reverse engineering (at least by my reading). That's scary and I actually think it has broader implications for "normal" products as less EULA concern is applied there than in obvious legal minefields like emulators.

I feel like "grandpa is gonna talk", and I'm not even that old. But "when I grew up", "reverse engineering" was still explained as an incredibly hard thing, infinitely harder than just engineering. It was said to be where one team would go into a room with a device, send out a spec, that a different team would then take to implement, they'd never meet, the implementing team would never get to see or touch the original device (pretty much what someone in a sibling thread described as their own experience, rather than me just hearing this being explained). With all that in mind, I'd say that WPL (the defendant) pretty much missed the whole point of reverse engineering...

That's 'clean room' reverse engineering. Not all reverse engineering has to be like that.

Based on the descriptions in the article, aside from isolating the teams, this is very much what they did.

The difference being that they didn't have a second team dis-assemble and actually reverse engineer the product to write a formal spec for how it functioned. Instead they did A/B testing to ensure that the output of the known product produced the same output as the reference implementation, reportedly without examining how the black box worked.

Yes - this was the point I was making in the last sentence of my comment. People writing things like emulators think about "reverse engineering" and take clean-room precautions. People writing things like spreadsheets think about "what does the competitor product do" and "competitive analysis" and type things into competing products and observe the output, which by my reading would be an EULA breach as well.

This is very similar to the dilema of drug manufacturers and generics to me. On one hand without a strong financial incentive you won't have big companies investing in the original pieces of software.

On the other hand at a certain point it becomes a monopoly with a negative societal impact.

It seems really weird to suggest that no big companies would make software if they knew that competing software could be developed. Regulations on drugs require extensive and time-consuming trials, and that's the strongest argument for drug patents. There isn't anything remotely similar in software, and that kind of incentive is definitely not needed.

Drug manufacturers get patents and a corresponding period of exclusivity. This is worse than patents in some ways because there's no time limit. It's like drug manufacturers could attach a EULA to their pills that makes reverse-engineering a competing product a legally enforceable contract violation even after the relevant patents expire.

I don't buy this. "It's like drug manufacturers could attach a EULA to their pills that makes reverse-engineering a competing product a legally enforceable contract violation _even after_ the relevant patents expire."

You've gone from "Drug manufacturers get patents and a period of exclusivity" to "Patent and exclusivity, and also protection from generics for the brand's life", but patents can be applied for at any time during a drugs development, including before it's ever been synthesized (e.g., theoretical manufacture via computer models) but the exclusivity is only a U.S. FDA marketing feature. Patents on a drug could expire before the exclusivity, so a competing manufacturer could create a secondary brandname drug and sell it overseas during that period. I'm really confused as to where this EULA would even fit in, since you've just moved the goalposts with your "even after" clause.

If the FDA had some kind of deterministic human trial of a drug, like some dystopian lab-grown identical human clones, of which drugs were trialled on and some company B was able to obtain a set of these clones from company A that had some kind of defect of which the drug was targeting as a cure or remedy for, and then used those proprietary clone models in order to test their clone drug against, we might have some kind of metaphor worth arguing against, but we don't.

Copyright does have a time limit. In the US, I believe the work just had to be older than Steamboat Willie.

However, there's another decision that doesn't seat with me either. US Copyright lay says:

> person who has lawfully obtained the right to use a copy of a computer program may circumvent a technological measure that effectively controls access to a particular portion of that program for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs

Courts have generally chosen that a EULA clause can override this provision of the law, which seems pretty backwards to me, especially considering that the validity of shrink-wrap licenses hasn't been established very firmly (although I'm not sure about the nature of the EULA in this case)

Even so, simply running the program as a blackbox and comparing whether your own program produces the same behavior does not constitute "access to a particular portion of that program for the ... purpose of identifying and analyzing ... elements that are necessary to achieve interoperability". That text is clearly referring to peeking at the code. The external behavior of a program isn't an access-controlled portion of the program. Only the code can be that.

Access controls are tricks like basic compilation of source into machine code (and further obfuscation from that departure point such as run-time decryption of code sections, requiring execution to be controlled in a debugger to intercept the decrypted code), and the placement of a program as firmware onto a tamper-resistant chip.

Imagine I do the following: I contract a third party company to obtain a license of SAS, and use that license to produce a language specification.

Producing a language specification surely is not reverse engineering on its own. I could equally well contract the company to undertake a rigorous security analysis of the language to look for vulnerabilities or defects. Neither of these companies needs to know how I'll use what they produce. It seems unreasonable to consider the act of producing documentation about a product's public interface behavior as "reverse engineering".

Then, I use the language specification to build my own implementation. Is this permissible? If not, why not? Who is undertaking the act of reverse engineering prohibited by the license?

This is known as a clean room process. In this case, you would not be at fault as you aren't held to the terms of the license. However the company doing the documentation may be in trouble, if the license forbids them to document the program functionality.

I don't feel like that should be something which /could/ get you in to trouble in a legal system focused on the good of the public.

How do you produce a CUDA clone if you can't explore any CUDA implementations or read any CUDA specs without first obtaining a licence.

You get someone else to obtain that license and produce a detailed requirement specification which they then sort of leak in your direction. You then "clean room" implement, without having seen any original documentation or worked with the original device or software.

That someone else is not connected in any way; i.e. you are not both subsidiaries of the same company, etc.

E.g. your manager's uncle has a friend who works in some company where they have a CUDA license; arrangements are made and things are procured.

The requirement specification is not traceable to a particular CUDA license key; there is nothing that can be proven about the identity of the source.

It's really improper for some license to forbid reverse engineering to begin with. They already are protected by copyright. Re-implementing something with reverse engineering should be perfectly legal.

The actual gripe here is that for physical products of any kind, of course companies routinely buy and completely take apart their competitors products. But in software make-believe land you can write any wish you have into an EULA.

There are entire companies whose only mission is buying electronics, reverse engineering it into its constituent parts and producing a detailed report that tells you whats in it, how it's made and most important what it costs to make. That's possible because when you buy something, you own it. Only in software make-believe do we allow selling some very ill-defined "right to use" with no guarantees or rights.

Protecting the inner workings of a product is precisely what patents are for.

Of course, the patent itself reveals the inner workings of the product. Or is supposed to. You trade the secrecy of your invention for protection from competitors.

In the EU, reverse engineering is allowed, but only for the purpose of making something that interoperates with the product you're reverse engineering, and does not compete with that product.

In the EU what WPL has done is allowed, it has gone through those courts already.


Notably only the way WPL produces manuals that are too similar to SAS has been upheld.

Do you have a reference for this? It would really help me settle a recent argument with a work colleague who thinks that reverse engineering a SAP HTTP API is not OK

The EU basis is Directive 2009/24. Given it is a directive, each member state has local laws implementing it, so the exact details might vary.


Article 5 and Article 6 are the most interesting when it comes to reverse engineering, with 5 allowing to study an application while using it legally and breaking some protected rights for bug fixes and 6 allowing decompilation for some purposes.

This case of SAS vs. World Learning first went to court in the UK and from there to the CJEU which had a few substantial clarifications. These are quoted here in Wikipedia:


Does this help you?

It's apparently in directive 2009/24:


I think you'd want to know about the case law before leaning too heavily on that, though.

Your #1 way to resolve that issue is to pass it to corporate legal if you have such a department.

Along these lines, would Google be in trouble for Google Sheets, since it can take an excel file and load it?

Nope, newer MS Office products write files as a fully documented XML format.

Contrary to popular belief MS never deliberately obfuscated Office files; they were simply a raw dump of the internal objects as they were in memory. So obviously they would change between versions. Which made sense in the days when computers were a lot more resource constrained than they are now. Now with power and memory to spare, they can be encoded and decoded on the fly.

And that xml file is anything but structured in a plain and simple way. To understand it and all it does, it’s be impossible to accomplish in a way that people didn’t load a given file in excel and diff the two. Same for OpenOffice.

I wonder how much that has to do with excessive amounts of backwards compatibility for existing .xls and .doc files. I imagine a fresh implementation with no respect paid to existing sheets would be much better behaved. Anything that stands out to you as overtly strange in the format worth drawing attention to?

Office is a super giant set of products with a million function, years of versions each their own set of bugs, and decades of files of every kind and subset of features produced by users. I personally have almost never seen another word processing app, for example, 100% successfully load in a non-trivial document from a competitor. It’s just really hard, especially if the features don’t map 1:1, let alone fonts, model of layout, etc. Just the shear number of rendering quirks, subtle differences in math formula implementations, etc would be mind boggling. It’s hard to imagine a more insane (and boring) job.

Kudos to Google for getting such impressive compatibility. Must have been insane amounts of man-hours to achieve. They at least have the ability to crawl the web, download docs and xls, and automate comparison. I’m not sure it’s even feasible otherwise.

Maybe some of it is that, but it was released amid an activist push for governments and public agencies to be required to use an open file format such as ODF[1]. So, Microsoft's XML format is open, but it may still not be great. From what I understand that's pretty easy to do with XML.

1. https://en.wikipedia.org/wiki/OpenDocument_adoption#United_S...

"excessive" to you is "core user need" to a product manager

OpenXML is not fully open standard, unlike OpenDocument. So they obfuscated even the modern one. There are many parts that ambiguously documented or not documented at all.


As a former microsoft employee, I disagree. They certainly were happy that it was hard for other people to read and write office files. It was a feature, not a happy accident.

My first task in the industry, in the early 90's, involved writing to excel files. At the time I worked at microsoft, so you'd have thought they'd have given me the super secret documentation to the excel format. Instead, they gave me a book published by microsoft press, describing the BIFF format which is what they'd called the format, apparently dreaming that it might one day become a semi-open standard for spreadsheets. (there was no danger of that ever happening, the format was distilled madness, based on a million performance optimizations)

Later they made the format a lot saner, but either way I'm pretty sure google would be fine.

IANAL, but it seems that yes Google could be in trouble there, assuming that the Excel EULA prohibits reverse engineering, and also assuming that Google did actually use Excel to compare the behavior of opening different files.

It also depends if Microsoft had published the xls[x] spec, and under what license.

The specs for the open-XML file formats (the newer XLSX) are open.

Which means you're permitted to parse the files and handle them according to spec., which is notably different to handling them "exactly as Excel does" (e.g. in cases where the spec. allows implementation variance, which I believe are frequent with OpenXML formats), particularly where Google would be testing with Excel software in order to ape implementation specifics that are absent from the spec. That's the potentially worrying differentiator in this case.

The older specifications are available as well, I don't think they have any specific requirements about their use. I think they called it CDF back then.

Might also be covered by one of the many cross-licensing agreements that no doubt exist between Google and Microsoft.

I feel like a key difference here is that there was a specific 'learning' version designed to bring someone trying to learn the language behind the scenes. While I can see the concern about this ruling being used in a broader context, I think there's a major difference between copying and experimenting with the prod version of the service and the one developed intentionally to give a behind-the-scenes view.

>>What about APIs? Is it forbidden for US citizens to create NVIDIA CUDA clones now?

If the Google v Oracle case stands, API's are fall under copyright as such you have to have a copyright license to replicate them.

That was the entire case, how google implemented the entire Java API with out using Java

SO things like WINE, or any other implementation of an API that does not have the original author of the API's permission are violating copyright law

Also companies probably could use this to punish security researchers for discovering vulnerabilities in their products.

The real lesson here is that they should have pirated the SAS software instead of licensing it. Then they would have been liable for at most a large fine instead of having their business shut down.

If the license was tightly integrated with the software (meaning even a pirated copy would require acceptance before use) then just hire an outside consulting company to generate the output from the test code. It could have all been documented and left the company with clean hands.

The simplicity of side stepping the license in this case highlights the absurdity of the ruling.

Not saying SAS wouldn't still sue them, but they wouldn't have nearly as strong a case with damages less likely to be bankrupting.

> The real lesson here is that they should have pirated the SAS software instead of licensing it.

That's a perverse but probably accurate reading of the situation.

It reminds me of patent advice I've received: never look at a competitor's patents, or even speculate about them. Damages in a patent lawsuit go way up if the infringement was willful, which is automatically assumed if you know about the patent.

This is generally what lawyers recommend: https://en.wikipedia.org/wiki/Clean_room_design -- although this is generally done to avoid copyright complaints, not license complaints.

But per your link "Clean-room design (also known as the Chinese wall technique) is the method of copying a design by reverse engineering and then recreating it without infringing any of the copyrights associated with the original design."

They did reverse engineer the code instead of infringing copyright. The problem is that it violated a license prohibition on reverse engineering. I'm not going to claim that the judges interpreted the law incorrectly, but I think that this legal result is overall bad for society. It means that a company can stifle competition even if potential competitors avoid violating copyright or patents.

If they had pirated the software, then they wouldn't violated a license prohibition since they wouldn't have agreed to it.

I'm wondering how what they did is different from clean room design where the clean room is just intensely close to the non-clean room.

I've worked for companies that created subsidiaries with the sole intent of purchasing competitors products with the intent to reverse-engineer them and do competitive performance analysis. Good legal counsel probably would have suggested the same.

That's interesting. I'd probably favor making the other company as disconnected as possible instead of a straight sub, but that difference may not matter much.

Even if they did shut down, couldn't they just rebootstrap as another LLC add do it the "right" way this time?

Late reply, but one problem here is that the ruling against the company could give SAS them the right to take ownership of the software as a creditor to a company with no assets left other than the code.

Lots of complexities there, but the root of the issue is that you can't pull a company's main asset out from under legitimate creditors. And SAS will soon be a big creditor as soon as the ruling is final and they get a monetary judgment that the company presumably won't be able to pay.

There are lots of ways companies try to evade this basic principle, but none that can withstand the scrutiny of a court and motivated, financed creditor.

So, basically poking your competitors software with a stick, being an effort to understand its inner workings, is reverse-engineering. When prohibited by EULA it becomes a breach of contract.

It does seem overly broad, this line of reasoning left unchecked would imply no third-party replacement parts for any device, because you need to understand the working to make a part...

On the other hand if I am creating some new technology, inhave now gained a very effective tool to fight the copy-cats. At least the ones who couldn’t setup a shell company for this exact purpose.

>> So, basically poking your competitors software with a stick, being an effort to understand its inner workings, is reverse-engineering. When prohibited by EULA it becomes a breach of contract.

Correct. The problem with that is you might hire someone who has lots of experience with a product in order to develop a competing one. You have that person tell you how the new product needs to behave. This is essentially doing the same thing, but who is violating the "agreement"? At the time the employee learned about the product, they were a legitimate user with no intent of reverse engineering. They may or may not have personally accepted the EULA (it may have been installed by the IT folks). When they go to the new company, who becomes responsible to any alleged wrong doing? I guess I'm saying there is a grey area where things boil down to intent rather than action, and that makes me think it's wrong (on top of the more obvious issues).

On the upside, IIRC there are countries where this activity would be legal and the enforcement of the EULA terms against it are unenforceable. IANAL, so find said country(s) and development practices to circumvent this problem on your own. I think it's unfortunate, but it's exactly the kind of stupid problem that pushed RMS to start the GNU project.

In developing the WPS, defendant did not try to decompile the Learning Edition, or otherwise “tear it down” or “look under the hood.” Instead, it would run SAS code through both the Learning Edition and the WPS, evaluate the outputs from both systems, and tweak the C++ code comprising the WPS to get the outputs to match.

This is the same as getting Linux to behave like a Unix kernel, or GNU tools to behave like Unix tools, Wine to behave like Win32 DLL's and so on.

Validating "does my machine produce the same output for the same inputs as this blackbox" is not reverse engineering. It's just engineering. Reverse engineering means taking it apart to look inside. Forward engineering means designing it and building it; reverse means the opposite: disassembling and inferring the design from the pieces and their relationships.

Key paragraph:

> More specifically, defendant had argued on appeal that the lower court’s summary judgment on the breach of contract/reverse engineering claim was improper because the term “reverse engineering” in the license agreement was ambiguous. Plaintiff and defendant offered competing definitions for what they thought reverse engineering ought to mean. Defendant proposed a narrow definition – essentially, that reverse engineering must have as its objective the re-creation of source code. Plaintiff, however, offered a broader definition, encompassing other efforts to “analyze a product to learn the details of its design, construction, or production in order to produce a copy or improved version.”

(spoiler: court sides with plaintiff)

To what extent can a lawsuit be brought over a system that functions, for many inputs, in the same way as another, separate system? What's the difference between reverse engineering and plain old competition?

You can't, in general, bring a lawsuit based on "reverse engineering." This was a breach of contract lawsuit, where the contract prohibited "reverse engineering."

But, can I effectively threaten all similar competition by having a reverse engineering clause in my EULA?

This, I believe, is why everybody is in an uproar over this decision. You put it very succinctly.

Your competition should read the EULA and if they were purchasing it with the intent of reverse engineering it then they should abort that purchase.

Not unless they bought your product and agreed to your EULA.

But what if I’m a new social network - do I have to hire engineers who aren’t on Facebook if they have no reverse engineering in their EULA? I’m worrried about it being yet another legal tool to bludgeon small companies with.

That's a good point. For products that "everyone" uses, it seems to give the companies behind those products more power. And further empowering larger companies to go after smaller ones doesn't seem like a good change.

To me, plain old competition is analyzing the system with data that a regular user might use.

It becomes more like reverse engineering the more you dig into, to the user, irrelevant technical details of the product.

The defendant acted as a regular user. They ran the SAS compiler and their compiler with different programs and looked for differences in the output.

No idea what the law actually says, but this seems like a job for the "obviousness" standard that we've also got in patent law (for better or worse). If you're poking at a product to figure out details about it that are "not obvious", and then you build a product with those same details, that's "reverse engineering".

In this case it does sound like they were trying to figure out API conventions, and not real engineering details, but that's just my cursory reading.

SAS Institute, one of the most valuable privately held compaies in the US, has been fighting against run-alike and data-compatability challengers for decades.

This is particularly ironic as the company itself was founded based on mainframe storage and interface technologies -- the SAS program editor and interactive environment through the 1990s was based on the IBM TSO/ISPF environment.

Earlier challenges included the BASS System, by Jeff Bass (a DOS run-alike in the 1980s), and a dataset reader/converter, DBMSCopy. The latter eventually included a program interpreter as well, I believe.

My recollection is that DBMS/Copy's developer and SAS came to a mutual understanding.

SAS's key asset is control over utility and access to a decades-old legacy of programs and data at enterprise and government sites, though it's lost ground to Python and R in tech and most especially academia.



I work as a SAS programmer for state government. I find it funny that anyone would set out to emulate the jumbled late 1960s hodge podge of yuck that is SAS syntax.

(I use SAS because I like data analysis and my pension plan and governments don't do open source, not because I like SAS...)

Gotta be the most archaic language still in common use.

I mean not saying it doesn't have legitimate uses, fast well tested and a few procs with the right options can accomplish a the equivalent of a lot of Python, and I only ever learned enough to run a few datasets and port some old code to python/r/vba, but observing the crazy ass shit people did to implement any kind of logic or data transformation was enlightening. Many many "wait people actually do this" moments. Like an entire ancient programming paradigm I never knew existed.

SAS actually combines several useful things in one seamless environment : statistics, plotting, ETL, and data management. For any one of those functions, there is some better system (R, R, perl, sql respectively), but integration can be hard. Also, it is a single purchasing decision with a standard product. Plus, a good SAS programmer can build fairly big processes and avoid brain dead IT bureaucracies. Not that I love it, but it's a niche no other single environment serves.

It's not so much that integration is hard, but that any given site tends to integrate differently.

The problem I've encountered with SAS specifically is that the more powerful tools are hard to gain access to (or proficiency with) given the licensing costs.

I have literally been told by SAS regional sales staff that I would be better off pirating a copy of the software to gain access to it. I politely declined.

Antecedents from, as noted, mainframes, and APL specifically.

SAS Supports R, so simply write R scripts and replace the proprietary crap piece by piece. Then use cost and security issues to kick them to the curb (A newspaper article about wasted Millions usually works if you can't get management to listen to reason and a researched cost-benefit analysis)

Funny, I just used SAS Studio for constrained optimization tasks (linear programming), for my Supply Chain Management classes, and I rather liked it.

I was told I could use Python instead for the same tasks, but I liked the single-mindedness of SAS, the program pretty much writes itself.

I think you just answered your own question. SAS makes a lot of money, so competitors want a chance to make their own cut.

What system could governments use to replace SAS if they were so minded?

Used to work for federal healthcare contractor, primarily in SAS. File conversion was a pain, but working in Stata would generally yield runtimes roughly an order of magnitude faster.

It helps a lot to think of SAS a as a set of tools, and then recognise what provides equivalent capabilities.

The DATA step follows conventions very similar to awk, though what SAS offers by way of data conversion (especially from mainframe formats) is hard to provide. The fundamental concept of iterating over the input stream is useful to keep in mind.

I've also found that awk is useful for writing SAS programs themselves. I bumped into this dealing with large data dictionaries and trying to make sense of them. Parsing those and generating the corresponding SAS statements, then seeing if the results made sense was far easier than coding by hand. (The dictionary, of course, failed to correspond entirely to the actual datasets, requiring mods, but the dev/test/modify cycle was far faster, and far more repeatable.)

For data storage, an RDBMS backend or SQLite is probably good, though you can also use various structured files (CSV, other delimited, column-formatted, etc.) Columnar + compression buys you much of the advantages of a SAS data set in terms of size.

For the various statistical and graphics capabilities, R, gnuplot, the JS plotting library, and some related bits. I'd really like to see what tools for generating dyamic SVG there are these days, as that's a graphics format that seems exquisitely suited to data-driven rendering.

For advanced quantitative programming: Python or related languages and libraries.

For report generation: these days I'd probably head to a lightweight markup language and Pandoc to create whatever format(s) I wanted. Or you could wire up dynamic Web output with the application engine of your choice.

For application design or creating commandline / back-end tools: whatever tools you prefer, ranging from scripting languages to compiled langauges. It's been a long time since I've worked with SAS, but its Macro and app development language (which I can't even remember the name of now) are both quite crufty.

The key advantage to SAS as I noted in an earlier comment is that many of the tool choices are made for you, in that that's what SAS offers you. You can go outside that set, though back in the day, few shops really seemed to be much interested in that. The problem is that the tool choices are limited, and any additional tools have significant costs.

Going with free/open options liberates you, but also means you've got to litigate the tool-choice battle. That seems to be a problem mostly at shops that continue to use SAS in part -- I don't know if it's sunk-cost fallacy or other dynamics, but there's quite often resistance at both management and developer/analyst levels to going to other tools (or had been in my experience). I found that and other dyanmics sufficiently frustrating that I largely stopped using the tool decades ago, with occasional (and regrettable) relapses.

This is of course the very activity that Compaq engaged in to unlock the PC bios capability and ignite a huge revolution.

This case is interesting and disturbing. As far as it goes, the plaintiff won only because 1> their license forbade using their product for reverse engineering and 2> the defendent tried to claim that reverse engineering would be a complete reconstruction of the original source code. A stretch, and it's understandable that they tried, but it's good they lost on that one.

On 1> I suppose the court correctly stood by contract law. The dreadful thing about this is that such terms could be enforceable. I would hope that the doctrine that prevents car manufacturers from forbidding you to use third party parts in your car would protect this and it's a shame the plaintiff didn't try. Also since this ruling, reverse engineering printer cartridges have thankfully been validated by the supreme court.

Sorry I don't remember the case that permits third party repair parts -- IIRC it was a lawsuit against Toyota and Volkswagen. Note that the car and tractor companies have recently tried fishing back with DMCA(!!!) claims.

The real problem is that prohibiting reverse engineering is an allowable license clause.

Imagine a hammer that was sold with a license that prohibited hammering a competitor's nails.

After you sell me something you should not be allowed to place restrictions on its use.

You are oversimplifying the situation. Two sufficiently sophisticated parties having more or less balanced bargaining power, as was the case in this situation, should be free to contract according to their will and good/bad judgment.

Of course, if you are a retail consumer who had no bargaining power and agreed to a standard form contract without any legal counsel then different rules should apply to you and in such cases courts will apply the test of unconscionability before enforcing any clause.

This just strengthens my cynicism on the general state of the law and the degree it generates justice. I'm hardly surprised anymore. Can anyone convince me that the judges in this case put more thought into this than the vast majority of the commenters here?

Even when I try to play devil's advocate, it's hard to justify. The fact that you invented something, should not give you eternal rights to exclusively profit from it. Even the warped patent industry knows that. The laws of innovation should be a balancing act between incentive for the innovator and incentive to society, and this decision is way out of balance in detriment of society.

So I have a question...

How if at all does this apply to API interfaces? For example, if someone makes an app that has a compatibility interface that works exactly like Amazon S3 while simultaneously competing with S3.

I know several people on HN run services like that. Where the code is their own but the API interface is flat out copied from the competition.

Only if you had signed up with AWS and agreed not to reverse engineer and you used the actual output of the APIs to compare to your product.

This is a contract dispute around the common sense term "reverse engineer", not a copyright or IP dispute.

I think it is safe to say that most of the people in that situation did sign up to AWS and AWS like just about every SaaS has a non-copy clause. Though it only has reverse engineering clauses on Microsoft software (Windows running on EC2) and some specific appliances.

Can anyone comment on how Octave developers test to see if they are compatible with MATLAB? It seems to me that Octave could run into this same issue.

So Instagram copied Snapchat features.

Say Snapchat mentioned in its TOS that you should not use this product to copy the features under reverse engineering and it proved that Facebook employees did it. Does Snapchat has a legal claim?

Only if Instagram used the Snapchat app to create those features. If someone told Instagram about the feature, or they read about it online, and then implemented it, they are not reverse engineering it.

And you would have to wonder how it would work for simple features, that can be communicated in a few sentences.

How long are these agreements valid for?

If you use the learning edition once, are you bound by it for a lifetime with no way to end the agreement?

Probably off-topic - One of the schools I studied in was a sell out for this trash of a company SAS. They shoved their analytics software down our throats, and I had a whole module where I was forced to use their shitty software.

I vehemently refused to use it and did all my analyses on Jupyter notebooks w/ Python. Simply because the software sucked so bad to the point of being unusable. For starters, it ran ONLY on windows and to complete my assignments, I had to use bootcamp on my Mac just for this shitty software. It was not a cloud based interface and it seemed like it was built specifically for Windows. And to add to the pain, it would randomly crash, throw out irrelevant errors (uploaded too large of a data file? Here's an error stating something about the file extension) and really looked like it was developed in the 90's.

I was blown away when I realized people were paying millions in just licenses for this crap. Over time, even the school realized everything was moving towards the cloud and started advocating the use of Jupyter more and more.

I for one would seriously hope this company burns down to ashes. Simply because they're sitting on top of millions and yet can't afford to make usable software for the amounts they charge and yet, still have the audacity to shove it down at people's throats. Fuck SAS.

There is a whole industry of software that is the same. Look at BMC, which I'm familiar with. Or just about anything Oracle makes. Yes, their databases are fast and powerful, but dealing with a lot of Oracle software is like going back to the 1970s.

As much as we like to rail on Microsoft (and it's well-deserved), companies like them and Apple, etc., have really made quantum leaps in usability that most enterprise software still hasn't made.

Based on my experience, SAS isn't an egregious example, it's typical.

The funny part is, SAS used to run on IBM mainframes, so most of the core computational libraries are highly portable. Probably just the GUI front end was tightly coupled to Windows.

Is it just me or would this have prevented the rise of the PC?

Looks like the EFF has to update their Reverse Engineering FAQ: https://www.eff.org/issues/coders/reverse-engineering-faq#fa...

This seems like a very bad decision. You can't make a c++ compiler that compiles the same things as Microsoft's c++ compiler? Software "licenses" that prohibit anything that a lawyer dreams of shouldn't be legal. An independent implementation of a program, where you merely used the original program to see how it worked when you used it should not be considered reverse engineering. Decisions like this only help large corporate America to preserve their monopolies.

Hmm, startup idea.

Reverse engineer SAS software, without using SAS software. Just rely on public documentation of SAS functionality/APIs, and test with SAS code shared from customers.

Or RE WPS' software after they went bankrupt. Sell it back to the founders of WPS for bonus points.

I'm not sure if Fruit of the Poisonous Tree, or a similar doctrine, applies here.

FotPS generally appies to evidence rather than copyright or contract, but I seem to recall this argument being made. Years ago....


This decision makes me want to donate a large sum to an open source project to make a free clone of sas software. I would offer $1000 toward that. This is a terrible decision and if we can't defeat it in this legal case, we should defeat a company that practices this way by legal, free, and independent software. And let's be sure not to use any sas software with that ridiculous license clause.

So if I'm Burger King, it's illegal for me to eat a McDonalds hamburger to see why people like them?

Well, I suppose Mcdonald's doesn't make you sign a contract before you buy their food, although I wouldn't be surprised if soon there will be TOS printed on the receipts that make it illegal.

But yes, that would mean that peeking in the kitchen to see how they prepare the food would somehow be an agreement violation...

No. However this situation is different: it's more like your Big Mac came with a license saying you weren't allowed to reverse engineer it (either by taking it apart and seeing what it was made of - 'reverse assembly' (per the article); or repeatedly comparing your burger to it in a series of taste tests - what this court called reverse engineering).

I think that's a bit off. The key sticking point for me is that they didn't use the _prod_ software version, they used a specific _learning_ version. This is like getting someone from Burger King hired into McDonalds to get trained on how to make a burger for the sole purpose of bringing that knowledge back to Burger King.

No. It's illegal to make a contract with McDonald's where they serve you a burger only if you don't try to recreate the recipe and then you do it anyway. Well they claim you did anyway.

tl;dr: court agreed "reverse engineering" does not mean to dive into someone code for the PURPOSE of making your copy or new copy of similar software better, but it simply means what it states: "you cannot reverse engineer (for whatever reason), period"

Pretty soon everything will be software-as-a-service, and can't be reverse engineered. They may even be able to detect attempts to reverse engineer and stop you.

Software might mean the complete destruction of private property as a concept.

> "Software might mean the complete destruction of private property as a concept."

I can see an argument made for removal of the concept of intellectual property as something that's legally protected. It sounds like you're wanting to say something stronger. What's the step into the material world?

If your washing machine and car are loaded with software, then the benefits and freedoms of ownership are basically non-existant.

This is already a serious problem. Look at the complaints against companies like John Deere. Once something is software controlled, you have a physical product with all the horrible things that are done in the software world, including draconian EULAs (enforceable or not) and patents on algorithms and basic math.

Sure, I can see how an argument could be made there. There's a lot of material goods that don't have software. Real estate, houses, food, just glancing around the room there are many things that don't incorporate software. How do you see these no longer being considered private property?

Well, deed restrictions (and property taxes) make it so that pretty much anything you can imagine can be "restricted" as you voluntarily enter into the agreement upon "purchase" of the property...

Its not much of a stretch to imagine common security/networking/etc type clauses in those restrictions as in many cases condo's sold in the US basically have similar situations where you agree to adhere to building wide decisions (on say which ISP services the building).

Then the servicing company comes along and starts to behave like John Deere and starts prescribing what TV/pc/whatever they will inter-operate with.

As you point out, there are already some limitations placed on other forms of private property. I don’t find this argument quite as compelling, at least with respect to the original premise of software destroying the concept of private property. There are restrictions which are independent and precede software, so one could suppose that software is currently the last vestiges of private property and SaaS and the like will finally complete the destruction of the concept of private property, but I’m not sure this has much weight with a lot of (or even most) people.

There are those who would argue that current encumberances have already destroyed private property; I think most people don’t find this to be the case, at least to the point of completely destroying it. We accept limits on freedoms and rights because we understand they need to be balanced with respect to one another. As absolutes they’re ultimately incompatible. Though this is now tending towards general ideology, so I’ll stop right here.

> Software might mean the complete destruction of private property as a concept.

Not "Software", but "SAAS".

How do you replicate the experience of a framework or standard without experiencing it? Now, I am not talking about looking at the machine code and whatnot, but the public API or UI.

So would mod. of old school setup work OK? A consulting company signs up/buys a product and creates specs/ test cases. Company takes specs test cases and creates a product.

I wonder if whatever is left of Netscape can sue Microsoft now over JScript...

In California, is there any protection for reverse-engineering?

> As part of its efforts to develop the WPS, defendant obtained a license to use the “Learning Edition” provided by plaintiff

This is a contract dispute plain and simple. It has nothing to do with California law and everything to do with civil procedure. You have a contract, and you claim and prove damages.

If you want to reverse engineer software, don’t enter into a contract with the maker of that software

In California, the employer can state that I'm not allowed to later work for a competitor. However, non-competes are not enforceable in California, unlike Washington for example.

Contract law has limits, and those limits differ on a state-by-state basis.

A contract cannot substitute itself to the law, unless the law permits it.

The law isn’t even involved in this case. It’s a contract dispute. It’s a civil case

The law stipulates what is and isn't subject to contract. Laws trump contracts every time, which is why contracts always have a clause "if any part of this contract is unenforceable..."

Anyone here have a client reverse engineer your work?

I worked at a company who's flagship product was simply rebranded and sold by a competitor in another country. Their version didn't evolve or keep up with our improvements. By the time I worked there, about ten years had passed, and they were still a major competitor.

Unrelated - but being able to handle front page HN/Reddit traffic should really be a basic requirement for any (mostly static) website today.

Yeah, sorry about that! My modest little blog is not used to the kind of traffic it's seeing today. Hope you were patient and hit reload.

Just out of curiosity, what's the traffic like?

Just passed 10,000 uniques at about 17:20 CST

How is this different from when AMD revere engineered x86 instruction set and made a processor that could execute that. I thought reverse engineering was specifically allowed legally.

I was in a road race where my car stopped running. My competitor was able to drive across the finish line because his engine kept running.

Later I had a second race where I defeated my opponent by driving with a full tank of gas.

The victory was overturned when a judge ruled that my use of a full tank of gas to generate similar performance was ruled “reverse engineering.”

I have a hard time understanding the idea that generating the same result without deriving how the other feature works is reasonably called “reverse engineering.”

At what point in your example did you agree with the competitor not to reverse engineer his winning method?

I feel like this example doesn't really reflect what happened in this court case.

Is comparing the output of two different systems “reverse engineering”?

Is modifying your output to be in par with a competitor reverse engineering?

My point is that the competition doesn’t know if SAS uses banana peels to generate their output- we only know that the the results are the same- and I don’t think that is a reasonable definition of reverse engineering.

The algorithm has not been copied- only the resulting output. Trade secrets remain protected.

This is one of of the biggest developments in the software industry ever because it incentivizes innovation (good for innovators, bad for copycats). It also fills part of the void left by a broken patent system. We all know many software companies are ripping off other companies ideas on a regular basis. In many cases it's big incumbents taking ideas from upstarts competing with them (example: Facebook via Instagram ripping off stories from Snap).

This decision should allow more competition from innovative newcomers and higher prices in software generally. Right now software is priced artificially low because very few vendors have any pricing power... because competitors can just rip off what they are doing. If that's not as easy companies with innovative ideas protected by strong ToS should be able to compete more aggressively and price their products much higher.

I believe you're going to see many companies put all their content behind an "agree" button.

This shift should also make acquisition prices go WAY up since companies will have to be priced more by the opportunity/IP rather than their replacement cost.

This is a big deal.

We all know many software companies are ripping off other companies ideas on a regular basis.

"Ideas" in the abstract aren't protected, except by trade secret laws. Patents are, at least in theory, supposed to apply to something more concrete than a mere "idea".

This decision should allow more competition from innovative newcomers

What? No it won't, it'll inhibit innovation by putting more power in the hands of large incumbents who employ many lawyers and have large war chests to fund lawsuits. No startup is going to prevail in a lawsuit against Facebook unless a miracle happens, because they'll run out of money and close down before the case is ever settled. That is, if the "chilling effects" of this kind of ruling doesn't prevent them from ever getting started in the first place.

This shift should also make acquisition prices go WAY up since companies will have to be priced more by the opportunity/IP rather than their replacement cost.

This also works to inhibit innovation, as companies can lock out competitors via legal machinations, as opposed to needing to innovate continuously.

This is a big deal.

Maybe. It was a circuit court decision, so (in the US at least) to the extent that it establishes any precedent, it's only strictly applicable in the 4th circuit (for now).

It sounds like you are like many others in tech who believe everything should be open source. Good for you but some of us need to make money off of our life's work in innovation.

Time will tell, I view this in a hopeful way as a shift in direction.

I think companies that invest in innovative products big or small should be able to defend those innovations against being ripped off.

Yes, fights over this will be resource intensive but there are ways to fund expensive litigation if winning is plausible. And of course the expense of litigation touches on all kinds of unrelated problems.

"This also works to inhibit innovation, as companies can lock out competitors via legal machinations, as opposed to needing to innovate continuously."

You're flat out wrong here. Companies will need to create their own innovations rather than ripping off others. This will give power to the the people actually innovating and encourage companies to invest in their own R&D.

RE the 4th circuit, yes it's not the Supreme Court but it's a big decision in the right direction in my view... and suggests this and/or related issues may be heard by the supreme court.

Ultimately software is not the open source cooperative utopia that many people like you hoped for. It is a ruthless for profit marketplace, and if you ever want to give the guy in the garage a chance you have to give him a mechanism to protect his ideas... and the patent system is not that mechanism right now. Perhaps terms of use will be?

Maybe not, in any case the status quo is letting giant tech companies power and influence grow without limits... and that needs to change.

It sounds like you are like many others in tech who believe everything should be open source. Good for you but some of us need to make money off of our life's work in innovation.

I'm not a FSF zealot or anything, not somebody who abhors the very existence of proprietary / closed-source software. That said, I do prefer OSS / Free Sofware in the general sense... but the rub is, software being F/OSS doesn't mean you can't make money from it. So I'm not really sure where you're coming from.

Maybe not, in any case the status quo is letting giant tech companies power and influence grow without limits... and that needs to change.

But this ruling benefits the tech giants at the expense of the "little guy". How many startups already never come into being because of fears of being sued by AmaGoogFaceSoft? And consider that most "innovation" is an incremental improvement to an existing "thing" and not some whole new thing cut from whole cloth. If you can't reverse engineer / clone products made by AmaGoogFaceSoft, Oracle, IBM, SAS, etc., it's going to be even harder for smaller companies to contribute their innovations.

That depends on the what the meaning of "ripped off" is. What is "ripping off" and what is legitimate competition?

This question has been the subject of many lawsuits for several decades and isn't going away any time soon.

I agree with you that the power of the large companies remains largely unchecked and that that's a bad thing.

You seem to think that you can not sell open-source software. Yet all the linux based companies are doing that for decades now. There are many other examples.

They sell support really, the software is free.

This is an dangerously simplistic analysis.

The world doesn't divide into "innovators" on one side and "copycats" on the other side. It would certainly be convenient, but it's simply not the case, especially when it comes to developing software.

How would you call a company developing a smartly enhanced version of their competitor's product? A "copinovator"?

And by the way: I don't see why anyone would want "higher prices for software" (which seems to be one of your goals).

This only looks good if you narrow your vision down to the software you're trying to sell, ignoring the incredibly larger amount of third-party software you're already paying for.

Yes it's simplistic because it's a HN comment not a a doctoral thesis, but that doesn't mean it's wrong. The fact that most software is very cheap favors companies/VC's that already have money... because it means you have to go for scale over margin. That's a game for people with deep pockets.

Example. Joe Smith builds innovative software. He sells this to 10 local businesses for $5K/mo each. He is able to take care of his family, hire a couple folks and live the american dream... no VC required. Then someone goes to his website, signs up, studies what he's done and copies this innovative software and sells it for $2.5K/month profitably because they don't have to incur the R&D costs or the lifetime of work experience Joe needed to come up with his innovations. Joe is forced to cut prices dramatically or be out of business. Joe's default path now is he must grow to $200K/month at all costs... sell a portion of his business to VC, then try to grow it to millions a month. Then sell more to VC. Rinse, repeat. This is nuts. People should be able to have innovative businesses that aren't copied and don't have the aim of scaling to infinity to enrich VC's. This is important because unlike other businesses such as construction the marginal cost for providing software is so close to zero you can (and many companies do) round it down to zero.

I don't care if any of you agree with me. ...but ask yourself... is the tech landscape serving the guys in the garage right now? If not why not? I believe part of the reason is there is no strong protection for IP anymore. This case was an example of an egregious rip off and the offender was rightly penalized to the tune of $80m, then that penalty was upheld by an appeals court. I think that is a just outcome based on the limited info I have about it... and I am encouraged by the precedent. I hear many of you disagree, and you're certainly entitled to your opinion.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact