The developer program agreement forbids you from using this for test or production installations [1]:

"By participating in the Program and accepting these terms, you represent that you will be using the Red Hat Subscriptions(s) for development purposes only, and Red Hat is relying on your representation as a condition of our providing you access to the Subscription(s). If you use the Red Hat Subscriptions for any other purposes, you are in violation of Red Hat’s Enterprise Agreement set forth below and are required to pay the applicable subscription fee"

1 - http://developers.redhat.com/terms-and-conditions/

Right, that's by definition what a "developer license" means; realize that this may not be common knownledge, but comment reads to me as if this was some form of trickery, which it clearly is not.

Though I am surprised to see "test" not included in the dev license. Aren't they usually lumped together?

It doesn't mention test at all in the agreement, I don't know what OP's talking about. It only forbids production installations.

Pretty sure it means you can't have servers running your tests that prepare your production code for deployment. Maybe you use RHEL to run Openshift 3 with containers spinning up a test environment to run acceptance tests exactly like production before deploying the same containers on the production machines. Not allowed with the free dev license.

In my experience, I've always got the dev / test env licences for free anyway when paying for prod / dr.

It's a checkbox in some companies procurement method, in the same way many require source code escrow just to do business.

Maybe they are worried about perpetual beta sites.

If it's externally accessible to customers, it's production. Whether you call your served content beta is irrelevant.

But what if I only test in Production? Achievement Unlocked!

Cleverness and semantics aside, be warned that if you do "testing" that per the agreement, the developer edition "may not address known security vulnerabilities."

Seems like it'd just make more sense to expect if you're getting value from this that will transition to "production like use" on RHEL, you should plan to pay for it; either in cash, or dealing with the lack of security patches.

CentOS gets security updates though, so would this miss security updates delivered to CentOS?

Stopped using CentOS, and have no idea what value if any the RHEL dev subscripion would have someone using both; yes, I'm aware of the relation between the two, just never looked into it.

I wonder if this prohibits use as a primary workstation?

On the SUSE side, you can get OpenSUSE Leap which is a clone of all of our SUSE Linux Enterprise (SLE) packages that are kept up to date with SLE. It also has a bunch of community-maintained free software packages not available in SLE. And yes, it's all free as in speech and beer. And no EULA.

How does "uses SLE packages" and "kept up to date" work together? I'm seriously confused because that seems to be exclusive to me. For example, an more up-to-date kernel package isn't really derived from SLE anymore then, right? And how can a developer be sure his software working on openSUSE Leap is running on SLE when there are different packages? That's what this post is about, kinda.

The more apt Red Hat equivalent seems to be Fedora here, which is 100% free as in speech & beer as well. Or CentOS, if we're talking about developing Enterprise software. It's a binary-compatible RHEL rebuild after all.

Well, the reason that Leap 42.1 has a 4.x kernel is because the next service pack of SLE is planned to have a 4.x kernel as well (at which point, from my understanding, they'll sync up). The reason they didn't just use the SLE kernel is because of hardware support.

But the rest of the packages are either:

1. Directly from SLE, meaning that they have the exact same version, patches and build setup (they're rebuilt on the External OBS though). These are kept up-to-date with maintenance releases for SLE (which is what I meant by "up to date").

2. Community-managed, meaning that they were not available in SLE and the community added them.

Admittedly, the kernel is the one case I know of where this is not the case. CentOS might be comparable, but I don't know whether or not RedHat actually contributes to CentOS (we contribute to OpenSUSE).

The difference between openSUSE and Fedora seems to be that openSUSE is based on SLES and Fedora is the base for RHEL. That may be different approaches, but I feel like it has very comparable results. Fedora is a community project heavily sponsored by Red Hat and open to everyone, it seems to be very similiar to openSUSE's governance model. Most things Red Hat is creating for RHEL is available in Fedora before (in fact, I cannot name any RH product that's not available in Fedora thinking about it).

> I don't know whether or not RedHat actually contributes to CentOS

CentOS is part of Red Hat (for like 1 - 2 years? Not sure).

I'm kinda irked by your original post because it seems to imply you cannot get Red Hat technology without the EULA or only by paying. That's just wrong as both CentOS and Fedora prove.

> I don't know whether or not RedHat actually contributes to CentOS

Not sure if that counts, but they hired a few of CentOS's core developers a while back (one or two years ago, I think), explicitly to make communication between RHEL developers and the CentOS people easier/faster. CentOS remains what it was before, but Red Hat now pays a few people to work on it full time.

CentOS is actually an official part of Red Hat by now[1].

[1] https://www.redhat.com/en/about/press-releases/red-hat-and-c...

Thanks for the link! I was not sure how far their involvment went beyond springing for the developer salaries.

Kept up to date with SLE, if I understand the poster correctly, as in using the same versions and patches.

EULAs on Linux, while MS goes MIT, all in a day. Interesting times indeed.

I can still install the exact same software as Red Hat Linux – except for a difference in name only – in the form of CentOS, for free, both as in beer and speech.

I still can't install MS Windows for free or without EULA.

I can.

In Germany EULA don't have legal value.

Actually in most European countries, if you only get to read the EULA after paying, it doesn't have legal value.

I was speaking in the context of my parent post.

It is good to know there is some legal haven where post-transaction EULAs are disregarded, though, thanks.

I wish this would spread more.

For example currently noone submit community made patches of SimCity 4 to SimCity 4 forums, because the EULA forbid it, and Electronic Arts DID contacted forum owners about it, saying that if they allow SimCity 4 patches in their forums and sites, the EULA will get enforced and they will get sued.

Even discussing making a community patch for SimCity 4 get you banned on those forums...

I am very sure that if EULA were non-enforceable in the entire world, people would start patching SimCity 4 to work properly on new computers in 6 months at most.

That makes no sense, except from an overstepping-legally-and-relying-on-unsophisticated-second-party point of view. How is a forum in any way bound to the game's EULA? As a trivial point, let's say the forum is owned by a company. So EA is going to sue the company for breaking terms in the EULA of its game? How did the company become beholden to those terms in the first place?

>if you only get to read the EULA after paying

Not relevant to Microsoft, or any consumer-facing company with a website really.

https://www.microsoft.com/en-us/useterms

You have to prove that the customer was made aware at the shop that such link exists and decided consciously to ignore the advise.

Legal stuff is fun, hence lawyers.

> EULAs on Linux, while MS goes MIT, all in a day.

Well, it is April 1st ;-)

A few years ago people hearing that news would have laughed at the silly joke.

I think this is RH finally realizing why Ubuntu Server has surpassed them in the cloud. It's because develop & test on the same OS. Its also the reason why CentOS was popular in the first place.

This coupled with faster but unsupported software version updates should put but back on track to compete in the cloud.

CentOS has let you do that for a long time.

The whole point of RH/CentOS is it's the distro for people who specifically do NOT want a lot of churn in software versions.

I install RHEL on production servers because I'm much more confident I can run "yum update" and nothing will break.

>> The whole point of RH/CentOS is it's the distro for people who specifically do NOT want a lot of churn in software versions

With collections they're pretty reasonable at letting you join the churn train if that's what you need.

I'd peg them as a purveyor of more thoughtful implementations. E.g. one example would be docker - rh implemented it from the get go with MAC. I think the others are catching up now, I believe apparmour profiles are present on modern Ubuntu around docker.

    I install RHEL on production
    servers because I'm much
    more confident I can run
    "yum update" and
    nothing will break.

Similar rationale for my using FreeBSD.

Excluding ports, right? Those break pretty often.

Er what? The CentOS 7.2 cloud image was released 3 days after the DVD. Amazon doesn't seem to record when the AMI was uploaded, but previously it happened at the same time as the cloud images were announced.

If you want faster, unsupported software versions for Red Hat ecosystem then use Fedora.

But if you want a stable base system with newer language runtimes or development tools, use Red Hat (or centos) with software collections.

https://www.softwarecollections.org/en/

Expect it to break a few times a year though.

Nothing you can't fix but I thought you might want to be aware of it up front.

In my experience (I've been using Fedora as my primary desktop for approx 8 years), breakage is more rare than that, like once every few years.

Depends what you mean by break, probably. I've been using Fedora as my primary desktop/home server since it began. I pretty much never see breakage from regular updates. I do expect to see something break whenever I upgrade from one release to another. I'm pleasantly surprised when it doesn't.

Usually it's something like "I need to ediff-merge foo.conf with foo.conf.rpmnew", or "I need to reinstall this dependency of my webapp to the new python site-packages directory", so you wouldn't see this kind of breakage on a clean install.

Does this give access to the Red Hat support website? Some of the notes on bugs/workarounds there are useful, but subscriber only.

After creating a developer account and logging in I still do not have access to the subscriber knowledge base.

I was able to log into the knowledgebase (e.g. https://access.redhat.com/solutions/412643) using my new developer account. Working in a CentOS shop, this has made my week!

I can also access the "premium" resources using my new account, however, on my first attempt I landed on my profile page asking for further details (address, phone number). Having completed my account I can read e. g. "verified solutions" I definitely couldn't access previously.

thanks, I'll give it another try. I have a subscription provided by my employer but it's good to know I'll have access if I ever leave.

Over the last few days at Build, Red Hat had been making a big deal about "loving .NET." I wonder if this move is driven entirely by the desire to be the go-to destination for .NET Core on Linux.

EDIT: I saw this announced by Red Hat during a .NET session and they were giving out flash drives with the image.

I could imagine Red Hat having lots of customers that would like running their .Net applications on Linux, so it makes sense for them.

I am curious, what does this give you over CentOS, I thought the idea of CentOS was that it was RHEL with different support and branding?

CentOS is a rebuild of RHEL. While it's rare, there are some bugs that creep in during that process. It also doesn't have a few other things that RHEL does - mainly the -supplemental repo (closed source 3rd party software, the most important of which is probably Oracle jdk in rpm form), a working yum-security module, and a slightly different update mechanism (both are yum, but if you are creating some mass deployment system then having subscription-manager is important; this is really edge case-y though).

And to be very, very clear - Red Hat does not support CentOS. Some of the CentOS devs are paid by Red Hat, but if you open a support ticket for it it will be closed very quickly. You cannot pay Red Hat for commercial support of CentOS in any way.

To invert the question then: Why, now, would I choose CentOS over RHEL with this new free development license?

You can put CentOS on production machines. If I understand the news correctly, the free developer license only applies to ... well, developer machines.

You would choose CentOS if you need to run enterprise-level software (example, Oracle), but you can't pony up the operational money to buy Red Hat Enterprise Linux licenses on your server fleet.

If you can afford Oracle licenses, RHEL licenses are a rounding error.

Oracle supported way would be to use Oracle Linux for that.

You wouldn't. Seems like the whole idea.

Are there no limitations at all with this then? No limit to the number of machines it can be deployed on? Any stipulations about it being for development only purposes?

Reading the article suggests it's developer only and so for low cost production deployments, Centos is still much cheaper(free).

Presumably if you dev in rhel or particularly rhel/.net, you'd want to run the same in prod.

For the first few years perhaps not to force current systems to move in order to keep receiving updates?

As a developer, it means I can now test my software directly on RHEL. CentOS is RHEL with different branding (and now supported by RedHat), but there might be small differences that creep in. Customers like hearing that you've tested it directly on their OS.

I have never totally understood the difference between redhat server, desktop and workstation. This program grants access to redhat server. Does this mean that you can not use this to develop something for Gnome? The way I understand the differences between the variants in order to do Gnome development you would need to use Workstation, which is Desktop plus development tools.

No, desktop and workstation are just stripped down versions of Server (with occasional really weird exceptions like the packages to burn a physical CD or DVD are, only in those two in RHEL7).

Server has a LOT of packages that the other two do not as well. Really, Server is what you want.

it just determines which packages are preinstalled

If you cant fight with free but unsupported, be free and unsupported. :) I was expecting this for quite some time.