Aikido Security says more than 30 official @redhat-cloud-services npm packages were compromised with a credential-stealing worm called "Miasma," a variant resembling the open-sourced Mini Shai-Hulud supply-chain malware. "The packages were published via GitHub Actions OIDC, indicating the CI/CD pipeline was compromised rather than an npm token," the report says. "If you have installed any affected package versions since June 1, 2026, treat all CI secrets, cloud credentials, SSH keys, and npm tokens as compromised and rotate them immediately." From the report: Each compromised package declares a preinstall script in its package.json that executes node index.js automatically on every npm install, before any application code runs and before the developer has any indication something is wrong. The index.js file is 4.2 MB payload hidden behind multiple layers of obfuscation.

As with previous Mini Shai-Hulud attacks, the payload performs a broad credential sweep across cloud providers, CI/CD environments, and developer tooling. On the CI side it targets GitHub Actions secrets including GITHUB_TOKEN and ACTIONS_RUNTIME_TOKEN. For cloud credentials it collects AWS access keys and session tokens, GCP application default credentials and service account key files, and Azure service principal credentials and managed identity tokens. It also sweeps for HashiCorp Vault tokens, Kubernetes service account tokens and kubeconfig files, npm and PyPI publish tokens, SSH private keys, Docker registry credentials, GPG keys, and any .env files it can find across the filesystem.

IBM and Red Hat are committing $5 billion to a new initiative called "Project Lightwell," which aims to secure open-source software supply chains with AI-assisted vulnerability discovery, triage, patch validation, and upstream maintenance. Longtime Slashdot reader wiggles shares a press release from IBM: IBM and Red Hat today announced Project Lightwell, a $5 billion commitment backed by new frontier AI capabilities and a global force of more than 20,000 engineers to help enterprises secure open source software. Together, these investments establish a new model for enterprise use of open source software, from upstream development through production environments.

Project Lightwell will establish a trusted enterprise clearinghouse combined with a global force of engineers to identify and fix vulnerabilities at scale. The clearinghouse will serve as a security coordination layer, using advanced AI capabilities to validate and test fixes across an unprecedented volume of open source code. These capabilities will be offered through commercial subscriptions, allowing enterprises to integrate secure patches directly into their existing software supply chains with enterprise-grade validation and lifecycle management.

IBM and Red Hat have already begun collaborating with a select group of early adopters on Project Lightwell, including Bank of America, BNY, Citi, Goldman Sachs, JPMorganChase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa and Wells Fargo. The real-world insights from these initial deployments will actively shape how vulnerabilities are identified, validated, and remediated at scale across complex software supply chains.

Red Hat has released RHEL 10.2 and 9.8 with new AI-assisted command-line tools. The releases also add updated developer toolchains such as Go 1.26, LLVM 21, Rust 1.92, Python 3.14, and PHP 8.4. Phoronix reports: Red Hat Enterprise Linux has introduced the goose command for power users. Goose is an optional CLI AI assistance with model context protocol (MCP) integration. There is also improved visual output via color output enhancements. As for their rationale with the new AI integration: "The business value: Faster problem resolution, and a quicker path for new administrators to become proficient. This translates into higher developer productivity and accelerated project timelines."

The blog It's FOSS has an update on the Fedora AI Developer Desktop Initiative, a proposed platform for AI/machine learning workloads on Fedora. It's now been blocked "after two Fedora Council members retracted their earlier approval votes." The initiative was proposed by Red Hat engineer Gordon Messmer, aiming to deliver an Atomic Desktop with accelerated AI workload support, covering developer tools, hardware enablement, and building a community around AI on Fedora... At the May 6 council meeting, the members unanimously voted to approve this new initiative. After which a short, lazy consensus window was left open until May 8 to accommodate absent members, after which the decision was to be ratified.

But that last bit never happened, as council member Justin Wheeler (Jflory7) was the first person to change their vote to -1... ["While I strongly support leveraging AI to establish Fedora as a leading platform, completely rearchitecting our kernel strategy is a massive structural shift. It requires explicit alignment with our legal and engineering stakeholders before we commit the project to this path."] Following that, fellow council member Miro HronÄok (churchyard) put in his -1, saying that he had originally assumed the proposal was purely additive and therefore uncontroversial. But seeing the community's response, he realized that he was mistaken about that. As an elected representative, he felt the need to reflect on this major proposal before signing it off.

Over 180 replies have piled up in the proposal's discussion thread, with many well-known Fedora contributors pushing back on things like kernel policy, proprietary software, and project identity. Hans de Goede from the packaging team called out the proposal's emphasis on CUDA support as going against Fedora's foundational commitment to free software, arguing that open alternatives like AMD's ROCm and Intel's oneAPI should be the focus instead.

"We have removed all malicious artifacts from the affected registries and channels," Trivy maintainer Itay Shakury posted today, noting that all the latest Trivy releases "now point to a safe version." But "On March 19, we observed that a threat actor used a compromised credential..."

And today The Hacker News reported the same attackers are now "suspected to be conducting follow-on attacks that have led to the compromise of a large number of npm packages..." (The attackers apparently leveraged a postinstall hook "to execute a loader, which then drops a Python backdoor that's responsible for contacting the ICP canister dead drop to retrieve a URL pointing to the next-stage payload.") The development marks the first publicly documented abuse of an ICP canister for the explicit purpose of fetching the command-and-control (C2) server, Aikido Security researcher Charlie Eriksen said... Persistence is established by means of a systemd user service, which is configured to automatically start the Python backdoor after a 5-second delay if it gets terminated for some reason by using the "Restart=always" directive. The systemd service masquerades as PostgreSQL tooling ("pgmon") in an attempt to fly under the radar...

In tandem, the packages come with a "deploy.js" file that the attacker runs manually to spread the malicious payload to every package a stolen npm token provides access to in a programmatic fashion. The worm, assessed to be vibe-coded using an AI tool, makes no attempt to conceal its functionality. "This isn't triggered by npm install," Aikido said. "It's a standalone tool the attacker runs with stolen tokens to maximize blast radius."

To make matters worse, a subsequent iteration of CanisterWorm detected in "@teale.io/eslint-config" versions 1.8.11 and 1.8.12 has been found to self-propagate on its own without the need for manual intervention... [Aikido Security researcher Charlie Eriksen said] "Every developer or CI pipeline that installs this package and has an npm token accessible becomes an unwitting propagation vector. Their packages get infected, their downstream users install those, and if any of them have tokens, the cycle repeats."
So far affected packages include 28 in the @EmilGroup scope and 16 packages in the @opengov scope, according to the article, blaming the attack on "a cloud-focused cybercriminal operation known as TeamPCP."

Ars Technica explains that Trivy had "inadvertently hardcoded authentication secrets in pipelines for developing and deploying software updates," leading to a situation where attacks "compromised virtually all versions" of the widely used Trivy vulnerability scanner: Trivy maintainer Itay Shakury confirmed the compromise on Friday, following rumors and a thread, since deleted by the attackers, discussing the incident. The attack began in the early hours of Thursday. When it was done, the threat actor had used stolen credentials to force-push all but one of the trivy-action tags and seven setup-trivy tags to use malicious dependencies... "If you suspect you were running a compromised version, treat all pipeline secrets as compromised and rotate immediately," Shakury wrote.

Security firms Socket and Wiz said that the malware, triggered in 75 compromised trivy-action tags, causes custom malware to thoroughly scour development pipelines, including developer machines, for GitHub tokens, cloud credentials, SSH keys, Kubernetes tokens, and whatever other secrets may live there. Once found, the malware encrypts the data and sends it to an attacker-controlled server. The end result, Socket said, is that any CI/CD pipeline using software that references compromised version tags executes code as soon as the Trivy scan is run... "In our initial analysis the malicious code exfiltrates secrets with a primary and backup mechanism. If it detects it is on a developer machine it additionally writes a base64 encoded python dropper for persistence...."

Although the mass compromise began Thursday, it stems from a separate compromise last month of the Aqua Trivy VS Code extension for the Trivy scanner, Shakury said. In the incident, the attackers compromised a credential with write access to the Trivy GitHub account. Shakury said maintainers rotated tokens and other secrets in response, but the process wasn't fully "atomic," meaning it didn't thoroughly remove credential artifacts such as API keys, certificates, and passwords to ensure they couldn't be used maliciously.

"This [failure] allowed the threat actor to perform authenticated operations, including force-updating tags, without needing to exploit GitHub itself," Socket researchers wrote.
Pushing to a branch or creating a new release would've appeared in the commit history and trigger notifications, Socket pointed out, so "Instead, the attacker force-pushed 75 existing version tags to point to new malicious commits." (Trivy's maintainer says "we've also enabled immutable releases since the last breach.")

Ars Technica notes Trivy's vulnerability scanner has 33,200 stars on GitHub, so "the potential fallout could be severe."

Another highly influential Linux kernel engineer, David Hildenbrand, is leaving Red Hat after a decade of major contributions to memory management, virtualization, and VirtIO. His recent kernel patch updates his maintainer info to a kernel.org address, signaling his departure. He hasn't yet said where he's headed next. Phoronix reports: David Hildenbrand serves as a reviewer for the HugeTLB code, s390 KVM code, and memory management reclaim code. He also serves as an upstream maintainer for the Linux kernel's core memory management code, Get User Pages (GUP) memory management code, kernel samepage merging (KSM), reverse mapping (RMAP), transparent hugepage (THP), memory advice (MADVISE), VirtIO memory driver, and VirtIO balloon driver.

Hildenbrand had been employed by Red Hat the past decade in Munich working on QEMU/KVM virtualization, Linux kernel memory management, VirtIO, and related low-level areas. Just this year alone so far in 2025 he's authored or been mentioned on more than one thousand mainline Linux kernel patches.

A hacking group claims to have pulled data from a GitLab instance connected to Red Hat's consulting business, scooping up 570 GB of compressed data from 28,000 customers. From a report: The hack was first reported by BleepingComputer and has been confirmed by Red Hat itself. "Red Hat is aware of reports regarding a security incident related to our consulting business and we have initiated necessary remediation steps," Stephanie Wonderlick, Red Hat's VP of communications told 404 Media.

A file released by the hackers and viewed by 404 Media suggested that the hacking group may have acquired some data related to about 800 clients, including Vodafone, T-Mobile, the US Navy's Naval Surface Warfare Center, the Federal Aviation Administration, Bank of America, AT&T, the U.S. House of Representatives, and Walmart.

Starting in 2026, Red Hat's back-office staff in HR, finance, legal, and accounting will be transferred to IBM, while engineering, product, sales, and marketing teams remain at Red Hat -- at least for now. The Register reports: According to a communication sent to employees, those in General & Administrative areas will join IBM, including the lion's share of the people working in the HR, finance, accounting, and legal units at Red Hat. A source told us the switch will be "implemented this year," although in some countries "it might take longer due to legal constraints." The leadership running those teams will remain within the Red Hat fold. Some are nervous about the move, with tech companies -- notably IBM -- eliminating duplicated roles to consolidate back-office functions. In January -- as has happened in recent years -- IBM again forecast annual savings of $3.5 billion, partly through job cuts.

There is no public data on the size of the G&A population within Red Hat but the total workforce is understood to be about 19,000 worldwide, with the bulk of those employed in the engineering, sales, and support divisions. The team remaining at Red Hat will be part of the central Strategy & Operations group managed by Mike Ferris. As such, engineering, product, sales, and marketing personnel will be unaffected. For now at least. "Culture has been dead for at least 1 year now," said Reddit user Purple_Afternoon 966. "The experience might be different depending on the department, but there is nothing left from the open culture praised. We have now micromanagement, decision making from middle management that clearly have no idea of what we do and how and trying to implement ideas that they read somewhere, with no context, data and not giving answer or addressing feedback."

BrianFagioli shares a report from NERDS.xyz: Red Hat has introduced a new option that gives developers a fast lane to enterprise-grade Linux without needing to go through IT. The new release, called Red Hat Enterprise Linux for Business Developers, is now available for free. It offers direct, self-serve access to the same operating system used in production environments, specifically for business-focused development and testing.

The offering is part of the Red Hat Developer Program and is designed to reduce friction between development and operations teams. Developers can now build and test applications on the same platform that powers critical systems across physical servers, virtual machines, cloud deployments, and edge devices. [...] Each registered user can deploy up to 25 instances, whether virtual, physical, or cloud-based. The program includes signed and curated developer content such as programming languages, open source tools, and databases. Red Hat also includes Podman Desktop, its go-to container development tool, allowing users to work with containers that can closely match production environments.

While access is free, developers can choose to purchase support plans that tap into Red Hat's Linux expertise. This could appeal to developers working in business units or teams that want to build quickly without waiting on formal IT approval. This new option complements Red Hat's existing free Developer Subscription for Individuals and the Enterprise Developer Subscription for Teams, which is available through Red Hat reps or partners.

Rocky Linux 10 "Red Quartz" has reached general availability, notes a new article in The Register — surveying the differences between "RHELatives" — the major alternatives to Red Hat Enterprise Linux: The Rocky 10 release notes describe what's new, such as support for RISC-V computers. Balancing that, this version only supports the Raspberry Pi 4 and 5 series; it drops Rocky 9.x's support for the older Pi 3 and Pi Zero models...

RHEL 10 itself, and Rocky with it, now require x86-64-v3, meaning Intel "Haswell" generation kit from about 2013 onward. Uniquely among the RHELatives, AlmaLinux offers a separate build of version 10 for x86-64-v2 as well, meaning Intel "Nehalem" and later — chips from roughly 2008 onward. AlmaLinux has a history of still supporting hardware that's been dropped from RHEL and Rocky, which it's been doing since AlmaLinux 9.4. Now that includes CPUs. In comparison, the system requirements for Rocky Linux 10 are the same as for RHEL 10. The release notes say.... "The most significant change in Rocky Linux 10 is the removal of support for x86-64-v2 architectures. AMD and Intel 64-bit architectures for x86-64-v3 are now required."

A significant element of the advertising around RHEL 10 involves how it has an AI assistant. This is called Red Hat Enterprise Linux Lightspeed, and you can use it right from a shell prompt, as the documentation describes... It's much easier than searching man pages, especially if you don't know what to look for... [N]either AlmaLinux 10 nor Rocky Linux 10 includes the option of a helper bot. No big surprise there... [Rocky Linux] is sticking closest to upstream, thanks to a clever loophole to obtain source RPMs. Its hardware requirements also closely parallel RHEL 10, and CIQ is working on certifications, compliance, and special editions. Meanwhile, AlmaLinux is maintaining support for older hardware and CPUs, which will widen its appeal, and working with partners to ensure reboot-free updates and patching, rather than CIQ's keep-it-in-house approach. All are valid, and all three still look and work almost identically... except for the LLM bot assistant.

SiFive was one of the first companies to produce a RISC-V chip. This week they announced a new collaboration with Red Hat "to bring Red Hat Enterprise Linux support to the rapidly growing RISC-V community" and "prepare Red Hat's product portfolio for future intersection with RISC-V server hardware from a diverse set of RISC-V suppliers."

Red Hat Enterprise Linux 10 is available in developer preview on the SiFive HiFive Premier P550 platform, which they call "a proven, high performance RISC-V CPU development platform." The SiFive HiFive Premier P550 provides a proven, high performance RISC-V CPU development platform. Adding support for Red Hat Enterprise Linux 10, the latest version of the world's leading enterprise Linux platform, enables developers to create, optimize, and release new applications for the next generation of enterprise servers and cloud infrastructure on the RISC-V architecture...

SiFive's high performance RISC-V technology is already being used by large organizations to meet compute-intensive AI and machine learning workloads in the datacenter... "With the growing demand for RISC-V, we are pleased to collaborate with SiFive to support Red Hat Enterprise Linux 10 deployments on SiFive HiFive Premier P550," said Ronald Pacheco, senior director of RHEL product and ecosystem strategy, "to further empower developers with the power of the world's leading enterprise Linux platform wherever and however they choose to deploy...."

Dave Altavilla, principal analyst at HotTech Vision And Analysis, said "Native Red Hat Enterprise Linux support on SiFive's HiFive Premier P550 board offers developers a substantial enterprise-grade toolchain for RISC-V.

"This is a pivotal step forward in enabling a full-stack ecosystem around open RISC-V hardware. SiFive says the move will "inspire the next generation of enterprise workloads and AI applications optimized for RISC-V," while helping their partners "deliver systems with a meaningfully lower total cost of ownership than incumbent platforms."

"With the growing demand for RISC-V, we are pleased to collaborate with SiFive to support Red Hat Enterprise Linux 10 deployments on SiFive HiFive Premier P550..." said Ronald Pacheco, senior director of RHEL product and ecosystem strategy. .

Beta News notes that there's also a new AI-powered assistant in RHEL 10, so "Instead of spending all day searching for answers or poking through documentation, admins can simply ask questions directly from the command line and get real-time help Security is front and center in this release, too. Red Hat is taking a proactive stance with early support for post-quantum cryptography. OpenSSL, GnuTLS, NSS, and OpenSSH now offer quantum-resistant options, setting the stage for better protection as threats evolve. There's a new sudo system role to help with privilege management, and OpenSSH has been bumped to version 9.9. Plus, with new Sequoia tools for OpenPGP, the door is open for even more robust encryption strategies. But it's not just about security and AI. Containers are now at the heart of RHEL 10 thanks to the new "image mode." With this feature, building and maintaining both the OS and your applications gets a lot more streamlined...

Slashdot reader Mirnotoriety shared this report from the Register: A proof-of-concept program has been released to demonstrate a so-called monitoring "blind spot" in how some Linux antivirus and other endpoint protection tools use the kernel's io_uring interface.

That interface allows applications to make IO requests without using traditional system calls [to enhance performance by enabling asynchronous I/O operations between user space and the Linux kernel through shared ring buffers]. That's a problem for security tools that rely on syscall monitoring to detect threats... [which] may miss changes that are instead going through the io_uring queues.

To demonstrate this, security shop ARMO built a proof-of-concept named Curing that lives entirely through io_uring. Because it avoids system calls, the program apparently went undetected by tools including Falco, Tetragon, and Microsoft Defender in their default configurations. ARMO claimed this is a "major blind spot" in the Linux security stack... "Not many companies are using it but you don't need to be using it for an attacker to use it as enabled by default in most Linux systems, potentially tens of thousands of servers," ARMO's CEO Shauli Rozen told The Register. "If you're not using io_uring then disable it, but that's not always easy with cloud vendors."

Axiom Space and Red Hat will collaborate to launch Data Center Unit-1 (AxDCU-1) to the International Space Station this spring. It's a small data processing prototype (powered by lightweight, edge-optimized Red Hat Device Edge) that will demonstrate initial Orbital Data Center (ODC) capabilities.

"It all sounds rather grand for something that resembles a glorified shoebox," reports the Register. Axiom Space said: "The prototype will test applications in cloud computing, artificial intelligence, and machine learning (AI/ML), data fusion and space cybersecurity."

Space is an ideal environment for edge devices. Connectivity to datacenters on Earth is severely constrained, so the more processing that can be done before data is transmitted to a terrestrial receiving station, the better. Tony James, chief architect, Science and Space at Red Hat, said: "Off-planet data processing is the next frontier, and edge computing is a crucial component. With Red Hat Device Edge and in collaboration with Axiom Space, Earth-based mission partners will have the capabilities necessary to make real-time decisions in space with greater reliability and consistency...."

The Red Hat Device Edge software used by Axiom's device combines Red Hat Enterprise Linux, the Red Hat Ansible Platform, and MicroShift, a lightweight Kubernetes container orchestration service derived from Red Hat OpenShift. The plan is for Axiom Space to host hybrid cloud applications and cloud-native workloads on-orbit. Jason Aspiotis, global director of in-space data and security, Axiom Space, told The Register that the hardware itself is a commercial off-the-shelf unit designed for operation in harsh environments... "AxDCU-1 will have the ability to be controlled and utilized either via ground-to-space or space-to-space communications links. Our current plans are to maintain this device on the ISS. We plan to utilize this asset for at least two years."
The article notes that HPE has also "sent up a succession of Spaceborne computers — commercial, off-the-shelf supercomputers — over the years to test storage, recovery, and operational potential on long-duration missions." (They apparently use Red Hat Enterprise Linux.) "At the other end of the scale, the European Space Agency has run Raspberry Pi computers on the ISS for years as part of the AstroPi educational outreach program."

Axiom Space says their Orbital Data Center is deigned to "reduce delays traditionally associated with orbital data processing and analysis." By utilizing Earth-independent cloud storage and edge processing infrastructure, Axiom Space ODCs will enable data to be processed closer to its source, spacecraft or satellites, bypassing the need for terrestrial-based data centers. This architecture alleviates reliance on costly, slow, intermittent or contested network connections, creating more secure and quicker decision-making in space.

The goal is to allow Axiom Space and its partners to have access to real-time processing capabilities, laying the foundation for increased reliability and improved space cybersecurity with extensive applications. Use cases for ODCs include but are not limited to supporting Earth observation satellites with in-space and lower latency data storage and processing, AI/ML training on-orbit, multi-factor authentication and cyber intrusion detection and response, supervised autonomy, in-situ space weather analytics and off-planet backup & disaster recovery for critical infrastructure on Earth.

When it comes to application packaging, earlier this month the site Its FOSS complained that Fedora Flatpaks "are often unmaintained or broken, leading to a poor experience for users who aren't usually aware they're using them." And this apparently created friction with OBS Studio, the free/open-source screencasting and streaming app.

"We are now considering the Fedora Flatpaks distribution of OBS Studio a hostile fork," OBS Studio lead Joel Bethke posted in on GitLab's page for Fedora Flatpaks. They said they were making "a formal request to remove all of our branding, including but not limited to, our name, our logo, any additional IP belonging to the OBS Project, from your distribution. Failure to comply may result in further legal action taken...." (Issues with Fedora's packaging led "to users complaining upstream thinking they are being served the official package..." Bethke said in his original Issue. "I would also like some sort of explanation on why someone thought it was a good idea to take a Flatpak that was working perfectly fine, break it, and publish it at a higher priority to our official builds.")

23 people clicked "Like" on the original Issue — but threatening legal action only happened after Bethke felt Fedora was unresponsive, according to It's FOSS: In a comment on a video by Brodi Robertson (check pinned comment), Joel shared that folks from Fedora were not taking this issue seriously, with one of them even resorting to name-calling by labeling the OBS Studio devs as being "terrible maintainers". Since then, a major step has been taken by Neal Gompa, a well-known Fedora contributor and member of the Fedora Engineering Steering Committee (FESCo). He has opened a new issue to remove Fedora's OBS Studio flatpak from the registry as soon as possible.
But by Tuesday Bethke posted in a new comment on GitLab announcing that "a very good conversation" with the Flatpak SIG and Fedora Project Leader seemed to have cleared the tension. "We discussed the issues, how we got here, and what next steps are... [T]he OBS Project is no longer requesting a removal of IP or rebrand of the OBS Studio application provided by Fedora Flatpaks." To the issue of not knowing where to report bugs for the downstream package, "We had some very good discussion on how this might be accomplished in the medium-long term, but don't consider it a blocker at this point." As for other issues with Fedora's Flatpak for OBS Studio, "The discussion was positive and they are actively working to resolve..."

And similar sentiments were echoed on Fedora's own issue tracker. "We had a good conversation today, and there is a hopeful path forward that does not require the OBS Project distancing itself from Fedora Flatpaks..."

PAjamian writes: Two years ago Red Hat announced an end to its public source code availability. This caused a great deal of outcry from the Enterprise Linux community at large. Since then many have waited for a statement from the Free Software Foundation concerning their stance on the matter. Now, nearly two years later the FSF has finally responded to questions regarding their stance on the issue with the following statement:

When asked if the FSF would be willing to intervene on behalf of the community they had this to say:

Following is the full text of my original email to them and their response:

Subject: Statement about recent changes in source code distribution for Red Hat Enterprise Linux
Date: 2023-07-16 00:39:51

> Hi,
>
> I'm a user of Red Hat Enterprise Linux, Rocky Linux and other Linux
> distributions in the RHEL ecosystem. I am also involved in the EL
> (Enterprise Linux) community which is being affected by the statements
> and changes in policy made by Red Hat at
> https://www.redhat.com/en/blog/furthering-evolution-centos-stream and
> https://www.redhat.com/en/blog/red-hats-commitment-open-source-
> response-gitcentosorg-changes
> (note there are many many more links and posts about this issue which
> I
> believe you are likely already aware of). While a few of these
> questions are answered more directly by the license FAQ some of them
> are
> not and there are a not insignificant number of people who would very
> much appreciate a public statement from the FSF that answers these
> questions directly.
>
> Can you please comment or release a statement about the Free Software
> Foundation's position on this issue? Specifically:
>

Thank you for writing in with your questions. My apologies for the delay, but we are a small team with limited resources and can be challenging keeping up with all the emails we receive.

Generally, we don't agree with what Red Hat is doing. Whether it constitutes a violation of the GPL would require legal analysis and the FSF does not give legal advice. However, as the stewards of the GNU GPL we can speak how it is intended to be applied and Red Hat's approach is certainly contrary to the spirit of the GPL. This is unfortunate, because we would expect such flagship organizations to drive the movement forward.

> Is Red Hat's removal of sources from git.centos.org a violation of the
> GPL and various other Free Software licenses for the various programs
> distributed under RHEL?
>
> Is Red Hat's distribution of source RPMs to their customers under
> their
> subscriber agreement sufficient to satisfy the above mentioned
> licenses?
>
> Is it a violation if Red Hat terminates a subscription early because
> their customer exercised their rights under the GPL and other Free
> Software licenses to redistribute the RHEL sources or create
> derivative
> works from them?
>
> Is it a violation if Red Hat refuses to renew a subscription that has
> expired because a customer exercised their rights to redistribute or
> create derivative works?
>
> A number of the programs distributed with RHEL are copyrighted by the
> FSF, some examples being bash, emacs, GNU core utilities, gcc, gnupg
> and
> glibc. Given that the FSF has standing to act in this matter would
> the
> FSF be willing to intervene on behalf of the community in order to get
> Red Hat to correct any of the above issues?
>

As of today, we are not aware of any issue with Red Hat's new policy that we could pursue on legal grounds. However, if you do find a violation, please [follow these instructions][0] and send a report to <license-violation@gnu.org>.

[0]: https://www.gnu.org/licenses/gpl-violation.html

If you are interested in something more specific on this, the Software Freedom Conservancy [published an article about the RHEL][1] situation and hosted a [panel at their conference in 2023][2]. These cover the situation fairly thoroughly.

[1]: https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/
[2]: https://sfconservancy.org/blog/2023/jul/19/rhel-panel-fossy-2023/

In his post about the future of Fedora Workstation, Christian F.K. Schaller discusses how the Red Hat team plans to integrate AI with IBM's open-source Granite engine to enhance developer tools, such as IDEs, and create an AI-powered Code Assistant. He says the team is also working on streamlining AI acceleration in Toolbx and ensuring Fedora users have access to tools like RamaLama. From the post: One big item on our list for the year is looking at ways Fedora Workstation can make use of artificial intelligence. Thanks to IBMs Granite effort we know have an AI engine that is available under proper open source licensing terms and which can be extended for many different usecases. Also the IBM Granite team has an aggressive plan for releasing updated versions of Granite, incorporating new features of special interest to developers, like making Granite a great engine to power IDEs and similar tools. We been brainstorming various ideas in the team for how we can make use of AI to provide improved or new features to users of GNOME and Fedora Workstation. This includes making sure Fedora Workstation users have access to great tools like RamaLama, that we make sure setting up accelerated AI inside Toolbx is simple, that we offer a good Code Assistant based on Granite and that we come up with other cool integration points. "I'm still not sure how I feel about this approach," writes designer/developer and blogger, Bradley Taunt. "While IBM Granite is an open source model, I still don't enjoy so much artificial 'intelligence' creeping into core OS development. This also isn't something optional on the end-users side, like a desktop feature or package. This sounds like it's going to be built directly into the core system."

"Red Hat has been pushing hard towards AI and my main concern is having this influence other operating system dev teams. Luckily things seems AI-free in BSD land. For now, at least."

"You can use any Linux distribution inside of the Windows Subsystem for Linux" Microsoft recently reminded Windows users, "even if it is not available in the Microsoft Store, by importing it with a tar file."

But being an official distro "makes it easier for Windows Subsystem for Linux users to install and discover it with actions like wsl --list --online and wsl --install," Microsoft pointed out this week. And "We're excited to announce that Red Hat will soon be delivering a Red Hat Enterprise Linux WSL distro image in the coming months..."

Thank you to the Red Hat team as their feedback has been invaluable as we built out this new architecture, and we're looking forwards to the release...! Ron Pacheco, senior director, Red Hat Enterprise Linux Ecosystem, Red Hat says:

"Developers have their preferred platforms for developing applications for multiple operating systems, and WSL is an important platform for many of them. Red Hat is committed to driving greater choice and flexibility for developers, which is why we're working closely with the Microsoft team to bring Red Hat Enterprise Linux, the largest commercially available open source Linux distribution, to all WSL users."
Read Pacheco's own blog post here.

But in addition Microsoft is also releasing "a new way to make WSL distros," they announced this week, "with a new architecture that backs how WSL distros are packaged and installed." Up until now, you could make a WSL distro by either creating an appx package and distributing it via the Microsoft Store, or by importing a .tar file with wsl -import. We wanted to improve this by making it possible to create a WSL distro without needing to write Windows code, and for users to more easily install their distros from a file or network share which is common in enterprise scenarios... With the tar based architecture, you can start with the same .tar file (which can be an exported Linux container!) and just edit it to add details to make it a WSL distro... These options will describe key distro attributes, like the name of the distro, its icon in Windows, and its out of box experience (OOBE) which is what happens when you run WSL for the first time. You'll notice that the oobe_command option points to a file which is a Linux executable, meaning you can set up your full experience just in Linux if you wish.

Red Hat, the IBM-owned open source software firm, is acquiring Neural Magic, a startup that optimizes AI models to run faster on commodity processors and GPUs. From a report: The terms of the deal weren't disclosed. MIT research scientist Alex Matveev and professor Nir Shavit founded Somerville, Massachusetts-based Neural Magic in 2018, inspired by their work in high-performance execution engines for AI. Neural Magic's software aims to process AI workloads on processors and GPUs at speeds equivalent to specialized AI chips (e.g. TPUs). By running models on off-the-shelf processors, which usually have more available memory, the company's software can realize these performance gains.

Big tech companies like AMD and a host of other startups, including NeuReality, Deci, CoCoPie, OctoML and DeepCube, offer some sort of AI optimization software. But Neural Magic is one of the few with a free platform and a collection of open source tools to complement it. Neural Magic had so far managed to raise $50 million in venture capital from backers like Andreessen Horowitz, New Enterprise Associations, Amdocs, Comcast Ventures, Pillar VC and Ridgeline Ventures.

"Looks like there's a storm brewing, and it's not good news," writes ancient Slashdot reader jd. "Whether or not the bugs are classically security defects or not, this is extremely bad PR for the Linux and Open Source community. It's not clear from the article whether this affects other Open Source projects, such as FreeBSD." From a report: A critical unauthenticated Remote Code Execution (RCE) vulnerability has been discovered, impacting all GNU/Linux systems. As per agreements with developers, the flaw, which has existed for over a decade, will be fully disclosed in less than two weeks. Despite the severity of the issue, no Common Vulnerabilities and Exposures (CVE) identifiers have been assigned yet, although experts suggest there should be at least three to six. Leading Linux distributors such as Canonical and RedHat have confirmed the flaw's severity, rating it 9.9 out of 10. This indicates the potential for catastrophic damage if exploited. However, despite this acknowledgment, no working fix is still available. Developers remain embroiled in debates over whether some aspects of the vulnerability impact security.

The Register's Liam Proven reports: Microsoft's in-house professional networking site is moving to Microsoft's in-house Linux. This could mean that big changes are coming for the former CBL-Mariner distro. Ievgen Priadka's post on the LinkedIn Engineering blog, titled Navigating the transition: adopting Azure Linux as LinkedIn's operating system, is the visible sign of what we suspect has been a massive internal engineering effort. It describes some of the changes needed to migrate what the post calls "most of our fleet" from the end-of-life CentOS 7 to Microsoft Azure Linux -- the distro that grew out of and replaced its previous internal distro, CBL-Mariner.

This is an important stage in a long process. Microsoft acquired LinkedIn way back in 2016. Even so, as recently as the end of last year, we reported that a move to Azure had been abandoned, which came a few months after it laid off almost 700 LinkedIn staff -- the majority in R&D. The blog post is over 3,500 words long, so there's quite a lot to chew on -- and we're certain that this has been passed through and approved by numerous marketing and management people and scoured of any potentially embarrassing admissions. Some interesting nuggets remain, though. We enjoyed the modest comment that: "However, with the shift to CentOS Stream, users felt uncertain about the project's direction and the timeline for updates. This uncertainty created some concerns about the reliability and support of CentOS as an operating system." [...]

There are some interesting technical details in the post too. It seems LinkedIn is running on XFS -- also the RHEL default file system, of course -- with the notable exception of Hadoop, and so the Azure Linux team had to add XFS support. Some CentOS and actual RHEL is still used in there somewhere. That fits perfectly with using any of the RHELatives. However, the post also mentions that the team developed a tool to aid with deploying via MaaS, which it explicitly defines as Metal as a Service. MaaS is a Canonical service, although it does support other distros -- so as well as CentOS, there may have been some Ubuntu in the LinkedIn stack as well. Some details hint at what we suspect were probably major deployment headaches. [...] Some of the other information covers things the teams did not do, which is equally informative. [...]