Firstly, it's perfectly aligned with the world of proprietary software. Oracle is probably more protective than the other vendors, because the restricted access to the source code is at the heart of their business model. But none of the vendors I'm aware of is very keen on reverse engineering.
Secondly, the reverse engineering is prohibited for ages - it's not that it was added to the license agreement yesterday. And there are other restrictions (e.g. on publishing benchmark results), so rather that "Oracle is bad" I'd say "people who sign accept license agreements without reading them are morons."
And thirdly, the article is spot-on about usefulness of the reports generated from a reverse-engineered binary. I've seen shitloads of such reports, usually generated by some clueless consultant with the sole competence to run an automated tool and print the result. So it's probably (at least partially) a protection against a flooding the support with bullshit reports.
And it's also true that many of the companies don't have proper security rules (like encryption, identity or password management, network security) yet pay some consultant for reverse engineering one of the components. Because it's easier to spend a large amount of money than evaluating and rebuilding their infrastructure.
So while I dislike Oracle, you can't blame them for everything - the customers are the ones choosing the vendor. If you happily accept their license agreement, you can't later complain "but we want to do reverse-engineering" no matter how many MBA titles you have. If you want such freedoms, ditch Oracle and proprietary vendors in general. That's what open-source is for.
That one is hugely dependent on jurisdiction. In place I live the right to reverse engineer is codified into law and can't be waived by an EULA.
Not in some countries. Oracle would be against the law in that case, that's why people are unhappy.
"It is not considered infringement of the copyright in a work referred to in Article 10, first paragraph, under 12°, if a copy is made of that work and the code is translated, in the case that these acts are indispensable to obtain the information which is necessary in order to achieve the interoperability of an independently manufactured computer program with other computer programs, provided that:
a. these acts are performed by a person who has gained access to lawfully obtained copy of the computer program or by a third person authorized by him;
b. the data that are necessary in order to achieve the interoperability, are not alreadyquickly and readily available to the persons referred to in point a;
c. these operations are confined to the parts of the original computer program which are necessary to achieve interoperability."
Repairing errors is part of another "artikel", http://wetten.overheid.nl/BWBR0001886/geldigheidsdatum_30-04...,
"Unless otherwise agreed, is not considered an infringement of the copyright in a work referred to in Article 10, first paragraph, under 12°, to reproduce the work by a lawful acquirer of aforementioned work with its intended use. The reproduction referred to in the first sentence, which takes place in the context of starting up, visualizing something, or correcting errors, can not be prohibited by contract."
That correcting errors by the customer cannot be prohibited by an EULA is something Oracle probably won't like. :-)
The correct way to treat these reports is to review them (after all, who knows...) and try to educate those customers who send you bogus reports: explain why they're bogus, why reverse engineering doesn't usually provide good leads, explain them what easier steps they can take for additional security, and maybe remind them about that EULA. This can be done on an individual basis, politely, and Oracle, who seems to employ half the salespeople in this world, certainly has the resources to do so. If they can call me every two months to remind me about their great offers, they can write the standard answer that almost every such report warrants.
But no, instead they chose to dump a load of shit in the form of this blogpost:
1. It's written in the kind of condescending tone that makes you want to punch your interlocutor in the face. Such as: " That said, you would think that before gearing up to run that extra mile, customers would already have ensured they’ve identified their critical systems, encrypted sensitive data, applied all relevant patches, be on a supported product release, use tools to ensure configurations are locked down – in short, the usual security hygiene – before they attempt to find zero day vulnerabilities in the products they are using.". Surprise, surprise: a lot of people who start reverse-engineering binaries are either a) extremely security-conscious people, who, yes, already do those things, or b) extremely good programmers who work for people who -- again -- already do those things! There are exceptions, of course, but assuming that everyone who submits such a report is one of those imbeciles who dreams of Matrix hackers but runs a company where no computer has an antivirus installed is naive.
Or: "there are a lot of things a customer can do like, gosh, actually talking to suppliers about their assurance programs etc.". This sort of crap belongs on a cocky teenager's blog, not on a serious company's website.
2. It's all the more insulting to whine about it when the subtle message you're trying to convey is that zero-day threats aren't that a big deal: "And in fact, there are a lot of data breaches that would be prevented by doing all that stuff, as unsexy as it is, instead of hyperventilating that the Big Bad Advanced Persistent Threat using a zero-day is out to get me!". Yes, it's no problem to state this when you're some random blogger. It is a problem to state this when you're CSO of the company famous for producing the one plugin that's recommended to be disabled by default.
3. Because the argument about the license agreement is childish. After explaining in detail how, even if you were right, you're getting a threatening letter about the license agreement, a requirement to destroy all proof of reverse engineering and so on, she goes on to throw this gem:
"The main reason is that, when I see a spike in X, I try to get ahead of it. I don’t want more rounds of “you broke the license agreement,” “no, we didn’t,” yes, you did,” “no, we didn’t.” I’d rather spend my time, and my team’s time, working on helping development improve our code than argue with people about where the license agreement lines are. "
Well how about skipping that debate and fixing your fucking code, eh?
To put it in the same line as her argument, there are a lot of things Oracle can do in order to reduce the amount of false positives they get, such as fixing their disastrous security track record, improving their communication with the security community (no, blog posts like these don't count as communication for the same reason why hanging out a "fuck you" banner outside your office doesn't exactly count as better communicating with your colleagues, either) and so on. If people had better reasons to trust Oracle, there would be a lot less effort of this kind, too.
4. The analogies being used are demeaning to anyone who doesn't work in sales. Like this:
> Q. But one of the issues I found was an actual security vulnerability so that justifies reverse engineering, right?
> A. Sigh. At the risk of being repetitive, no, it doesn’t, just like you can’t break into a house because someone left a window or door unlocked.
Someone missed their first tech evangelism class, where they use that analogy for exploting, not reporting vulnerabilities.
Is it also wrong to call someone and tell them they left their door unlocked because their dog ran into it and it opened?
The whole things reads like "you guys are like the worst customers ever. We're smarter than you, we have lawyers and we knowz securitiez. Now shut the fuck up."
Sales people are unusable for educating customers, and they're busy with using Licensing Breach Notices to boost sales of cloud services anyway (http://thestack.com/oracle-breach-notice-cloud-services-1007...).
I do agree with you that the blog post seems written in a bit condescending way (it's difficult for me to judge, as I'm not a native speaker).
And I do agree that some of the arguments are misleading - the fact that many breaches are caused by lack of basic security practices does not make zero-days insignificant. And the "assurance programs" guarantee nothing if you fix the issues poorly (nice example from DEFCON 22: https://defcon.org/html/defcon-22/dc-22-speakers.html#Litchf...).
What I perfonally find the funniest about the whole "reverse engineering prohibited" clause is that the bad guys don't give a shit - they'll reverse engineer it anyway, because no one will find out. So the only "victim" is the customer who accepted the licensing agreement, and it does not matter if the purpose was to lower the number of reports or protect the source code.
But I'm still astonished people are surprised by the stupidity of Oracle licensing terms. Bullshit like that blog post is actually one of the main reasons why I stopped working with Oracle products and went full open-source.
Because if they don't, stuff like this happens: they get blamed for any trivial data breach that happened through some of their programs -- even if the problem wasn't that it sucked, it was that the password was admin123.
It's not glamorous and we can all agree that, as long as we're talking about responsible users, it shouldn't be Oracle's job to do this kind of education. However, exploiting users' ignorance is an integral part of their business model; they're consciously targeting them -- it's up to them to deal with all the consequences that brings.