[CentOS-devel] First round of RHEL programs announced

On Friday, January 22, 2021 4:38 PM, redbaronbrowser via CentOS-devel <centos-devel at centos.org> wrote:

> On Friday, January 22, 2021 2:45 PM, Mike McGrath <mmcgrath at redhat.com> wrote:
>
>> On Fri, Jan 22, 2021 at 2:16 PM Phil Perry <pperry at elrepo.org> wrote:
>>
>>> On 22/01/2021 18:13, Leon Fauster via CentOS-devel wrote:
>>>> Am 22.01.21 um 14:53 schrieb Neal Gompa:
>>>>> On Fri, Jan 22, 2021 at 8:32 AM Leon Fauster via CentOS-devel
>>>>> <centos-devel at centos.org> wrote:
>>>>>>
>>>>>> Am 22.01.21 um 14:18 schrieb Mike McGrath:
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 22, 2021 at 5:39 AM Peter Eckel via CentOS-devel
>>>>>>> <centos-devel at centos.org <mailto:centos-devel at centos.org>> wrote:
>>>>>>>
>>>>>>> Hi Mike,
>>>>>>>
>>>>>>> thanks for the information, this is at least partly good news.
>>>>>>>
>>>>>>> Whet I currently can't figure out - maybe you have some
>>>>>>> information
>>>>>>> about it - is the situation with, e.g. Vagrant.
>>>>>>>
>>>>>>> I rely a lot on Vagrant boxes for development and testing work,
>>>>>>> and
>>>>>>> up to now the situation with RHEL is that there are none, probably
>>>>>>> due to legal issues and because RHN registration doesn't mix well
>>>>>>> with instances created and deleted on-the-fly. The obvious
>>>>>>> solution
>>>>>>> is - or rather, was - CentOS, which so far fit my needs. CentOS
>>>>>>> Stream in all likelyhood will not fill that gap.
>>>>>>>
>>>>>>> Are there plans for making it possible to create Vagrant boxes and
>>>>>>> similar items based on "FreeRHEL"?
>>>>>>>
>>>>>>>
>>>>>>> I don't think we're going to ship vagrant images directly. I know
>>>>>>> several customers are using vagrant with RHEL and we've got some people
>>>>>>> using it internally. We've got some kbase and docs on the customer
>>>>>>> portal (which you do have access to with these developer program
>>>>>>> accounts).
>>>>>>>
>>>>>>> https://access.redhat.com/documentation/en-us/red_hat_container_development_kit/2.2/html/getting_started_guide/introducing_red_hat_container_development_kit
>>>>>>>
>>>>>>> <https://access.redhat.com/documentation/en-us/red_hat_container_development_kit/2.2/html/getting_started_guide/introducing_red_hat_container_development_kit>
>>>>>>>
>>>>>>>
>>>>>>> de-registering a box could be made part of the teardown process I would
>>>>>>> think. I've also heard stale boxes (IE: registered systems that are no
>>>>>>> longer check-ing in) have some way to do an automated cleanup after 2
>>>>>>> days or so? I'm a little confused on how that process works though,
>>>>>>> its
>>>>>>> actually on my todo list to check out in February when the new simpler
>>>>>>> content access is in place.
>>>>>>>
>>>>>>
>>>>>> Honestly not so much experience with mock but what about mock build
>>>>>> environments. While mock bootstraps the context to build rpms quite
>>>>>> often, there is the need to access the repos. Does mock support "login"
>>>>>> into such "RH accounts" and logout (deregister)?
>>>>>>
>>>>>> CentOS with there mirrors was quite easy in this case.
>>>>>>
>>>>>
>>>>> It does not, unfortunately. You need to have subscription-manager
>>>>> configured on your host to be able to use RHEL content with Mock
>>>>> (which is a bit of a hassle in its own right...).
>>>>>
>>>>
>>>> Thanks, I was afraid reading this. So free RHEL make it more worse.
>>>>
>>>
>>> If you are building a lot of stuff in mock, you will almost certainly
>>> want to set up your own internal mirror of RHEL content for mock to
>>> build against.
>>
>> I asked around about this a bit. I think you're allowed to download whatever content you are entitled to and keep an internal mirror as long as it is protected somehow (IE: don't let unentitled people get access to it as I think you'd run afoul of redistribution problems). In other words, if you're downloading a repo and using it for your purposes, I don't think that violates our agreement. It turns out this is the thing that makes satellite possible.
>>
>> -Mike
>
> Thank you for looking into this.
>
> Just to clarify, you mean we should avoid redistributing RPMs not covered by the GPL/LGPL, right?
>
> For RPMs that are covered by the GPL and LGPL, it should not violate any agreement to redistribute those to anyone? As long as the form of redistribution doesn't claim the receiver is entitled to Red Hat support, anyone is entitled to the GPL/LGPL covered RPMs?

Mike McGrath, I find it troubling a VP level member of Red Hat, Inc. might be implying there exist people that are unentitled to GPL/LGPL covered works. If you don't mind, I would like to see if I can get a member of the Free Software Foundation involved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210123/c112e8a2/attachment.html>