Thanks for the post @sherold, I went looking for the clause around redistribution in the EULA earlier and had trouble tracking it down.
I have absolutely no doubt it’s in there, do you have a direct link for reference?
We are not rehosting Red Hat’s actual sources anywhere for 8. That isn’t the intention. The intention is to pull their sources, de-brand, etc as CentOS, Oracle, Springdale, and others have done. Those projects don’t host Red Hat’s sources, so why would we?
If you are concerned about this, I would recommend you joining us in slack and bringing it up to the core team.
Thank you.
1 Like
Huh… We’ve actually drastically reduced the terms on our clickthrough for the Dev Program from the last time I actually read it. I agree, I don’t see anything jumping out at me. Thanks for engaging. We want to make sure we aren’t getting in your way here.
2 Likes
I am not a lawyer, so won’t offer any advice as such, but section 1.2(e) of our wonderful Appendix 1 is what I’d ensure was understood when determining from where you get the sources. https://www.redhat.com/licenses/Appendix_1_Global_English_20200424.pdf
1 Like
Thanks again @sherold exactly what I was looking for, and it does seem pretty clear.
As appears custom for this thread, I’ll preface the following with IANAL and also that I don’t represent Rocky Linux in any way, I’m merely an interested observer and the following isn’t a suggestion for circumvention of any agreements, purely an academic discussion.
I understand that srpm != source, as in, my understanding is RH aren’t obligated by license terms to provide srpms just the modified sources (for GPL, but many packages use other licenses such as Apache 2.0 and MIT, which is another discussion entirely)
I have tried to determine in the past where srpms sit in terms of licensing and I have never really found a clear answer.
Is an srpm in itself considered a derivative work of the code it’s packaging? It seems somewhere in between as it’s not a modification of the sources, it’s a description and definition of how to package and build the sources for a specific output. What license do the contents of an srpm fall under from RH’s perspective? ie. The spec file, the package metadata such as description, changelogs, CVE references, dependency information, pre and post scripts etc.
As it stands, RH could potentially not provide srpms at all and just provide original source and patches and still remain compliant from a licensing perspective as the srpm itself is, I assume, RH IP.
As an example, if you build a new srpm (note: not compiled rpm, but regenerating srpm) from an existing srpm using rpmbuild (source files unchanged) this new srpm, although functionally equivalent, would be a different package, is that then redistributable if the original srpm isn’t due to how it was retrieved?
Not expecting anyone here to have all the answers, but if anyone has any information or input on this from experience, it would be good to know.
RHEL has strategically used this conversion to using CentOS SRPMs and therefore do NOT need to use any other SRPMs. You won’t find any SRPMs for RHEL other than the SRPMs within CentOS.
If you have any kind of RHEL subscription be it a single sub you pay for or a dev sub, you can still access the source RPM’s via DNF and reposync. My team that is working on the rebranding have done this already.
In the future, we will end up looking at commit tags to try to determine the right versions, but for now, this is where we are at.
1 Like
Hopefully the guys like you all that know how get the source and how to build the rhel fork can contribute for this ( Step-by-step process for forking & rebuild RHEL) also
RHEL Dev Sub Terms indicates no security updates
Are you sure Dev Sub with RHEL has access to all SRPMS?
The Dev Sub includes security updates in the rpm minor version increments (including security backports) and provides the associated source rpms.
Where is this information it doesn’t include security updates? Do you have a source, or more context?
-edit-
I found the following reference (emphasis theirs):
The Red Hat Subscriptions offered to you in this Program are unsupported, intended for development purposes only, are not intended for other purposes such as production environments without an active Red Hat Subscription(s) and may not address known security vulnerabilities.
Source:
I won’t speculate on why this statement is included, but it’s pretty overt. The Developer Subscription provides access to the same core RHEL content (from the FAQ) as a paid subscription and also provides access to older releases which are out of support and no longer receiving security updates, eg. RHEL 4.
Security update RPMs aren’t provided as discrete, separate packages and security errata are bundled in package releases with enhancements and bug fix errata. There is errata metadata provided (updateinfo.xml) to outline specific errata that coincide with RPM package updates, which is provided to supplement the information in the package changelog and to provide capabilities such as the yum-plugin-security functionality. I don’t know the status of this metadata with Developer Subscription, I haven’t investigated, but I know for a period the CentOS project (or an individual) were rebuilding this metadata from the mailing list for CentOS.
If anyone has had a different experience, keen to know the details.
-edit 2-
CEFS was the project I was referring to that built from the CentOS announce mailing list:
With Standard Subscription you can park RHEL on any minor release you want and still receive security and bug fix updates.
With Development there is no such service, actually there is no ERRATA branch of the release.
You asked where is it, you referenced it yourself. (in the terms and conditions of the Developer Subscription)
The $349 version also has limitations of installation on physical devices
The only full version is the one with standard support and is at minimum $799/year per VM or Server.
it also is missing high availability and Gluster and the like.
The complete version is more expensive
I believe what you’re describing in terms of security updates is EUS (Extended Update Support) minor release repositories (and minor version pinning). As fas as i’m aware, no downstream RHEL rebuild project has supported this, including CentOS, which Rocky is planning to emulate (really interested if there are examples of downstream providers offering EUS). This is an exercise of back porting packages in the major release repository into minor releases, and even RHEL do this selectively. I agree this isn’t provided, but it’s also not something that CentOS (or for example, Oracle Linux, provide)
EUS is provided to pin to minor versions, primarily (in my experience) to maintain support positions with ISVs (Independent Software Vendors) that choose to certify against minor releases.
All security updates are still provided to the primary major release repository and then backported to EUS repositories when the primary repository moves forward a minor version. These backports are also selective (eg. only backporting security that are rated critical in later minor releases), and EUS minor repositories also have reduced support lifecycles.
Gluster and High Availability are treated as Add Ons and not core RHEL. High Availability is branded as “High Availability Add-On”. I agree these aren’t included in the Developer Subscription.
I am not sure the Developer Subscription was chosen as the source for Rocky, i’m not involved. The Gluster and HA Addons are likely available in the git repos, i’ll take a look.
The package manifest of the HA add-on is listed here:
Agreed they aren’t in the Developer Subscription, they are in the git.centos.org repository which I appreciate was what you were pointing our in your original post.
eg.
booth packages spec is here:
clufter is here:
etc.
No EUS was not what I was talking about
CentOS does not use RHEL SRPMS it uses git.centos.org which is contributed by RedHAT commits after RHEL,
I understand what CentOS uses as it’s source and how the source RPMs are provided to the CentOS project.
The security patch concern you initially raised “RHEL Dev Sub Terms indicates no security updates”, are you able to provide an example of the security patches (from core RHEL) that are currently in CentOS that aren’t available in Red Hat Developer Sub? keen to take a look. Are you using yum-versionlock to lock minor version in CentOS, or RHEL?
Is it just HA Addon and Gluster security patches? or core RHEL package security patches for minor versions too?
-edit-
Example of how CentOS handle minor OS release, with 8.3 released, 8.2 no longer receives backported patches to the minor release version and ‘8’ is pointed at current minor release ‘8.3’.
http://mirror.centos.org/centos/8.2.2004/readme
This directory (and version of CentOS) is deprecated. For normal users,
you should use /8/ and not /8.2.2004/ in your path. Please see this FAQ
concerning the CentOS release scheme:
https://wiki.centos.org/FAQ/General
If you know what you are doing, and absolutely want to remain at the 8.2.2004
level, go to http://vault.centos.org/ for packages.
Please keep in mind that 8.2.2004 no longer gets any updates, nor
any security fix's.
-edit 2-
Interesting that the storage packages in vault for 8.2 have been updated in December but BaseOS hasn’t been updated since June (expected, as this is when 8.3 was released).
storage/ 2020-12-08 07:08
Not sure what the CentOS policy is on updates for these additional packages, is that because they are outside BaseOS and managed by SIGs (eg. https://wiki.centos.org/SpecialInterestGroup/Storage)?
1 Like
Yrah, but CentOS 7 is still a downstream distro. We should not forget the mission of Rocky Linux. CentOS is becoming an upstream distribution. Rocky Linux was created to have an community maintained downstream offering for EL.
IMHO everything prior to the stream direction change in CentOS shouldn’t be our concern.