[CentOS-devel] First round of RHEL programs announced

Gena Makhomed

gmm at csdoc.com
Sat Jan 30 21:00:21 UTC 2021


On 29.01.2021 20:35, Matthew Miller wrote:

>> In the example above - Alice and Bob are employers of company,
>> which are registered Individual Developer Subscriptions using
>> corporate mail, for example, alice at example.com and bob at example.com
>> example.com - domain and mail server owned by Example Corporation.
>>
>> Is such registration allowed?
>>
>> Is Alice and Bob allowed together use these 32 subscriptions
>> for servers and VMs used in production for company purposes?
>>
>> And what changed if we have not 2 but 32 employers? 32 employers
>> of company together can have 512 subscriptions for servers and VMs.
>>
>> And what changed if we have not 2 but 128 employers? 128 employers
>> of company together can have 2048 subscriptions for servers and VMs.
>>
>> If Alise of Bob leaves the company - they email will be blocked,
>> servers and VMs will be deregistered from Alise of Bob accounts
>> before Alice and Bob fired from the company, and these servers
>> and VMs anew will be registered to another employers of company.
>>
>> Such a scheme of work with subscriptions will work without problems
>> or such scheme of work is forbidden and illegal? (on which reason?)
> 
> This is not an official response. Just some thoughts.
> 
> I don't think there is anything specifically forbidding this, but I think
> it's pretty easy to tell that it _feels_ kind of off. I mean, the whole fact
> that you're speculating about such a scheme as a possible way to skirt the
> intent says you feel that too. Like I said to someone asking about one
> person person registering many different accounts with different emails,
> there's some degree of just plain expecting people to play nice.
> 
> As far as problems with the plan, aside from the overhead of managing it
> all, I think there's a pretty good argument that if the actual subscriptions
> aren't _actively managed_ by those 128 employees but instead handled
> centrally in their name only, that's probably actually cheating not just
> "smells cheaty".

Matthew, thank you for the detailed answer.

Since I manage more than 16 bare metal servers / virtual machines
- now I understand that I shouldn't even try to use no-cost RHEL
for production. And the only available option for me is migration
to the Oracle Linux / Alma Linux / Rocky Linux / Debian / Ubuntu.

> And if instead your company comes up with some process for _actually_
> managing everyone's active participation, well, okay, fine, but maybe that
> time would be better spent on figuring out how to actually just cope with
> CentOS Stream — or to skip all that and decide that you're at a scale where
> actually paying for RHEL isn't all that terrible after all and all the
> employees can concentrate on doing their actual jobs.

I can't use CentOS Stream - it is beta quality and has critical bugs.
For example: https://bugzilla.redhat.com/show_bug.cgi?id=1913806
This bug is critical for me, because I use systemd-nspawn containers
for production. I will continue to use CentOS Stream in the future,
but only as the beta-tester, to see what new will be in the future
minor release of Oracle Linux / Alma Linux / Rocky Linux.

We are a small company and website hosting is low-margin business,
so we can't buy RHEL for each bare metal server / virtual machine.

-- 
Best regards,
  Gena



More information about the CentOS-devel mailing list