On Fri, Jan 29, 2021 at 08:20:48PM +0200, Gena Makhomed 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".
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.