Then, Red Hat decided they could make more money by spinning off Red Hat Linux into a separate enterprise-only product called Red Hat Enterprise Linux (RHEL), which they declined to make available for free in a ready-to-install binary form. Fedora[2] was also spun off at this time, as the free successor to Red Hat Linux that was supposed to be only suitable for home users. Fedora development was/is sponsored by Red Hat but they did not offer end-user support, in contrast to RHEL.
Meanwhile, there was demand for a free version of RHEL. Since it was built with GPL software, Red Hat was obligated to make it available in source form, but their trademark policy prohibited anyone else from using the Red Hat name. Therefore, a group of volunteers took RHEL, removed Red Hat trademarks, and called it CentOS. To avoid confusion, CentOS explained the origins of the distribution on their web site. For their efforts, they were threatened by Red Hat's legal department and forced to remove all mentions of Red Hat and even links to Red Hat's web site from the CentOS web site. CentOS complied and began referring to its Red Hat derivations using the euphemism PNAELV[3].
Now, Red Hat has again decided they would benefit from being more directly involved in providing an open-source, freely-available enterprise Linux distribution. We've come full circle.
(Flippant depiction aside, I intend no antagonism, but merely find the history of these projects interesting.)
[1]: https://en.wikipedia.org/wiki/Red_Hat_Linux [2]: https://fedoraproject.org/en/about-fedora [3]: http://www.pnaelv.net
By the way, what did Firefox do to live down its IceWeasel[1] infamy?
Mozilla simply claimed that the Firefox trademark cannot be applied to any codebase that Mozilla, the trademark owner, hadn't officially sanctioned. They began to actively prosecute those cases because some people were modifying the Firefox source to contain malicious code and calling it "Firefox", misappropriating Mozilla's trademark. Because Debian issues a version of Firefox that contains unofficial patches, they cannot legally call their distribution "Firefox", since Mozilla hasn't officially blessed that exact codebase.
tl;dr Red Hat was trying to make money from users, and Mozilla wasn't
Disclaimer: I personally fully support making money from users and reject freedom 2 as a true fundamental of "free-as-in-freedom software". I'm just explaining why some people in FOSS dislike Red Hat, as it pertains to the CentOS backstory, and why nobody cares about Mozilla's brief trademark dispute with Debian.
Nothing would make Red Hat happier than having every hacker under the sun using Red Hat - what they were attempting to do was keep the enterprise customers, who were currently paying $1000+/CPU (or so) go with a free alternative and kill their company.
Simply removing three things allowed them to do that: (1) No RHN/Up2Date available for Centos, (2) No Support, (3) Most importantly, absolutely no mention or reference to "Redhat" Trademarks.
Centos had everything else.
Because Debian issues a version of Firefox that contains
unofficial patches, they cannot legally call their
distribution "Firefox", since Mozilla hasn't officially
blessed that exact codebase.
Mozilla are happy for distros to put out their code - just not hacked up versions of it with the same name. Good for them.
They started user the trademark thing to force some distributors who were adding patches they did not want to be associated with (either because they were just plain malicious or because they didn't want thie bug tracker filled with reports about code they had nothing to do with), the Debian people scanned the relevant legal details and decided that they either needed to stop using hte name or work put together an agreement that covered them. The latter would have been easy enough but was against their preferred WayOfThings(tm) as it would mean downstream of them would (legally speaking) need to make changes or separately arrange an agreement, so they chose a new branding instead.
Neither the Firefox team protecting their name or the Debian team stucking to their mission statement is wrong IMO (though of course some may desagree, depending on definitions of "free" and so forth, so they could be said to be wrong), but without the branding change the two are incompatible on a legal point that was only enforce to stop the malicious.
With the branding change the "conflict" is resolved, and no one is really unhappy or otherwise reasonably put out.
The RedHat/CentOS case is a bit different: the way CentOS were using the name in no way implied that RedHat was responsible for CentOS but did accurately represent how CentOS was built, so CentOS were probably on good legal ground but capitulated because they didn't want that particular fight. This, IMO, made RadHat somewhat bully-like in this case - though to be honest it takes more than one iffy commercial/legal wrangle to undo the pile of good that Redhat has (directly and otherwise) done for Linux and related projects over the years (and continues to do).
Indeed, the success of Linux in the enterprise owes a lot to Red Hat, as they gave enterprises the sort of consistent, corporate-buzzword-compliant support agreements that removed a lot of the scariness that would otherwise impede use of Linux for "important" services.
It allowed ISVs to certify their software packages against a consistent OS built, hardware vendors to utiliza a long-term consistent driver interface, and end-users to not have to worry about upgrade cycles, sudden performance changes, and so on.
Basically it gave enterprises that had been dependent on Solaris and the like a comparable Linux alternative.
Due to the success of Ubuntu you have user/experts in small to medium sized companies that have 'given Linux a go' and got some good experience of Ubuntu. They might prefer the Ubuntu ways of doing things, e.g. the 'no root' security model, the modern, up to date packages (e.g. latest version of PHP), the ultra easy firewall and plenty else.
However, due to the perception that Red Hat is 'enterprise' and that small to medium companies re cheapskate, the CentOS rip-off gets specified by micro-managers because they have heard it is more 'enterprisey'. 'They know best' and go with the turgid CentOS regardless of whether any developers on the team would prefer something else.
You then have a lot of hosting companies pushing CentOS because they think it is more 'enterprisey' and what their customers want. Non-technical managers listen to them and then blame their team for any server problems.
Sure, if you know your way around Red Hat it is the greatest thing since Windows 3.0, you can get it to do what you want just fine. But, actually, if you are not an expert yet then very little about Red Hat is obvious. Far too many answers to common problems are guesswork in forum answers that you come across. Furthermore any serious claim to better security goes out the window as soon as you add random repositories that you might need just to get your work done.
Red Hat has had its day. CentOS has been a mere rip off of Red Hat and it has not added to the state of the art. I know it has its fans but I wish it would just go away.
Why do you find it odd when it is succinctly explained in the comment to which you are replying?
As far as IceWeasel, I asked a Mozilla employee about it a few years ago. He said they generally approved of it, and were just glad that people were using the code.
If they wanted to shut down CentOS, it would be very easy to stop distributing the source of their own projects and of permissive license packages. Hopefully sponsoring CentOS is not just a play to exert influence on the project and retard its progress, but I am willing to give Red Hat the benefit of the doubt here.
[1] http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/...
That is true, but the GPL allows their customers to freely distribute the GPL source they receive. Not saying Red Hat doesn't help or isn't doing good here, but it's not quite as altruistic as you make it out to be. I thank the GPL for that.
Note that I'm a huge fan of Red Hat and preferred their distribution since the RH 4 days, I don't want to denigrate Red Hat in any way. Also a huge fan of CentOS as well.
Doesn't trademark require you to enforce your trademark (or you lose it)?
Also, Oracle did/does the same thing as CentOS, and sells support for it. There is also ScientificLinux too.
- have support contracts that make sense, and trust their customers. Let their customers choose which server they want to put under contract etc...
- have more software in their default repo (like, I don't know... Ubuntu)
They managed to corner the market for pay-for software (to a certain extent, Suse has managed to capture a piece of that market), but they make support and lack of standard software so bad, that people go to extreme length tu run on CentOS and ScientifiLinux, and have a single server running Ubuntu.
It's sad, but this wasn't at a .com rev3 company, this was an old-school hedge fund with billions under management. IT support is just something that gets neglected if there isn't a contract that is enforceable. Clearly the company could afford a thousand systems worth of support, and could make it worth the money (autofs bugs galore!). There is a something missing in making the social contract of open source pay for the people needed to maintain open source.
I know of a few companies which tried to pay for 24 hour support for prod servers, email for QA servers and no support for dev servers, and RedHat insisted on making them pay for anything running RedHat, all or nothing... Companies switched to CentOS and SL, and bought contract for one RedHat server.
Oracle Linux's distribution model is that you can take CentOS, change a couple repositories and make it Oracle Linux. Then if you want support, you can pay for it. With Red Hat, RHEL and CentOS before today were separate products with separate release schedules and separate userbases. This move gives Red Hat the opportunity to act more like Oracle Linux if they choose to.
* CentOS has significant market share
* people sometimes want to switch from CentOS to RH, but not vice versa (natural evolution in growing companies)
Thus they will cooperate with CentOS, with the end result that switching from CentOS to RH will become easier.
As someone who used Red Hat Linux in the 90's / early 2000's, you had to be there to know how large of a gap the CentOS team filled.
Historical background:
Red Hat Linux (RHL) was the most widely used Linux distro in the late 90's / early 2000's. Overnight, RedHat destabilized RHL by turning it into Fedora with it's rapid release cycles, lack of back ports, bleeding edge packages etc. RHEL became a closed distro with only source distributed, but none of the tools to easily replicate the build.
RHL users (who were the majority of Linux users) were faced with a choice. Pay for RHEL or switch distros. This really sucked b/c RHL deployments were largely servers that were designed for long term deployments. The community was faced with a large scale migration of servers which involved a large population of web and edge of network deployments.
This is when CentOS stepped in, created a binary compatible build of RHEL, and allowed long time RHL users to continue with a RedHat-like distro.
RedHat has been a major contributor to OSS. However, projects like CentOS have filled very important roles in the Linux and OSS communities. Again, congrats to the team.
That would work a long way to make CentOS a viable Linux distribution for everyday use. In my experience, EPEL isn't enough and rebuilding packages seems like a wasted effort since they were there when they branched off to prep a new release.
Add a somewhat predictable release schedule on top of that (again, in my opinion Ubuntu hit the sweet spot with 24 months here) and that would be the icing on the cake. Heck, RHEL 6 was first released in 2010 and there's still Python 2.6 on that!
I know that I could shut up and use Ubuntu (I do), it's just that I like RedHat way more than Canonical but they don't make it easy for me to use and love their products (speaking as a former Fedora user and contributor).
It isn't always so easy. I don't know what RHEL7 is like, but for 6 and 5 there wasn't a complete correlation between a Fedora release and a RHEL release. For example, 6 is mostly based on Fedora 12, except for a bunch of backports from 13 and a few from 14.
"RHEL 6 was first released in 2010 and there's still Python 2.6 on that"
Or Python 2.7 or 3.3 can be installed via Software Collections. These have a predictable release cycle- a new version is released every 18 months, and each version is supported for three years.
https://access.redhat.com/site/support/policy/updates/errata...
https://access.redhat.com/site/support/policy/updates/rhscl/
[1] https://access.redhat.com/site/documentation/en-US/Red_Hat_D...
"With great excitement I'd like to announce that we are joining the Red Hat family. The CentOS Project ( http://www.centos.org ) is joining forces with Red Hat. Working as part of the Open Source and Standards team ( http://community.redhat.com/ ) to foster rapid innovation beyond the platform into the next generation of emerging technologies. Working alongside the Fedora and RHEL ecosystems, we hope to further expand on the community offerings by providing a platform that is easily consumed, by other projects to promote their code while we maintain the established base."
(continues)
> - Some of us now work for Red Hat, but not RHEL.
> - Red Hat is offering to sponsor some of the buildsystem and initial content delivery resources
> - Because we are now able to work with the Red Hat legal teams, some of the contraints that resulted in efforts like CentOS-QA being behind closed doors, now go away and we hope to have the entire build, test, and delivery chain open to anyone who wishes to come and join the effort.
> - The Red Hat Enterprise Linux to CentOS firewall will also remain. Members and contributors to the CentOS efforts are still isolated from the RHEL Groups inside Red Hat, with the only interface being srpm / source path tracking, no sooner than is considered released. In summary: we retain an upstream.
Edited for clarity.
I don't see what interest has RH into Centos except for trying to disrupt the base and push that way more businesses and customers to RH.
Maybe i'm just biased but Centos is doing pretty good in my opinion except maybe the late code changes and updates.
Why would they? CentOS is RHEL, they'll ship whatever RHEL ships.
"Keep your friends close, ..." because it's just business.
This smells like FUD.
Sounds like the CentOS QA process will be more transparent.
It is for this reason that I moved to Oracle Linux about a year ago when deploying a bunch of new machines. I am certainly no fan of Oracle the company but they were getting security updates out much quicker than CentOS.
But think: how could Red Hat 'control' CentOS when CentOS is simply a clone of RHEL produced from the srpms that Red Hat have to distribute under the terms of the GPL?
As Karanbir says, 'we retain an upstream'.
There are other clones: Scientific Linux (CERN/Fermilabs and a lot of Universities) and Springdale Linux (Princeton/Institute of Advanced Study) are two other RHEL clones. And of course, there is Oracle Linux, a third clone, and one that provides commercial support.
If CentOS gets shitty you can always move to SL, Puias etc or make your own.
As a longtime Fedora user and a recent emigre (post-Snowden) to OpenSuSE, I agree that there is much to love about the selection of RPMs available, especially under Fedora. Although I'm sticking with suse for the lightning-fast zypper (still noticably faster than yum or even its slated nextgen replacement dnf!) and well-thought-out snapper utilities. But that is OT.
My preference stems from the following:
1. yum repos are so simple to create and maintain! One command, one directory, no files except the packages themselves. Contrast this with apt-get...it literally took me weeks to figure out how to create an apt-get repo. It requires several configuration files, which are generally human maintained (as far as I can tell, the docs for maintaining a repo separate from the Debian repo are awful and leave more than half of the process out completely, to be guessed and googled...they assume you only want to add a package to the Debian repo, not create a new one). It is also inefficient as hell. Generating our Debian/Ubuntu repo meta-data takes an order of magnitude longer than the yum repos.
2. Packaging RPM is much nicer, IMHO. If you don't need patches, it's just one file, the package-name.spec, plus the tarball. If it's a standard "./configure; make; make install" process, your spec file can be almost empty. The spec file is well-documented (Epoch is tricky, and a couple of the macros aren't immediately obvious, but in general, I can answer my questions by reading the docs). Debian requires several directories full of files for every package, and the documentation is obtuse. Again, it took me a long time to figure out how to package for Debian, and there's no good source for what tools you use to create and maintain packages. Wanna sign those packages or repos? Good luck! There are three or four different ways documented, and it was not at all clear which was the right way. I had to dig into the Debian repos to see how they did it, and try to replicate it. I think I'm doing it right.
3. As a user, I dislike apt-gets tendency to want to remove packages based on dependencies no longer existing...so, if Apache were installed to satisfy a dependency in another package, and you remove that other package, apt-get will (with some configurations, seemingly the default) ask if you want to remove Apache. Even if you have a hundred VirtualHosts configured and rely on Apache for everything! I find some of apt-gets other defaults alarming.
4. yum has mock. mock is amazing. Building packages for any RPM/yum-based distro with one command and one configuration file (and maybe a custom repo, if there isn't already one) is so awesome. As a package maintainer, this would be enough to win my heart forever. apt-get has some kind of fake root thing, or something, but I can't figure it out, so I have to maintain a VM for every Debian/Ubuntu version we support. This sucks and is tedious as hell.
But, if I had to live with apt-get, I certainly could. They are, honestly, both amazingly great technology, and I can't imagine life without a good package manager. I hate Windows and Mac for this very reason. I can't believe people think Mac OS X is acceptable, given the awfulness of package management on the platform. Even Windows has better package management than Mac OS X.
Some amazing things about both:
yum has groupinstall and apt-get has tasks. Super cool! Install a huge swath of packages, for achieving a specific goal (like "Development Tools" or "Gnome Desktop") with one command. Brilliant.
Easily install all the dependencies you need to build a source package, based on it's specified build dependencies. How amazing is that? Not only can you install the source code and the config files, patches, and data files you need to replicate the package from source, you can also replicate the needed build environment easily. (Add mock on yum-based systems, and you have packager heaven.)
I've had problems with individual .deb packages before, but never broke the whole package management system quite like that before :P