Hacker News Reader

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.

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.

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.

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.

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.

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

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.

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.

> 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.

See: https://en.wikipedia.org/wiki/Clean_room_design

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.

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.

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

It's apparently in directive 2009/24:

https://en.wikipedia.org/wiki/Reverse_engineering#European_U...

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

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.

http://eur-lex.europa.eu/legal-content/EN/TXT/?qid=143505754...

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:

https://en.wikipedia.org/wiki/SAS_Institute_Inc_v_World_Prog...

Does this help you?

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

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

https://en.wikipedia.org/wiki/SAS_Institute_Inc_v_World_Prog...

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

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

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.

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?

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

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...

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.

http://www.decalage.info/files/JCV07_Lagadec_OpenDocument_Op...

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.

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.