First off, IBM, the big company, has nothing to do with any of Red Hat development. We (Red Hat) are a completely separate company whose profits go to IBM. We have a completely separate legal staff, health care, management, engineers, policies, everything. So, quit saying that we (Red Hat) get access to all their lawyers and engineers. We don't have access to that any more than any other partner. We also don't have to work according to their policies, we have to work according to Red Hat's policies, which are sometimes more strict, and sometimes less strict.
On Wed, May 5, 2021 at 8:32 AM Yasha Karant <[email protected]> wrote: > You stated: > > all sorts of tests that we can't do in > public, and make tweaks and changes that we can't do in public. This is > mainly due to hardware NDA's, and security stuff. > > End excerpt. > > 1. Are these NDA enabled tweaks, changes, and tests that are in the > production releases of IBM RH EL ("binary" installable "executables" > only available under license for fee) fully and identically > (defect-for-defect, etc) reproduced currently in CentOS (soon to be EOL) > and thus in SL, etc., assuming that these are built from the IBM RH > released source code? > > All of Red Hat's source code is completely released, tweaks and all, when the product is released. Anybody can use that code. CentOS, S.L., Alma, Rocky, Oracle, even you, can freely download that code from the git repo's and do whatever you want with it. As was noted in a different email on this thread, you can freely get it from the git repo's that are currently at git.centos.org. Due to the EULA you cannot use the source rpm's that you get from your subscription to build your own release. That's a legal thing that makes my head hurt. But all the source that is those source rpm packages, is in the publically available git repo's. No subcription, or signup required. > 2. "Security" -- you are including in this term the "hardening" of EL > compared to, say, Fedora or "enthusiast" distributions. If the > "security" is done to any application that is derivative of a source > code file that is under an "open systems" EULA, my understanding is that > IBM RH would be required to release, not under NDA, the same security > modifications. > > All of Red Hat's source code is completely released, tweaks and all, when the product is released. See my previous answer. > 2.1 Presumably, the large staff of legal professionals (eg, JDs) > employed by IBM (and thus IBM RH) would do whatever is necessary through > torts, actions, etc., to prevent the release of (1) or (2) to non-IBM > entities if release is viewed to negatively impact the "financials" of > IBM (including market share, cash flow, etc.). Even if the "other side" > has deep enough pockets to counter the above, by the time interval that > the legal proceedings have concluded (unless these result in a permanent > enforceable consent decree against the company and any of its successors > -- tied to the intellectual property and the derivatives/successors > thereof, not the current owner thereof), the modifications effectively > are syntactically "obsolete". > > 2.1 is completely false, pretty much to every degree. I already explained the IBM thing, but let me go back to my history, and why I joined Red Hat. I am one of the original creators and developers of Scientific Linux. Connie and I were making Fermi Linux based off Red Hat Linux (RHL) before Scientific Linux. When Red Hat stopped RHL, and started Red Hat Enterprise Linux (RHEL), they started a whole different process, with a whole different EULA. No longer would you be able to take their binaries and create your own distribution. They were still working within the GPL, and the GPL gives them that right. At the time, the other enterprise linux distribution was SUSE. With SUSE, they also followed the GPL, and if you were a customer, you could get access to their source rpms. They put alot of hurdles in the way, so even as a customer, it was hard to get their source code. We (Connie and I) were very worried about this happening at Red Hat. But, it didn't. >From the very beginning of RHEL, all of their source for RHEL has been publically available. Originally it was via srpms at ftp.redhat.com, and now in the git repos at git.centos.org. Just think about that. Here you have a new product, that you are asking people to buy, and at the same time, you are giving away your source, in an easy to consume way, in a public area. It was very gutsy and courageous. >From the very beginning, they knew what we (Scientific Linux, CentOS, White Box ... etc) were going to do. They were ok with it. And rather than just withering away, this completely open policy, made them grow, and continues to make them grow. That was why I wanted to work at Red Hat. They had courage, and they were very open. After joining, and working here for as long as I have, I still like it. It's very open, and we continue to open things even more, internally and externally. Anyway, I can either make things short, or I get into these long stories. This has been sorta a fun run down memory lane, but I really do have other work to do. I hope I explained things enough. Others on this list can fill in the gaps. Troy Dawson > Yasha Karant > > On 5/5/21 8:09 AM, Troy Dawson wrote: > > > > On Tue, May 4, 2021 at 10:01 AM Yasha Karant <[email protected] > > <mailto:[email protected]>> wrote: > > > > If I correctly have read the RH EL9 CentOS announcement below, EL 9 > > will be in production before the end of this year, leapfrogging EL 8 > as > > it were. > > > > > > I just want to clean up one point, because it seems you mis-understood > > the announcement. > > > > RHEL9 will not be in "Production" before the end of the year. It will > > be in "Open Development". [1] > > > > Starting with RHEL8, RHEL now has 3 years between major releases. (8, 9, > > 10), and six months between minor releases (8.4, 9.1). > > RHEL9 will not go into "Production" until 3 years after RHEL8 was > released. > > > > But development of a release takes several years. > > In previous releases, everything was done behind closed doors. For > > RHEL8 I wasn't allowed to even say I was working on RHEL8. > > For RHEL9, everything completely flipped open. The goal was, and is, to > > have everything as completely open as possible. > > If people want, I could go into each step, but let me make this brief > > and not do that. > > By the end of the year, you, or anyone, can watch the whole process[2]. > > Not just the "here is this days/weeks/months release". But you will be > > able to watch, live, the RHEL developers git commits, merges, build, > > watch koji building the package, the package getting tagged, and so > forth. > > That's why I'm calling it "Open Development", because anyone will be > > able to watch the development. > > > > So, what is the difference between that and a release? > > We (Red Hat) do not stand behind the packages until they are released in > > production. And only the packages released in production. > > There will be a time that we take one of the snapshots, bring it behind > > closed doors and subject it to all sorts of tests that we can't do in > > public, and make tweaks and changes that we can't do in public. This is > > mainly due to hardware NDA's, and security stuff. That internal testing > > takes months. > > After those tests and tweaking is done, and marketing says the time is > > right, we will release the production release of RHEL 9.0. > > > > I hope this clears things up. > > > > Troy Dawson > > > > [1] - "Open Development" is my term, not a Red Hat term. I find it more > > descriptive. > > [2] - There are three exceptions to the completely open process. 1 - > > embargoed CVE's, 2 - code partners will not let us show until released, > > 3 - some previously internal only package that got missed. Number 3 is > > small, and hopefully should go away. >
