With 7,000 companies paying for support contracts for Oracle's Enterprise Linux clone, the software giant is, whether anyone likes it or not, a player in the Linux racket. And Oracle just made its competitive position in the Linux space a lot more interesting with the acquisition of a startup called Ksplice. Ksplice is short for …
What have I missed?
Maybe I'm missing something, but Oracle have bought (and paid money) for something which is distributed for free under the GPL v2 and other open source licenses?
What's the point in buying a company for a technology which anyone else can fork and use themselves for free?
I'm sure I've missed something... what is it?
> What's the point in buying a company for a technology which anyone
> else can fork and use themselves for free?
What does the clever man do? Buy the recipe how to make good beer? Or employe the talent behind that beer recipe?
Source code is.. well, source code. The savy that went into making that source code is worth a lot more than the source code itself.
Re: What have I missed?
> I'm sure I've missed something
Anyone redistributing the GPL version of Ksplice must redistribute under the GPL.
By buying the copyrights, Oracle have removed that requirement from their distributions.
That sort of thing has a nasty tendency to occur just before the owner changes the licence to something more proprietary :-( Such a change would allow Oracle to do something incompatible with everyone else and not release their source.
Of course, Larry might just have had an altruistic moment and decided to put some cash towards a startup that really needed the assistance...
 No, of course he didn't.
This says it all
Coekaerts added that Oracle does not intend to support RHEL or SUSE Linux Enterprise Server
If any still needed to 'get it' that Oracle is totally against FOSS then this must the final nail in that coffin.
Their current modus-operandi in the Linux space is IMHO to take as much 'stuff' as they can get and make it proprietary thus increasing their USP in the Corporate Linux Space.
We use Oracle RDBMS where I work and we are increasingly moving away from Solaris to RHEL. We also use JBOSS pretty heavily. Oracle sent in a sales team recently to persuade us to use the entire Oracle stack. Even with our so called Global Corporate discount their prices made us weep. They were more than 100% higher than IBM was quoting for their WAS stack. In the OS space it was just the same. The sales team were pretty miffed that the used CentOS everywhere except for UAT & Live systems.
At one point the head of the delegation said
'We won't support any of our products on any version of Linux except our own with 18 months so we had better sign up now as it would cost a whole lot more if we delayed."
Once our collective jaws had stopped hitting the floor, the Oracle team were politely shown the door. A phone call from our IT Director to their local head honcho got what added up to a 'No Comment'.
Needless to say we are evaluating our use of Oracle products. This may have been the final nail in their coffin. We use Oracle RDBMS on HP Superdomes.
I am pretty safe to state that Oracle's days are numbered. As soon as we can move SAP from Oracle to something else I am sure we will.We are just starting a major SAP upgrade so the time is right.
Bye Bye Oracle. I wasn't nice knowing you.
Now where that IBM's Salesmans phone number?
"that" actually does not say it all
The Customer Letter from WC (http://www.oracle.com/us/corporate/Acquisitions/ksplice/customer-letter-430127.html) does not say anything about the actual support for Oracle Database Server or any other product on RHEL. It is restricted/specific to KSplice itself.. "Oracle does not plan to support the use of Ksplice technology with Red Hat Enterprise Linux or SUSE Enterprise Linux."
Of course, there is still no support/certification for Oracle Database Server on RHEL6 but this is no different from OL6.. And the silence is deafening.. but I guess Oracle is not going to take the route you are describing. If they do, then it will be (for them) significantly more severe "self-inflicted injury" then the IA64 play.
code may be GPL but they have a patent
From memory, I recall their website mentioning patents. You can have the code, just be prepared to be trolled...
Dividing by zero
What happens if you patent something *and* GPL it?
Seriously, I think reading your comment just induced a small aneurysm. Where's my Aspirin?
There is no conflict!
The GPL is a license about being allowed to get and use the source code.
The patent is about actually letting the code run, in which case you would be trampling the roses on someone's homesteaded property in the space of ideas (or something similarly illogical and deluded from the 104-Fahrenheit-feverish world of IP advocates) and this means they can sic the state's law-enforcement apparatus on you.
Btw, it's not good to take aspirin in case of aneurysm.
You have a bad memory
Their website doesn't mention patents and the word isn't even present in their white paper.
> What happens if you patent something *and* GPL it?
GPLv2 has an implicit patent grant both in Section 0 ("The act of running the Program is not restricted") and in the Preamble ("To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all"). That stood for some considerable time, and was considered by many to be sufficient.
GPLv3 changed this to an explicit patent grant (all the above, slightly modified, plus the downstream licencing in Section 10, the whole of Section 11, and some odds & sods besides).
Oracle's seeming attempts to convert this to something non-GPL would complicate matters a little (Oracle may distribute their own code how they like, and are not bound by the terms of the GPL in respect of it unless there is anything there they do not own), but they'd get hit with an "unclean hands" defence (amongst other things) if they even thought of trying patent games with formerly-GPLed code
The GPL v2's "implicit patent grant"
An implicit patent grant is up to a trial to find as, by definition, it's not in the GPLv2 (if it was, it would be explicit). Please correct me if I'm wrong here, but this hasn't been tried, has it? That makes it nothing more then a legal theory (as pleasant a theory as it may be).
This is why a few companies which had GPLed code which they also had patents in, included a separate patent license. This is also why the GPLv3 got an EXPLICIT patent license.
Personally, I almost would like to see all this software patent nonsense really blow up. It would be worth it to get rid of these silly math patents.
Re: implicit patent grant
> Please correct me if I'm wrong here, but this hasn't been tried, has it?
I'm not aware of any court that has had to rule on it - but then, the GPL has rarely gone near a court; infringers, when shown the alternatives, have invariably settled out of court by complying with the licence and taking steps to prevent further infringement.
If I get a licence from you that says "you may use this software", you're going to be hard-pressed to find a legal jurisdiction that finds that statement invalidated by a patent whose use is required by the licence to be freely usable by the code or not usable at all...
> This is also why the GPLv3 got an EXPLICIT patent license.
It is. The jury's out in terms of whether or not the explicit grant was *required*, but is does seem to be a sensible precaution in the face of ever-more bizarre patent grants and excessive litigation in a land where it is ruinously expensive to *win* a case.
> It would be worth it to get rid of these silly math patents
 In those rare instances where a court has actually become involved, the GPL has triumphed in every case of which I'm aware.
Who needs it?
If you're running a virtualized cluster, do you really need this kludge to patch a running kernel?
Telcos do. When you're looking for 6-nines availability (5 minutes downtime in 10 years) you can't afford to reboot. Ever.
Single point of failure?
If you are running a telco that is all well and good, but in these days of IP telephony and cheap hardware redundancy, you can take down one of your triply replicated servers to reboot and still have a failover option.
Disclaimer: yes I have worked for telcos... (We were running at zero overall downtime over 4 years, although parts were down for an hour or more it never impacted service.)
Re: Single point of failure?
Avoiding service outages isn't the telco's biggest priority.
Avoiding billing outages is....
Just because your virtual OS is running as a VM doesn't mean you don't have to reboot it. A great many applications are still very stateful - you can't just pull a host out of a pool.
Moreover, if you are selling shell logins or zones then live kernel patching is a great thing to have.
Of course, rootkits have been doing this for donkeys
RE: hot patching
"Telcos do....." Telcos don't use Oracle Untakeable Linux for exactly the 6-9s point mentioned. At least not any I know, but, if you know better, please do supply the details of some Outer Mongolian telco that is trusting their billing system to it.
Re: hot patching
> you can't afford to reboot. Ever.
IMO, if you can't afford *any* reboots, you've got insufficient hardware to cover your SLA...
I tried Ksplice some years ago. I see it as a very interesting project - but I wouldn't use it on a production system. I found it way too complex to be certain of success (although my trial splices did work). I think I'd add an extra server to cover the reboot cycle...
KSplice is GPLed. But the company they bought is run by the people who developed the KSplice patch (so they'll know the best how it operates, if there are any weird "corner cases", and so on). The KSplice team was also producing the actual updates themselves -- I'm quite sure there's no automated way to generated a KSplice patch from the "Here's a brand new kernel and modules" packages the vendors provide.
It appears it would use a kernel source tree and the security patch diff, and compare the results of patched and unpatched builds to determine what changes. Not bad. BUT, they also say if the patch changes any structs or other semantic changes, that a programmer must basically patch the patch to make it ksplice compatible. That may be the sticky wicket, is there some docs on what kind of changes must be made? If nobody at Redhat etc. figures out how to make all the security patches into KSplice patches, then that's that.
Good buy for Oracle
I hope this does bring about a community driven project and other commercial distros rise to the callenge with their own solutions as this is a great technology.
including Oracle RAC
Including Oracle RAC. Even the DBAs don't have a clue when it comes to setting up
redundancy and the apps developers insist on hard coding hosts/IP addresses (not VIPs!)
Our Oracle RAC cluster is harder to maintain than 10 stand alone servers...
Stewart McKenna said:
> Our Oracle RAC cluster is harder to maintain than 10 stand alone servers...
I manage 4 RACs. One is a 12 node RAC.
Cannot recall the last time I had to do sysadmin (Linux) or sysdba (Oracle) maintenance on the 12 node one as it simply works.
If it is hard to maintain then the house was build on sand. RAC is only as robust as the underlying hardware enables it to be.
My pet peeve is looking at others building RACs and using 100Mb Ethernet for the Interconnect. Or shared 1Gb Ethernet for both the public network and Interconnect. Or using shared switches for the Interconnect. Etc.
Performance and robustness of such RACs are essentially non existent. RAC is not designed to be run on a "garbage" h/w layer.
ksplice - interesting in theory, highly complex in practice
Sun Microsystems had a similar piece of technology (hotpatching / DUKS, aka 'dynamically update kernel services' or something like that) that shipped with early releases of Solaris 8. The facility was _removed_ it in later system updates.
Why is that ? Largely because of the complexity in managing a hotpatched system, and the complexity involved in creating such a hot patch for a given (likely already-patched) target system.
Patch management as-such is already complex - like, which order to install if multiple patches are applied, which services need to be started / stopped to apply certain patches safely, which patches can be applied without requiring a reboot to activate, which ones do need that. As your system ages, all these factors compound.
Now add splicing to the picture. At each of the above steps, for each of the patches involved, add the question "has it been spliced before", and the question "should it be spliced now", the question "what'd be the splicing baseline", "should it be spliced again after ordinary reboot, or patched ordinarily", and the same for "what if it crashes". Also, ask yourself the question how a splice/hotpatch can be qualified / verified / certified ...
In practice, this means splicing / hotpatching is a valuable tool for rare occurances only - namely, a well-understood, critical, but small and contained modification applied to _bridge_ the time till the next planned maintenance. To some, this is worth $$$$.
Most interesting bit about the news is that to Oracle, this must be an investment in an area where they already hold assets (the technology acquired with Sun Microsystems). If they are cooking up a good way of managing / reducing / eliminating the complexity mentioned, then I for one are looking forward to more. The hard part is not "how to splice", but rather how to manage / track a spliced deployment.
Although, of course, if you own enough patents on methods for "dynamically redirecting program flow", you can throw spanners into the gears of hypervisors, tracing utilities / mechanisms, virtual machine just-in-time compilers/optimizers, debuggers and all such. But then, these days any piece of software lives under the patent sword of damocles.