These Linux distros claim to be open source, but they're barely even close

These Linux distros claim to be open source, but they're barely even close

Published Oct 24, 2026, 8:00 AM EDT Umair Khurshid is a technology writer and developer with a strong focus on Linux, FreeBSD, cloud infrastructure, and automation. Before focusing on writing, Umair worked as a developer and DevOps engineer building and automating cloud-native systems. Linux has a reputation for giving people control over their computers, but plenty of commercial products use Linux without giving their owners much control at all. They ship with proprietary software, restrict access to source code, or lock down the hardware so thoroughly that installing a modified operating system becomes impractical. There are different ways to judge whether an operating system deserves the open source label. The Free Software Foundation (FSF) sets a strict standard through its four software freedoms and its GNU Free System Distribution Guidelines. Distros such as Trisquel, Guix System, and Parabola aim to meet those requirements by excluding proprietary software. Ubuntu, Debian, and Fedora take a more permissive approach, supporting or providing access to proprietary firmware and software alongside their open source components. The Open Source Initiative (OSI) uses its Open Source Definition, which focuses on licensing requirements such as free redistribution, access to source code, and permission to modify and distribute derived works. Under that standard, Ubuntu, Debian, and Fedora have extensive open source foundations. Debian’s Social Contract and Free Software Guidelines also establish clear principles for the software it includes in its main archive, but open source licenses tell only part of the story when it comes to commercial operating systems. Can you obtain the source code, build the operating system yourself, and install your own version on the hardware it was designed for? Red Hat makes it harder to rebuild what it sells RHEL’s source-code policy changed the game Red Hat Enterprise Linux (RHEL) contains software distributed under the GPL and other open source licenses, and the company has also contributed extensively to open source projects over the years. Yet its decision to restrict public access to RHEL source packages in 2023 caused a major backlash across the Linux community. In June 2023, Red Hat announced that CentOS Stream would become the sole public repository for RHEL-related source code. Previously, people could obtain RHEL source packages through publicly accessible CentOS infrastructure. After the change, customers generally needed to access the relevant sources through Red Hat’s customer channels. Red Hat’s subscription terms restrict redistribution of subscription content, complicating efforts to publish a compatible distro using the company’s source packages. Red Hat argues that its subscription model is legitimate and that CentOS Stream provides a better place for collaborative development, but one can argue (which a lot of critics do) that Red Hat benefited from an ecosystem built around accessible source code, then made it much harder for independent projects to reproduce its commercial product. Rocky Linux and AlmaLinux were among the projects forced to rethink their approaches and both adapted their build processes to continue providing enterprise Linux compatibility. Red Hat did not simply turn RHEL into proprietary software. The licenses covering its open source components still apply, but Red Hat’s policies have made it harder for outsiders to obtain the same source packages and redistribute a compatible system without navigating its commercial terms. Open source software depends on people being able to take the code, build on it, and share their work under the applicable licenses. Making that process harder for a product whose success rests on open source software undermines the collaborative ecosystem around it. The company can defend its subscription model, but the Linux community has good reason to question whether this approach serves the ecosystem that helped make RHEL successful. Tizen is open source, but your Samsung TV isn’t The project and the product tell different stories Tizen is a genuine open source operating system project hosted under the Linux Foundation. It has public repositories, developer tools, documentation, and support for several device categories, including televisions. Samsung also provides resources for developers who want to build applications for its TVs. Buy a Samsung TV running Tizen, however, and you do not get the same freedom that the open source project suggests. The commercial product includes Samsung-specific software, proprietary services, hardware adaptations, and firmware that is not necessarily available as a complete, reproducible build. Samsung has faced criticism over its television software for years. Developers can use the supported tools and APIs to create applications, but that is a far cry from being able to rebuild the complete operating system and install it on a television. Owners cannot assume that the public Tizen source repositories contain everything needed to replace the firmware on their particular model. The frustrating part is that the open source work is real. Tizen is not just a Linux kernel with a different name slapped on it; there is a substantial project behind it, but buying a Tizen television does not give you the freedom to take that project, rebuild the entire software stack, and replace Samsung’s version. If a company wants credit for building on open source, I think it should be more forthcoming about what remains closed and what customers can actually change. Samsung’s developer resources are useful, but they do not make its televisions open source devices. Fire OS borrows Android’s openness without offering the same freedom Amazon controls the experience on top of AOSP Amazon’s Fire OS powers Fire TV devices and Fire tablets. It is derived from the Android Open Source Project (AOSP) and runs on the Linux kernel. Amazon publishes source code for components covered by applicable open source licenses, including the kernel and other software subject to source distro requirements. Much of AOSP uses the Apache License 2.0, which generally allows companies to modify and redistribute the code without releasing their proprietary changes. Amazon has used that flexibility to build its own ecosystem. The Fire OS launcher and interface, Amazon Appstore, Alexa integration, and various system services are proprietary. Many Fire devices also have locked bootloaders, making it difficult or impossible for ordinary owners to replace the installed operating system with their own builds. Under AOSP’s permissive licenses, Amazon generally has no obligation to publish those modifications; while that does not make the arrangement a licensing violation, it does mean the company can benefit from an open platform while keeping much of its own product closed. The bootloader restrictions make things worse for anyone who wants to experiment. Publishing kernel source does not mean you can install a replacement operating system on a Fire TV Stick. Device-specific restrictions, proprietary services, and hardware support can stand in the way even when some of the underlying code is available. Amazon doesn’t call Fire OS open source outright. Describing Fire OS as built on open source software does the job, letting the credibility of AOSP handle the marketing while Amazon maintains complete control over the finished product. It’s a carefully convenient use of language, the wording may be technically accurate, but it encourages customers to associate Fire OS with the freedoms of open source without actually offering them those freedoms. The GNU Project even has a page called Words to Avoid (or Use with Care). Perhaps more companies selling products built on open source software should give it a read. They might discover that the wording around openness can be just as carefully managed as the code itself. Credit: GNU Three questions that expose an open source claim Companies know that calling something open source sounds good. It suggests transparency, user control, and software people can inspect and improve. But before buying into their pitch, you may want to know what the company is actually offering. Who gets access to the source code? If the answer is limited to paying customers or people willing to accept restrictive terms, the company is already putting barriers between its software and the wider community. What can you actually do with that code? An open source kernel buried beneath proprietary services, a closed interface, and vendor-controlled components doesn’t make the entire operating system open source. It makes the product dependent on open source and can you run your own build on the hardware you paid for. If the bootloader is locked, the firmware is unavailable, or the vendor provides no practical way to replace its software, publishing source code only gets you so far. There’s nothing inherently wrong with commercial software that uses open source components, and proprietary code isn’t automatically a licensing violation, but the problem is using the reputation of open source to sell a product while keeping the freedoms associated with it out of the customer’s hands.

Original Source

Read the full article at Howtogeek →

KhanList aggregates and links to publicly available news content. We do not host full articles from third-party sources. Always verify important information with original sources.