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@example.com and bob@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.