> The only definition of "reverse engineering software" that I use

Uhm, no, that's far too narrow. Reverse engineering is any kind of introspection into a device in question, designed for obtaining any degree of understanding of its inner functioning.

What you're talking about is called "decompilation", and it's not even among the most useful reverse engineering techniques.

People have different understandings of words, so I'm not claiming there is one, universal meaning of "software reverse engineering." However, here is the definition some researchers came up with: "Reverse engineering is the process of analyzing a subject system to create representations of the system at a higher level of abstraction. It can also be seen as "going backwards through the development cycle." (from https://en.wikipedia.org/wiki/Reverse_engineering#Reverse_en... , original publication: http://win.ua.ac.be/~lore/Research/Chikofsky1990-Taxonomy.pd... )

edit: I just wanted to explain to you which definition I was using earlier, so that you could understand what I meant better.

That quote is quite different from the definition you're using.

Your definition is not what anyone else uses, from what I've seen. You don't have to use the same definition, of course, but be aware that unless you clarify what you mean, you're going to be creating a ton of confusion.

I don't see how it is different. A "higher level of abstraction" means progressively higher-level versions of source code. Binary->machine/assembly code->C++ code for example. Each step involves reverse engineering. Simply disassembling/decompiling a binary is not really sufficient to be considered "reverse engineered". Someone needs to analyze the output of these tools to create reverse-engineered output which is ready to be modified/extended/investigated.

It does not really matter how we are interpreting the term "reverse engineering". What matters is how it was used in the OP article, in the EULAs and the national laws. In the article it was clearly applied to a binary analysis part of pen testing efforts by the Oracle customers, so this is what we should be discussing here.

I disagree. The author implies several times that the main issue, and the reason for the ban on reverse engineering in the agreement, is protection of intellectual property (source code). People may do other types of vulnerability testing, but the piece that Oracle is concerned about is trying to discover their source code (for example, by using static analysis tools...which analyze some version of source code).

Many static analysis tools are working on JVM bytecode level, and there are quite a few for even the raw x86.

I would consider that "some version of the source code".

However, this is one of the reasons I disagree with Oracle on the matter. There are tools which actually can and do find issues at this low level (even if there are false positives), and running those tools can be part of many reasonable verification efforts. I think static analysis at the bytecode or assembly code level still counts as analyzing the source code, but I think it makes sense to do that in many scenarios.

> The only definition of "reverse engineering software" that I use is this

That's the definition of decompiling not reverse engineering. The original IBM BIOS was reverse engineered by two teams: one which read the disassembled binary and wrote a written specification and a second team that took that specification and wrote code.

What you just described agrees with my definition. The ultimate goal of both teams was to end up with usable source code that is likely to be close or identical to the original used to create the binary. There is a slight difference in the IBM BIOS project in that, I think the goal was to create code which could not be claimed to infringe on the patents/copyrights of IBM. That last bit is an extension of reverse engineering, i.e. they reverse-engineered the binary (which took both decompilation and analysis) in order to create code which matched the same specification and wasn't outright "copied".

See the previous reply I made for links to discussion of what is usually meant by (software) "reverse engineering." But, like I said before, there probably is no "universally correct" definition, I am only describing it so that my previous comments can be understood fully.

You are right, that does agree with your definition. But, in my opinion, the reverse engineering was done only by the first team. They took the binary and constructed an understanding of the code. The second team just did basic software engineering from a spec. Your definition requires both teams and that's where your definition is too narrow.

This isn't entirely accurate. There are restrictions on the legality of decompilation in Europe. The main one being that "...decompilation must be necessary to achieve interoperability with the target program or other programs. Interoperability information should therefore not be readily available, such as through manuals or API documentation."

So, decompilation in order to check for security vulnerabilities or to modify the function of the software for non-interoperability reasons do not appear to be covered.

disclaimer: I don't live in Europe and am not familiar with the most up-to-date software laws there. This is from the following source: https://en.wikipedia.org/wiki/Decompiler#Legality

> if I buy a software, and it does not run on my system,

This would be one example case. As I posted in my comment.

Integration can also just mean for future possible integration – for example, if someone writes a tool that can read a file format, I may decompile it to implement a tool to read the same file format.