Attack of the clones: Oracle's latest Red Hat Linux lookalike arrives For each new Red Hat Enterprise Linux release, a new version of Oracle Linux is never far behind, and RHEL 7 is no exception. Red Hat shipped its latest version in June, bringing such features as support for Linux Containers, XFS as the default file system, improved integration with Microsoft Active Directory domains, and more …
Just remember they're ripping off Red Hat Linux lock stock and barrel. "Ah", some apologist might say, "the licence allows them to". It sure does. It doesn't make them look any less hypocritical.
I do wonder who in their right minds would pay them for support though. If you want to pay for support why not pay it to the company which actually develops the distribution (or the package maintainer itself) instead of the barnacles hitching a ride.
Actually, as an ex-Oracle employee who retains a certain amount of disdain for the company, it is all about the license.
By your logic, they shouldn't be relying on Intel's hardware technologies, just because Intel sell chips where they say they can you can run third-party software on it.
It's all in the licensing.
> "Ah", some apologist might say, "the licence allows them to".
I understand and agree with the point you are making, but does the GPL really require Redhat to release their source code to the *public*? I thought the only requirement was to release the source to *those using the binaries*, i.e. Redhat customers. The rest is an act of generosity by a relatively small behemoth (if you see what I mean). You don't see SLES source available to the public and you don't see clones so far as I am aware. I'm not sure it is the same code as OpenSUSE at all.
Oracle Linux's desktop will come with LibreOffice rather than OpenOffice. I take some consolation from the irony.
I imagine the support is 'bundled' to some extent with other products for a total price. They've kept it going so it must pay.
I understand and agree with the point you are making, but does the GPL really require Redhat to release their source code to the *public*
Yes.
That's section 3(b) of the GPLv2.
I thought the only requirement was to release the source to *those using the binaries*
No. This is often believed, but isn't true.
The only time a GPL provider can restrict his requirement to provide source to those that get the binaries from him are when he performs a Section 3(a) distribution - which requires source to *accompany* the binaries. RH doesn't do this - and nor do most people.
You don't see SLES source available to the public
https://www.suse.com/download-linux/source-code.html
Vic.
They can, but they would have to change how they deliver the binaries, such that the source is always delivered with them.
Even that would make little difference to anything - every single recipient of that combined source/binary package is entitled to redistribute it under the licence terms.
Even then Oracle could just buy a copy of the binaries.
Or ask someone else who has.
Vic.
No.
Source only has to be produced when requested by the user. If you aren't a user, then Redhat doesn't have any obligations to you and never did.
This is how a company that creates GPL based derivative works for internal use doesn't have to give YOU a copy of what they have done. Rights to the source are only conferred upon the user of the program. If you aren't a user, then you're irrelevant.
The "loophole" here is that there's nothing preventing a user from sharing.
ANY Redhat user gets the same rights to the programs in question that Redhat does.
No.
Yes.
Source only has to be produced when requested by the user.
Source has to be produced when requested by *** ANY THIRD PARTY ***.
Don't take my word for it - go read the licence You're looking for section 3(b).
If you aren't a user, then Redhat doesn't have any obligations to you and never did.
Absolutely, fundamentally. 100% incorrect. Read the licence. It disagrees entirely with what you say.
This is how a company that creates GPL based derivative works for internal use doesn't have to give YOU a copy of what they have done
Wholly internal use does not constitute redistribution. But if they do redistribute, they must do so under one of the clauses of section 3. Pick one - the effect is much the same...
If you aren't a user, then Redhat doesn't have any obligations to you and never did.
Totally incorrect.
From GPLv2 section 3:
You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also ... Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange
Do you see the phrase "any third party" ? It's important. It means exactly what it says - *any* third party. It does not matter whether or not you are a RH client - *any* third party is entitled to a copy of the source code of anything redistributed under 3(b). And IME, everything RH reditributes is under 3(b).
Rights to the source are only conferred upon the user of the program. If you aren't a user, then you're irrelevant.
Seriously - read the licence. It disagrees with you.
Vic.
The use of GPL in a commercial product obliges the company to supply the source upon request. These days most companies would normally throw the tarballs up on a web server and let people click the link to get them.
Note of course that a Linux dist isn't just GPL, but dozens of open source licences with disparate obligations. So potentially RH could withhold parts of a dist (e.g. BSD licenced stuff) if they felt like it though it would cause bad feeling in the open source community if they did.
They could also dual licence something really important that they developed themselves to stop the likes of Oracle leeching off it but Canonical got burned by such practices so that might be a non runner.
What they have done is stop releasing discrete patch files for their fixes & changes. Instead they concatenate everything into one large patch. Presumably this is to frustrate Oracle's support efforts.
The use of GPL in a commercial product obliges the company to supply the source upon request.
The commercial nature of the product actually makes little difference - only that binaries and object files may be redistributed unmodified under section 3(c) if it is non-commercial. This is merely a convenience - in practice, it makes no difference to the distribution of source, because the Section 3(b) promise under which is was initially distributed holds true for everyone, not just the initial recipient.
So potentially RH could withhold parts of a dist (e.g. BSD licenced stuff) if they felt like it though it would cause bad feeling in the open source community if they did.
Only when those BSD-licensed bits do not form part of a larger, GPL-licensed program.
But more importantly, RH *gets* open source. That's why they make money - they're not trying to hoodwink anyone or run scams. They stick to the spirit of the license as well as the letter.
They could also dual licence something really important that they developed themselves to stop the likes of Oracle leeching off it
Dual-licensing wouldn't help - either license may be used. And if neither license is GPL-compatible, the code cannot be used in a larger GPL-licensed piece of code. That's unlikely to be of use to RH...
But all this is academic - Oracle really isn't a problem for RH. They're an annoyance, no more.
Vic.
Nah, plenty of reasons to get Oracle support:
- you have a surfeit of cash
- your IT folks need seasoning so best to get a support provider that doesn't hold their hand, doesn't understand their own product and just wants to do their thing so that their case support metrics look OK (i.e. for the nth time, can you repeat, again, your environment details so I can put you as 'awaiting customer response')
- Oracle Linux is unbreakable, the ads say so.
- Larry needs a new boat
- Pesky Red Hat, who wants to claim the moral high ground because they worked on it. Oracle believes we should all share, as exemplified with sharing Java's APIs.
I'm surprised that an entire El Reg article about Oracle Linux 7 failed to mention CentOS 7 at all. The major CentOS 7 devs are now employed by Red Hat and I suspect CentOS 7 is actually more compatible with RHEL 7 than Oracle Linux 7 is (e.g. don't Oracle tweak the kernel somewhat?).
I can just about see the argument for large database shops who already pay millions for their overpriced Oracle licenses to go with Oracle Linux, but I'm not sure about anyone else going for it. I suspect large businesses not running Oracle would prefer the "original" Red Hat support and smaller businesses would opt for CentOS since it's the most compatible RHEL clone out there (and to be honest, support usually isn't worth paying for, especially when both CentOS and RHEL bug trackers can be used for free).
Exactly, the difference is in their kernel version (they take newest one from kernel org, apply patches and then claim that everything is compatible with RHEL which validates against its own kernel). Which is fine and dandy, but I am not so sure that for instance the kernel has the same reliability on, say, HP servers... And ksplice (the only potential benefit) isn't really worth the risk for majority of usecases. And that java abomination that is OEM for management? No, thanks.
Without paid support you don't have access even to patches, which makes CentOS better value for money as you get patches for free. And 100% compatibility with RHEL as a bonus.
From my experience the support Oracle provides is nowhere near as good as Red Hat and we've had no end of compatibility problems with their UEK kernel (including one memorable issue where the kernel was writing so much debug to the log files it was essentially DOS-ing itself...).
Smart folks!!!
I know of an SMB that ended up locked in hard (Apache/Weblogic/OracleDB/OracleLinux) that had a huge support bill with oracle, and ended up paying me to come in and fix the issue. The competing (and I'm 100% sure that it was an ego-fest) support groups at Oracle could not untangle their own finger pointing. I spent 14 hours untangling things and presenting the solution that those teams could not coordinate over 21 days of issues. Considering the level of skills in those teams, I really don't understand why they could not pull back, regroup, and package the same up for their client.
Redhat has been utterly impeccable in their support on my primary employment. There are only 2 cases where I've had to hound them in over 10 years of the contract.
I wholeheartedly agree - my first action on an Oracle Linux system is to take the UEK off with a blowtorch.
It REALLY makes no sense on 32-bit, since they refuse to support the UEK in this environment AT ALL, which you will discover after you have worn out your phone and keyboard with their tech support. At the risk of (ab)using a cliche, EPIC FAIL!!
Does anyone know if I could I study towards the RHSA and RHSA II exams using Oracle linux without issues? I want to familiarise myself with Red Hat fully before going ahead and doing the courses / exams, but I don't want to pay for RHEL first. I take it with it being just a recompile of the code there shouldn't be anything missing in their distro that might trip me up in future?
Thanks
Go for CentOS instead, it's almost exactly RHEL (there's a big tie up between Red Hat (company) and the CentOS developers that was announced a few months back) but with branding removed. You can see a list of what they remove/modify here: http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7#head-d58ad86f1b5399bb36755532321b1df4f242a88c
Oracle Linux do things like tweak the Kernel etc.
Our regional data center runs 10.2.0.5 db on OL5. We also run Oracle RDB on VMS. I've got a big pile of CSI numbers.
And yes, I'd rather try out OL7 on my home machines than CentOS.
If Red Hat had a free version for dev/test where I could enable support if I chose, I'd be more sympathetic. They don't, and I haven't used their products in many, many years.
It's a Redhat clone for people who want either:
1) No support.
2) Support so poor words do not exist to express the futility of raising a request.
Point 2 is from repeated painful experience, we've had solutions that don't match the problem, syntactically incorrect solutions, lots of infinite circles, requests for information we've already explained doesn't exist (and that would have been useless anyway), and so on. In fact I can't think of a single example where we didn't eventually fix the problem ourselves. Sometimes their support people aren't even aware of known issues the engineering ones are already fixing.
And that's before you go near UEK. Minor patch releases can be things of real fear, like the time they turned on by default a flag which makes RAC crash randomly.
Utterly horrendous, my sympathies to anyone else who suffers this company.
"They can keep their existing RHEL servers in place and simply switch to Oracle support, and they can install RPMs from Oracle's repositories on their RHEL servers without a hitch."
It's worth nothing that - unless you want to pay for support twice - this would violate the all-or-nothing clause. If a RHEL system is out of support you need to shut it down or otherwise all of your other currently employed RHEL instances will be out of support too. So no, no can't just leave the RHEL installation in place and switch to Oracle support.
You do get patches with OL for free. Just configure your yum.conf to connect to Oracle's public yum repository. Or perhaps it's already by default.
I used Red Hat in the old days (still have a moldering RHCE) but I exclusively use OL (and Ubuntu) now. The main differences really are KSplice and support for the very large engineered systems (e.g. optimized IB drivers, optimizations for very-large-memory and very-large-CPU-count machines).
Now if I was running a little startup, I'd still run OL and use their public yum. Do I get anything over say CentOS? probably not, except the warm fuzzy feeling of having "enterprise grade support" for $500 per server per year (or free if I have on Sun/Oracle hardware with a support contract) if I needed it.
I know of large telecoms customers who have switched from RHEL to OL simply because RH charges a per-box fee, which these customers intensely disliked. Of course said customer also had a $$millions$$ Oracle ULA.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
