[CentOS-devel] First round of RHEL programs announced

Thu Jan 28 11:22:45 UTC 2021
Gena Makhomed <gmm at csdoc.com>

On 20.01.2021 15:14, Mike McGrath wrote:

> Hi all, I know this was a hot topic on the list so I thought I'd share
> today's blog post which covers no-cost RHEL for small production workloads
> and no-cost RHEL for customer development teams.  Keep in mind there are
> other programs coming, these just got done first.
> 
> https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-programs-easier-ways-access-rhel
> 
> Bullet Points:
> 
>     - Self-Support RHEL for no-cost in production use cases of up to 16
>     systems.
>     - No-cost RHEL for customer development teams (larger number of systems
>     for non-production cases).
>     - Available no later than February 1
>     - Single Sign-on via a Red Hat account, or Github, Twitter, Facebook or
>     other accounts (You'll soon not need to provide all kinds of personal
>     information like you used to).

I have same questions.

This is copy of my email to centos-questions at redhat.com

==============================================================================

Hello Red Hat,

As I understand from the Red Hat blog article "New Year, new Red Hat 
Enterprise Linux programs: Easier ways to access RHEL" I am limited to 
only 16 no-cost RHEL instances. Limit 16 instances means bare metal 
servers and KVM virtual machines, right?

But what about systemd-nspawn OS-level virtualization containers? To be 
able run "yum update" inside systemd-nspawn containers I need to 
activate Red Hat subscription inside each container too???

And I can't have more than 16 instances (bare metal + VMs + containers) 
with a RHEL subscription?

This is too strict restriction for me. Because I use now CentOS 8 in 
production and use systemd-nspawn containers for hosting websites, and 
create for each website a separate systemd-nspawn container.

Or I can legally create and legally "yum update" and legally use in 
production OS-level virtualization systemd-nspawn containers without 
activating RHEL subscription for each such container?

But I still need to activate the RHEL subscription for each VM which 
runs an RHEL instance?

==============================================================================

What is about running in the one bare metal RHEL server virtual machines 
with different subscription owners? For example, run in production on 
one bare metal server 16 VMs with subscription owner Alice, and 16 VMs 
with subscription owner Bob, and 16 VMs with subscription owner Carl, 
and so on. Are such configurations legal and allowed or not? I didn't 
find any limitations on the blog article, but for sure and for future I 
need a clean and unambiguous answer from Red Hat.

If such configurations are allowed - this is a legal workaround for a 
limit of 16 no-cont RHEL instances. For example, a small company, with 
50 employees can absolutely legally have free and no-cost 800 RHEL 
servers in self-support mode. Company with 100 employees can have 1600 
free no-cost RHEL servers in self-support mode and so on.

If such configurations are forbidden (on what basis?) - I have no choice 
but to migrate from free CentOS and no-cost RHEL to Oracle Linux or Alma 
Linux or Rocky Linux.

And in the future if my company grows and I will need to buy commercial 
support - I will be forced by Red Hat's decision to buy subscriptions 
for Oracle Linux from the Oracle Corporation?

Is this the real goal of the no-cost RHEL 16 instance limit - force 
CentOS users migrate to Oracle Linux?

More details here:

- https://www.oracle.com/linux/

- https://linux.oracle.com/switch/centos/

==============================================================================

[...]

-- 
Best regards,
  Gena