OpenELA's first code drop
OpenELA is excited to announce that the source code for all packages necessary for anyone to build a derivative Enterprise Linux operating system is now available. The initial focus is on EL8 and EL9, and packages for EL7 are forthcoming. The project is committed to ensuring the continued availability of EL sources to the community indefinitely.
The organization has also announced a technical
steering committee made up of "highly experienced individuals from
the founding companies
".
Posted Nov 3, 2023 17:17 UTC (Fri)
by rsidd (subscriber, #2582)
[Link] (18 responses)
If there's some other sort of "enterprise Linux" definition, they should say.
Posted Nov 3, 2023 17:59 UTC (Fri)
by epa (subscriber, #39769)
[Link]
Posted Nov 3, 2023 20:38 UTC (Fri)
by atai (subscriber, #10977)
[Link]
RedHat and clones
Posted Nov 4, 2023 0:06 UTC (Sat)
by Schroeder (subscriber, #128168)
[Link] (9 responses)
Posted Nov 4, 2023 0:40 UTC (Sat)
by pizza (subscriber, #46)
[Link] (1 responses)
"This Agreement establishes the rights and obligations associated with Subscription Services and is not intended to limit your rights to software code under the terms of an open source license." [1]
*nothing* in the GPL, or any other F/OSS license, obligates folks to provide a warranty, support, or access to future versions. Indeed, the GPL makes the opposite quite explicit, clearly stating that support and warranty is out of scope [2] and stating that a user exercising their source rights can be grounds for ceasing to provide updates and support. [3]
The only thing that gives you the right to obtain software through Red Hat's services is the RH subscription agreement, and they have *always* provided complete source code to every binary they distribute, via the same distribution mechanism, fully complying with the GPL's source requirements. However, if you are no longer (or never were) a customer, they provide a written offer for the complete source code for a given RHEL release [4], just to cover all the bases.
[1] https://www.redhat.com/licenses/Appendix-1-Global-English... (section 1.4)
Posted Nov 4, 2023 17:06 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
> "This Agreement establishes the rights and obligations associated with Subscription Services and is not intended to limit your rights to software code under the terms of an open source license." [1]
I've just looked up the four freedoms ...
0. The freedom to run the program as you wish, for any purpose.
How does the subscription service interfere with your ability to run the program? Isn't the whole point of the subscription to HELP you run it if you have problems?
1. The freedom to study how the program works, and change it so it does your computing as you wish. ...
How does the subscription service interfere with your ability to study and change the program? Of course, if you change it, RH/SUSE/Canonical et al may refuse to support it (unless you pay them extra), but why should they work for you, for free?
2. The freedom to redistribute copies so you can help your neighbor.
And the subscription service interferes with ability to share copies, just how? Sure, the subscription may force you to *choose* between sharing, and helping your neighbour, but there's an easy fix to that. Just get them to take out a subscription service, too.
3. The freedom to distribute copies of your modified versions to others.
And the subscription service interferes with your ability to do that, just how? You're no longer distributing someone else's supported product. If it goes wrong, it's YOU that will have to fix it, FOR FREE, according to your logic.
I've said it before, I'll say it again, others have said it too. If what RH/SUSE/Canonical et al are doing really is just lumping a load of free programs together, and their work has no value, why are people kicking up a stink because they refuse to give it away gratis? If it's worthless, why do you want it? Are you SURE it's worthless? And if it's actually worth something, why are you such a skinflint miser as to not want to pay the labourer his hire?
Cheers,
Posted Nov 4, 2023 19:18 UTC (Sat)
by sjj (guest, #2020)
[Link] (4 responses)
Can you give ONE example of them "making it harder and harder for people to do with it what open source is supposed to let them do"?
I would expect techy people to be able to use logic, not smears and innuendo.
(I don't or haven't worked at RH, but I have worked at another Linux company.)
Posted Nov 4, 2023 19:58 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (3 responses)
I doubt they're techy, and I doubt they're really linux people. Unfortunately, there are quite a few hooligans in the peanut gallery :-(
Cheers,
Posted Nov 6, 2023 8:32 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
According to wikipedia: A hooligan is a participant in hooliganism—unruly, destructive, or bullying behaviour.
Disagreeing and bullying/destroying aren't the same.
Posted Nov 6, 2023 10:43 UTC (Mon)
by hkario (subscriber, #94864)
[Link] (1 responses)
Posted Nov 6, 2023 13:13 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
One of the characteristics of hooligans, trolls, psychopaths, call them what you will, is that they LOOK for communities they can infiltrate and disrupt, just to give themselves kicks. Anyone who believes that can't happen here (and yes, Jon does make it much harder) has a touching faith in human nature which reality says doesn't exist.
(And I hate to say it, but it's obvious that a lot of people here, myself included, have strongly entrenched beliefs. These are EXTREMELY hard to tackle with logic. And it means we all can (and do) behave like hooligans sometimes. I just get the feeling though that some people aren't interested in logical and rational argument, they just want to enjoy an argument for the argument's sake.)
Cheers,
Posted Nov 5, 2023 6:58 UTC (Sun)
by jafd (subscriber, #129642)
[Link]
Posted Nov 5, 2023 16:22 UTC (Sun)
by jzb (editor, #7867)
[Link]
Red Hat doesn't develop everything or even a majority of the software it ships, true -- but there are very few, if any, organizations that contribute as much as Red Hat. Also very few that open source just about everything in their product line, even if Red Hat doesn't just throw open the gates and let non-customers download exact source to its products.
"Just bundles and sells" handwaves away all the work that goes into deciding what should be in a RHEL release, making sure that upstream projects developed separately co-exist together, legal research, translations, certification and testing work, carrying bugfixes back to RHEL when things are reported by customers, etc. It ignores things like supporting Python releases well past the EOL from upstream. It ignores all the additional components that Red Hat invests in like the Anaconda installer and ensuring that upgrades work from release to release (to whatever extent they do...)
Posted Nov 4, 2023 15:54 UTC (Sat)
by jzb (editor, #7867)
[Link] (5 responses)
Red Hat publishes code to CentOS Stream that roughly corresponds with RHEL, and invites people and organizations to work with that. It has taken steps to stop "bug for bug" compatible clones, or at least make that work harder. If that means OpenELA and any downstreams are touting "Enterprise Linux" code without direct claims of 1:1 compatibility with specific RHEL releases, that kind of seems like a win for Red Hat.
It means there's doubt around whether a OpenELA-derived release is actually "compatible" with the RHEL release. So if people are shopping for RHEL, and not just an "enterprise Linux" release, that makes it more likely they'll go to Red Hat. If you actually "need" RHEL, maybe you'll actually buy a subscription instead of using a clone. And if all you want/need is something that kind of looks like RHEL and you're happy to forego all the certifications and such -- take your chances with one of the OpenELA distros.
* As long as they're not stripping any copyright notices or things like that.
Posted Nov 6, 2023 20:40 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (4 responses)
Obviously, this is abusive of Red Hat's subscription, and they are well within their rights to prohibit it. The only real question, to my mind, is exactly what means they can or should use to enforce that prohibition, and exactly how it ought to be worded (technically, the customer only ever installs RHEL on one workstation at a time, so you can't just prohibit multiple installations...). I imagine there are probably other permutations of "install CentOS, buy RHEL support, and use the one for the other," but the above is probably the most tricky to outright ban. I imagine that CentOS might have been internally seen as an attractive nuisance for this sort of client misbehavior, and so they got rid of it.
(In case it's not obvious: A few hundred workstations will have problems at a higher rate than a single workstation. You are asking Red Hat to do more work, and refusing to pay for it, so that's abusive.)
Posted Nov 7, 2023 3:26 UTC (Tue)
by calumapplepie (guest, #143655)
[Link] (3 responses)
To my knowledge, most Red Hat customers never use the support at all; they just paid for Red Hat so that they'd have the OS which their proprietary software vendor said was supported. If you can get a bug-for-bug identical OS without paying Red Hat at all, then why wouldn't you?
Posted Nov 7, 2023 10:14 UTC (Tue)
by zuki (subscriber, #41808)
[Link] (1 responses)
80% of the value⁽¹⁾ of the service provided by Red Hat is timely updates with few regressions. So even if the customer never opens a ticket or makes a support call, they are using the support provided. If there never is a major bug worthy of a opening a ticket, then that's Red Hat QA working as expected.
Testing of RHEL packages with various proprietary (or not) software vendor's third party stuff is also part of the work done by Red Hat. And fixing regressions — if an update breaks 3rd party stuff, it will be fixed/reverted/redone. That is part of the "support" too.
⁽¹⁾ number made up ;)
Posted Nov 9, 2023 3:18 UTC (Thu)
by sionescu (subscriber, #59410)
[Link]
Posted Nov 7, 2023 10:40 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
Re-imaging is trivial - it's literally "click the button, reboot the system and wait". The only hard part in the whole thing is being careful with your licensing, so that you've not got more copies of anything in use than you're paying for - but you're doing that anyway, because your proprietary software terms allow for audits, and have huge fees included if you fail an audit; e.g. one package I've encountered had a "list price" of over $100,000/month per user in a month, but you could easily negotiate down to under $10,000/year per concurrent user. Fail audit, and you would be expected to pay list price for that month; so, having had 10 concurrent users, and 30 engineers using it in a month, you'd go from under $100,000 in a year to $3,000,000 for the month in which you were audited and found to have more concurrent users than you'd paid for.
In this sort of situation, you've already built tooling and processes to guarantee that you comply with the licensing rules, because of the cost of failing to do so, but you'd still like to cut out the $9,000/year "overhead" you pay for RHEL with Standard Support for 30 engineers using RHEL workstations with the expensive proprietary software. Doing so by reimaging with real RHEL (bearing in mind that in the environment I saw this in, workstations are reimaged daily to stop engineers saving work locally instead of on the NetApp) whenever a bug needs reporting is cheap, especially since your bug-for-bug rebuild of RHEL is unlikely to have many bugs. And most of the cost is "fluffy" cost, in terms of engineers not doing their work but waiting to use the "real" RHEL system to reproduce a bug to be reported to the tool vendor or to RHEL support.
Posted Nov 3, 2023 18:16 UTC (Fri)
by pizza (subscriber, #46)
[Link] (29 responses)
I mean, if they try to make any technical changes, by definition they're no longer "EL" compatible.
Posted Nov 3, 2023 19:13 UTC (Fri)
by aklaver (guest, #62352)
[Link] (11 responses)
Our Mission:
To establish and make accessible the sources, tooling, and assets to all members, collaborators, and the open source Enterprise Linux distribution developers to create and maintain 1:1 downstream derivatives of EL
Posted Nov 3, 2023 19:26 UTC (Fri)
by pizza (subscriber, #46)
[Link] (10 responses)
Sure, they _could_ scrap all of the existing CentOS tooling, but... why? It would be a ton of work, and all they would accomplish along the way would be to (greatly) increase the risk of divergence from upstream 1:1 binary+bug compatibility, which... again, is the entire point of OpenELA.
Again, there are no "technical steering" decisions to be made in a project whose sole mission is to be a (zero-cost) 1:1 downstream derivative of someone else's technical/engineering decisions.
[1] Essentially perform a 1:1 clone of the completely-open CentOS tooling, replace dist-git with their own, s/CentOS/OpenELA/g, hit rebuild.
Posted Nov 3, 2023 19:49 UTC (Fri)
by yodermk (subscriber, #3803)
[Link] (7 responses)
Posted Nov 3, 2023 20:07 UTC (Fri)
by pizza (subscriber, #46)
[Link] (6 responses)
Red Hat is currently just as open with their sources as SuSE and Canonical, and all fully comply with the letter and spirit of the GPL. Why the selective outrage?
Posted Nov 3, 2023 20:24 UTC (Fri)
by ballombe (subscriber, #9523)
[Link] (5 responses)
Posted Nov 3, 2023 22:06 UTC (Fri)
by pizza (subscriber, #46)
[Link] (4 responses)
"... You may not: (a) use any Subscription Offering or SUSE Product for the benefit, directly or indirectly, of any third party, which includes making the Subscription Offering or SUSE Product available as part of any product or service that is sold, leased, rented or otherwise made available by You; (b) allow a third party to use or access, directly or indirectly, or otherwise benefit from, any of Your Subscription Offerings or SUSE Products; or (c) assign or transfer the Subscription Offering to any third party."
This is materially identical to the language in RHEL's agreement.
Canonical's agreements are a bit more tangled, but their "ubuntu pro personal agreement" section 3, includes this text:
"You must not use the software made available through the Service for more than the entitled number of physical or virtual Ubuntu systems except as otherwise agreed, nor resell or attempt to resell the Services"
The non-personal Pro terms include similar language to the above in section 5.1, but adds a lot more, incluidng section 12.3 -- "There are no intended third party beneficiaries to this Agreement. " and references a UK law that I can't be bothered to look up.
So there's arguably a bit of wiggle room such that you can technically give it all away gratis to third parties, but it appears to be the same sort of "you can only use the services on the number of systems licensed, and don't let third parties get the benefit of the subscription" spirit as SuSE and RHEL."
Meanwhile, neither Canonical or SuSE provide source code for their extended releases (ie >5yr after initial release) to non-subscribers (ie just like Red Hat) and all three reserve the right to terminate the agreement at any time, for any reason.
So, yeah. Why does everyone else get a free pass for essentially the same behavior, especially when they've been doing it for much longer?
Posted Nov 4, 2023 12:35 UTC (Sat)
by ballombe (subscriber, #9523)
[Link] (3 responses)
Posted Nov 4, 2023 13:29 UTC (Sat)
by gfernandes (subscriber, #119910)
[Link] (2 responses)
The two are - and rightly so - completely independent of each other.
And the GPL *expressly" separates them.
Posted Nov 4, 2023 15:47 UTC (Sat)
by ballombe (subscriber, #9523)
[Link] (1 responses)
Posted Nov 4, 2023 17:29 UTC (Sat)
by gfernandes (subscriber, #119910)
[Link]
Posted Nov 3, 2023 21:07 UTC (Fri)
by tzafrir (subscriber, #11501)
[Link] (1 responses)
Neither the original one, nor any Oracle "Unbreakable" kernel one.
Posted Nov 4, 2023 16:40 UTC (Sat)
by zuki (subscriber, #41808)
[Link]
Posted Nov 4, 2023 16:01 UTC (Sat)
by jzb (editor, #7867)
[Link] (16 responses)
I feel like that would be more honest and actual competition, rather than leaving it to Red Hat to do all the work up to releasing the code and then rushing behind them to compile it and undercut Red Hat on pricing and little else.
IMO, it's not particularly good for the larger industry/ecosystem to undercut Red Hat's revenue and ability to develop software while not picking up the slack. If SUSE, Oracle, and CIQ are out there hiring all the folks who support the types of work Red Hat is doing (not only coding, but testing, product management, etc.) then great. If they're just siphoning the code and then making it harder for Red Hat to pay for the work that goes into RHEL... not so good.
Posted Nov 6, 2023 11:18 UTC (Mon)
by rolexhamster (guest, #158445)
[Link] (13 responses)
There are already 2 community "EL" distros that compete with RHEL: (1) Debian LTS and (2) Ubuntu LTS, both of which ship a ton of code developed and/or checked by Red Hat (i.e. indirectly paid for by subscriptions to RHEL).
It can also be argued that CentOS Stream is a competitor of sorts to RHEL as well. Even though Red Hat killed the original CentOS project, OpenELA can and will use CentOS Stream sources against Red Hat.
CentOS Stream is ostensibly meant as an intermediary between Fedora and RHEL, as part of the pipeline for developing and stabilizing RHEL releases (major and minor). Unless OpenELA steps up and actually contributes something of meaningful value to CentOS Stream, I can't see how the current status quo with CentOS Stream will continue.
CentOS Stream has no value to Red Hat unless RH gets something out of it (say, at the very least, bug reports). To a large extent, Fedora already serves as a decent testing ground for RHEL. Red Hat (or IBM) execs will either withdraw support from CentOS Stream, or (most likely) change it to an internal Red Hat project, absorbing it into the internal RHEL development process. Only Fedora would remain as the publicly available upstream to RHEL.
Posted Nov 6, 2023 11:34 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (2 responses)
I'd just note that CentOS Stream used to be an internal Red Hat project as part of the internal RHEL development process, and not something that was publicly exposed. Reversing that decision would cost Red Hat a lot more goodwill than cracking down on bug-for-bug clones of RHEL has done, since many consumers of CentOS Stream are people who transitioned away from bug-for-bug clones and who now contribute by providing useful bugs reports and/or code to CentOS Stream.
Posted Nov 6, 2023 11:45 UTC (Mon)
by rolexhamster (guest, #158445)
[Link] (1 responses)
Posted Nov 6, 2023 14:08 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
Yes - I see contributions to CentOS Stream and to ELN (the upstream of CentOS Stream) coming from my former employer, and I've never worked for Red Hat. From what I can tell from the outside, these are genuinely useful contributions, too, not just "foo doesn't work" type of reports.
Posted Nov 6, 2023 14:02 UTC (Mon)
by pizza (subscriber, #46)
[Link]
Not quite. "EL Next" (ELN) is the intermediate step between Fedora and RHEL. CentOS Stream is a rolling release distro of what will the next RHEL point release, with each update going through RH's full QA pipeline.
ELN (public) -> Stream boostrap (internal) -> Stream + RHEL .0 release (public)
After the .0 release, subsequent .X releases are snapshotted/branched from the current state of Stream.
Posted Nov 6, 2023 15:04 UTC (Mon)
by jhoblitt (subscriber, #77733)
[Link] (2 responses)
Posted Nov 6, 2023 15:11 UTC (Mon)
by jhoblitt (subscriber, #77733)
[Link]
Posted Nov 7, 2023 11:35 UTC (Tue)
by rolexhamster (guest, #158445)
[Link]
Each Ubuntu release is essentially a snapshot of Debian unstable at a particular point of time. Ubuntu may add a bit of sprinkling here and there, but much (if not the majority) of the direction setting and QA has already been "done" at the snapshot stage (via Debian processes and policies) by volunteers and organizations supporting Debian.
The additional QA for Ubuntu LTS releases is also mainly done by volunteers (i.e. the users). When LTS version (N).04.0 is released, users of LTS version (N-1).04.x are not automatically prompted to upgrade. Instead, Canonical waits until "enough" bugs have been reported and shaken out, then releases LTS version (N).04.1, and then finally allows upgrades from version (N-1).04.x. In other words, each Ubuntu (N).04.0 LTS release is in fact a public beta release, all while Canonical pretends it's not.
Posted Nov 7, 2023 3:34 UTC (Tue)
by calumapplepie (guest, #143655)
[Link] (5 responses)
I disagree with the implication that Ubuntu and Debian are Red Hat supported. Yes, Red Hat spends a ton of time and money on LTS for software. So does Canonical. So do Debian developers. Determining who spends the most would be really hard; Debian devs support obscure architectures that nobody else does, Canonical is a whole blown competitor to Red Hat, etc. Implying that either of those would not exist were it not for Red Hat is a bit silly.
Posted Nov 7, 2023 11:56 UTC (Tue)
by rolexhamster (guest, #158445)
[Link] (4 responses)
Eh? No such implication was made. In the hypothetical scenario where Red Hat never existed, Debian and Ubuntu may still exist, but would almost certainly not be as good as they are now.
Debian and Ubuntu contain a truckload of software developed and/or checked by Red Hat, simply by the virtue of Red Hat widely participating in the open source / free software ecosystem (e.g. via Fedora and upstream contributions to many projects). Red Hat's participation is paid for by RHEL subscriptions (support contracts).
Posted Nov 7, 2023 18:21 UTC (Tue)
by amacater (subscriber, #790)
[Link] (3 responses)
Debian is also the upstream for several projects. Numbers of packages is not necessarily a metric
[Full disclosure: I'm a Debian developer and have been a sysadmin for many years - there's a *reason*
LWN no longer maintains the Distributions list but relative popularity of Debian-derived vs. Red Hat derived distributions is instructive.
Posted Nov 7, 2023 20:24 UTC (Tue)
by zdzichu (subscriber, #17118)
[Link]
Posted Nov 7, 2023 21:12 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (1 responses)
And the ones that are neither ... ?
Slackware may not have the numbers, but it still has quite some mindshare. The Gentoo family ...
And of course there's SUSE which, while it now uses RPM, it predates Red Hat ...
Cheers,
Posted Nov 7, 2023 21:39 UTC (Tue)
by zdzichu (subscriber, #17118)
[Link]
Posted Nov 14, 2023 13:25 UTC (Tue)
by durikmel (subscriber, #162032)
[Link] (1 responses)
Posted Nov 14, 2023 14:02 UTC (Tue)
by pizza (subscriber, #46)
[Link]
1) Pull patches from upstream EL (ie RHEL or CentOS Stream).
...In other words, they only intend to accept changes already vetted by Red Hat QA. (So much to providing their own QA resources...)
That said, they also have a "-contrib" repository for ABI-incompatible modifications to upstream packages or packages that don't exist upstream in RHEL/CentOS already. It remains to be seen what this repo (and their governance therof) will offer that existing EL add-on repos (eg EPEL, RPMFusion, etc) do not. Also noteworthy is that there's zero promises made about ABI (or any other form of) stability for -contrib stuff.
Lots of high-minded rhetoric here, but in the end, it's still just a 1:1 rebuild of RHEL, and still lacks any concrete details on how they're going to handle updates between the five-year delta between the EOL of CentOS Stream X and RHEL X. (For free. Since that's the _only_ thing its prospective users actually care about...)
Posted Nov 4, 2023 10:03 UTC (Sat)
by cyperpunks (subscriber, #39406)
[Link] (6 responses)
Posted Nov 4, 2023 14:14 UTC (Sat)
by pizza (subscriber, #46)
[Link]
It's not "money" that's needed per se; instead what's needed is reliable developers that do the actual work.
I can only imagine the difference it would make if the dozen or so people on that "technical steering committee" were paid by these companies to work full-time on Fedora (or even CentOS Stream) instead.
That way they can have an actual technical influence on the development of RHEL (and thus "EL"), and would ironically far better support their own mission statement in the process, both in the core "EL" but also "extras", most of which currently come via Fedora!
Red Hat got where they are today (and stay there!) because *they pay people to do the work* to make it happen (publicly, in ELN, CentOS and Fedora) and *pay people to do the work* of supporting it for a decade afterwards.
Posted Nov 5, 2023 23:06 UTC (Sun)
by jccleaver (guest, #127418)
[Link] (4 responses)
Frankly, the entire RedHat ecosystem could have done with an inversion, to mirror how the Debian universe works, where the "core" stable system is community-driven and the faster-moving, more fragile, and desktop focused distros build off of that. Instead, in RH-land, server admins have to deal with dumb Fedora decisions for years that have trickled down from years prior and are far too late to undo. And even when Fedora *has* reverted to sanity (eg, Modularity), the nature of long-term releases means EL users are stuck with it.
I'd prefer to see something OpenELA take direct control over the steering of the Rawhide repository, while Fedora hangs off of that and does whatever its Workstation users think is necessary, and RHEL does its certification and special sauce downstream of either (or both)... But I'm glad to see OpenELA take these first steps.
Posted Nov 6, 2023 6:50 UTC (Mon)
by pbonzini (subscriber, #60935)
[Link]
Not going to happen; OpenELA doesn't want to actually make engineering choices.
Posted Nov 6, 2023 11:40 UTC (Mon)
by rolexhamster (guest, #158445)
[Link]
Why should Red Hat do that? If you disagree with the directions taken by Red Hat, and prefer Debian (the OS) and/or how the Debian development process works, why not just simply use Debian (or Ubuntu) in the first place?
If you want super long term support in the Debian "universe", you can either pay Canonical (Ubuntu) for the service, or contribute to Debian LTS efforts. It's that simple.
Otherwise all your arguments end up sounding rather privileged.
Posted Nov 6, 2023 13:32 UTC (Mon)
by pizza (subscriber, #46)
[Link] (1 responses)
Modularity was a case of the tail wagging the dog, actually. RH pushed for it in Fedora (and did all of the work!) because they wanted it in an upcoming RHEL release, and Fedora is RHEL's upstream.
Posted Nov 7, 2023 3:36 UTC (Tue)
by calumapplepie (guest, #143655)
[Link]
Posted Nov 10, 2023 14:59 UTC (Fri)
by carlosrodfern (subscriber, #166486)
[Link]
OpenELA's first code drop
OpenELA's first code drop
OpenELA's first code drop
OpenELA's first code drop
OpenELA's first code drop
[2] GPLv3 section 15, plus section 4, paragraph 2.
[3] GPLv3 section 6, paragraph 6.
[4] Mail them $5, and you'll get back a USB stick with everything.
OpenELA's first code drop
Wol
OpenELA's first code drop
OpenELA's first code drop
Wol
OpenELA's first code drop
OpenELA's first code drop
OpenELA's first code drop
Wol
OpenELA's first code drop
OpenELA's first code drop
OpenELA's first code drop
** I am a former Red Hat employee, but don't take anything I say as past or current official Red Hat stance on anything. Whether Red Hat as a company minds the omission of the words "Red Hat" is just speculation on my part.
OpenELA's first code drop
OpenELA's first code drop
OpenELA's first code drop
OpenELA's first code drop
OpenELA's first code drop
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
To allow and encourage contributions and enhancements from the upstream community in the form of “extras”
To always act in the best interests of the open source community and all downstream derivatives
To create an inclusive community of organizations and individuals to ensure the longevity, stability, and management of this project
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
Thanks for clearing that up.
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
I would love to see them attempt to establish a community EL that they drive and compete with RHEL as a standard.
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
<i>
... many consumers of CentOS Stream are people who transitioned away from bug-for-bug clones and who now contribute by providing useful bugs reports and/or code to CentOS Stream.
</i>
</ul>
Is there actually evidence of this, and are these bug reports making a meaningful difference? (Genuine question -- I haven't checked CentOS Stream bug reports). If indeed it's true, CentOS Stream would be providing value to Red Hat, which would hopefully offset the damage caused by OpenELA.
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
I would not characterize Ubuntu as a community distribution. How many non-canonical employees decide the direction of the distro, what is packaged in each release, and perform QA?
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
I disagree with the implication that Ubuntu and Debian are Red Hat supported (...) Implying that either of those would not exist were it not for Red Hat is a bit silly.
"technical steering committee" for a project that does no engineering of their own
maintains ports for other machine types.
but the Debian package universe comfortably dwarfs RHEL and EPEL together, I think.
my home machines and hosting all runs Debian :) ]
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
Wol
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
"technical steering committee" for a project that does no engineering of their own
2) When that's not possible, contribute changes to upstream first (ie CentOS Stream)
3) Anything that's not already upstream will be handled in a TBD manner.
Missing donation to Fedora
Missing donation to Fedora
Missing donation to Fedora
Missing donation to Fedora
Missing donation to Fedora
... to mirror how the Debian universe works ...
Missing donation to Fedora
Missing donation to Fedora
OpenELA's first code drop