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