On Sunday, January 24, 2021 7:13 PM, Mark Mielke <mark.mielke at gmail.com> wrote: > On Sun, Jan 24, 2021 at 3:04 PM Josh Boyer jwboyer at redhat.com wrote: > > > On Sun, Jan 24, 2021 at 1:41 PM redbaronbrowser via CentOS-devel > > centos-devel at centos.org wrote: > > > > > On Sunday, January 24, 2021 11:50 AM, Josh Boyer jwboyer at redhat.com wrote: > > > > > > > As a general reminder, the GPL and LGPL are source code licenses. The > > > > source code to the packages in Red Hat Enterprise Linux releases, GPL > > > > or otherwise, are released on git.centos.org, which requires no > > > > registration and no terms to accept. The recent announcements around > > > > CentOS Linux and CentOS Stream did not alter this approach. > > > > But Josh Boyer has taken the threat from Red Hat to the next level. > > > > I made no threat. I pointed out that we provide sources to packages, > > > > regardless of whether they were GPL or not and any recent > > > > announcements haven't changed that. > > For "we provide source to packages", this was my understanding: > > 1. RHEL packages are available in SRPM form from a public FTP site. > For GPL software, this nicely aligns with the spirit of the GPL. For > non-GPL software, this may be an additional nice gesture to apply GPL > thinking to all the source code whether or not it is GPL. It may also > keep things simple, since so much of it is GPL. For the software > published to the public on the public FTP site, there should be no > restrictions that apply, as there is no agreement between the user and > Red Hat. > > 2. RHEL EUS packages are available in SRPM form only to subscribers > with EUS subscriptions. For GPL software, such a person should be able > to legally download the SRPM, rebuild it, and redistribute the newly > built binary as a right provided by the GPL. However, the Red Hat > contract states some restrictions around access to non-public content > which may contradict the GPL, in which case this is a place where Red > Hat could void the contract despite the GPL granting full rights to > the user. For non-GPL software, this is much more grey zone. > Personally, I've avoiding looking at or using the SRPM content from > RHEL EUS, as it seems like a landmine. Instead, I prefer to use an > upstream release from Fedora or EPEL, or backport a later RHEL package > version, than rely on RHEL EUS. For those not aware - RHEL EUS is > generally the minor release date plus two years, and represents the > "branch" that people were talking about when they say that RHEL > differs from CentOS Linux. Essentially, RHEL has EUS streams, while > CentOS Linux does not have EUS streams. > > 3. RHEL ELS packages are available in SRPM form only to subscribers > with ELS subscriptions. This is the same as above, but could extend > beyond the 10 years support life of an RHEL release. I don't think > I've ever had an ELS subscription so I can't speak much more about > this. > > When it comes to CentOS Linux, CentOS Linux aligned with 1). It never > aligned with 2) or 3). > > With CentOS Stream, I believe 1) will also disappear. The reference to > git.centos.org seems to be glossing over that git.centos.org does not > contain the RHEL / RHEL EUS / RHEL ELS package sources, but only > includes the CentOS sources. And if CentOS Stream continues, then > CentOS Stream sources will receive updates, but if CentOS Linux does > not continue, then it seems doubtful that CentOS Linux sources will > receive updates. Meaning, that by 2022, I expect the RHEL sources to > no longer be available via git.centos.org, and the idea that > "announcements haven't change that" is likely to be false. I think > announcements have definitely changed this. > > But, let's come back to this in a year and see who is right. > > -- > Mark Mielke mark.mielke at gmail.com A lot of the issues we are seeing follows very closely with the transistion to Fedora during 2003/2004. Ensuring availability of the SRPMs wasn't ever an issue that exceeded the first year of Fedora. I'm guessing this is an oversight and it will be resolved before 2022. I think the "announcements haven't change that" is a likely forword looking statement. However, that isn't the only issue that seem to be forword looking statement phrased as if it has already been resolved. I doubt all those issues will be addressed by 2022. Rich Bowen seem to be sincerely working on being open and transparent so we may eventually be able to track what issues Red Hat considers seriously and the status on how they are working to resolve them. (Including continued SRPM availablity without CentOS 8). It is odd they never simply enabled SRPM access on the CentOS koji. In the mean time, it seems like Red Hat is just gauging the community response on an announcement by announcement basis instead of having a clear roadmap. Again, much like RH did during the first year of Fedora. So what was the point of RH claiming they learned from mistakes they made with the community during the creation of Fedora then? Not that anything I said matters, it seems all of my feedback is tagged "bad faith" now so I guess I am the only one frustrated about things.