CoreELEC is a LibreELEC fork whose whole product is one media centre on low cost hardware

What the fork relationship means for the build and the community

The README states it in one line: CoreELEC is a minor fork of LibreELEC, built by the community for the community. That relationship is the whole product definition. The purpose is stated just as plainly, a Just enough OS Linux distribution for running Kodi on popular low cost hardware.

CoreELEC identifies itself as a minor fork of LibreELEC, built by the community for the community.

The documentation pointers in the README are unusually direct for a distribution repository. CONTRIBUTING.md covers how to report issues and submit pull requests. STANDARDS.md holds coding standards for build scripts and package files. packages/README.md is described as a detailed guide to package.mk structure and variables. That third file is the one to read first if you want to add software, because package.mk is the unit of construction in a distribution built around a Makefile.

Support runs through the CoreELEC forum on Discourse rather than GitHub issues, which is a deliberate routing choice for an appliance distribution with an end user base.

The Makefile exposes six build targets and nothing else

The root Makefile is short, and that is informative. Its targets are:

all: release

system:
	./scripts/image

release:
	./scripts/image release

image:
	./scripts/image mkimage

noobs:
	./scripts/image noobs

clean:
	./scripts/makefile_helper --clean

distclean:
	./scripts/makefile_helper --distclean

src-pkg:
	tar cvJf sources.tar.xz sources

Three of them produce artefacts. make system runs the image script with no mode argument, make release passes release, and make image passes mkimage. make noobs passes noobs to the image script. The default target is all, which depends on release.

Every target is a thin wrapper over scripts/image with a mode string. The real logic is in that script, not in the Makefile, so reading the Makefile tells you the build modes exist but nothing about how long they take or what they need installed.

src-pkg is the exception and it is not a wrapper at all: it archives the sources directory into sources.tar.xz with tar. That is the artefact for reproducing or auditing a build rather than running one.

The clean and distclean targets pass --clean and --distclean to scripts/makefile_helper, which separates removing build output from removing downloaded sources. That distinction is the reason there are two.

The directory layout is a build system, not an application

Top level entries tell you where the work happens. packages/ holds the package definitions and its README. projects/ is where project sources are declared. config/ holds the build configuration. distributions/ holds the target definitions, which is where you would add or retire a hardware target. scripts/ contains the image script and the makefile_helper the Makefile calls. tools/ holds host side tooling. licenses/ holds licence material, and create_tar.sh at the root handles archive creation.

There is also a CHANGELOG at the root rather than under docs, and no docs directory at all, which is consistent with the documentation living in the three markdown files the README links plus the forum.

The primary language of the repository is recorded as Makefile, which tells you what kind of codebase this is before you read a line. You are not going to find an application here to patch. You are going to find a description of how to assemble one.

That has a practical consequence for evaluating a bug fix: the unit of change is a package definition or a target definition, and the correctness bar is that the image still builds and still boots on the affected hardware.

Copyright follows upstream, which is the rule contributors get wrong

The README has the longest paragraph in it about copyright, and it is worth reading carefully because the rule is not the one most contributors assume.

The position: because CoreELEC includes code from many upstream projects, it includes many copyright owners, and CoreELEC makes no claim of copyright on any upstream code. Patches to upstream code carry the same licence as the upstream project unless stated otherwise. A complete copyright list requires checking out the source and reading the licence headers.

The default for new contributions is GPLv2, stated as covering all code submitted to the project in any form unless expressly stated otherwise. Retention of your own copyright is explicitly permitted: add a copyright header to each submitted code page. If you submit code that is not your own work, placing a header stating the copyright is your responsibility.

So there are two regimes in one tree. Original CoreELEC code is GPLv2, and a patch to something inherited from an upstream project follows that upstream's licence. The repository's own licence field is recorded as unknown in the metadata, so the README paragraph and the headers in the files are the authority, not a badge.

This is the GPLv2, and it carries the copyleft obligation that matters if you build a modified image and distribute it.

Release line 22, and the branch layout follows it

The default branch is coreelec-22, which is named for the release line rather than for a permanent trunk. There is no main or master named in the repository metadata, so a clone lands on the 22 line by default.

The releases in the record are all from that line. 22.0-Piers_rc1 on 2026-10-03 is a release candidate, preceded by 22.0-Piers_beta2 on 2026-09-07 and 22.0-Piers_beta1 on 2026-06-23. Betas spaced months apart with a release candidate after them is the shape of a distribution that ships when the image is ready rather than on a calendar.

A named codename per release, Piers here, is worth noting because it is how images and discussions get referred to. Distinguishing a beta from a release candidate matters for anyone flashing hardware: the candidate is where you find the last of the regressions, and the beta is where you find most of them.

The last push was on 2026-10-14, two days after the release candidate and well after the beta, and the repository is not archived. Whatever maintenance looked like through the 22 line, it did not stop.

No donations, and what that says about who maintains it

The README says plainly that donations are not accepted at the moment, with the reason given as doing this for fun not for profit. The project homepage is coreelec.org and support runs through the Discourse forum.

Read together with the copyright paragraph, that sets expectations about the relationship. There is no commercial support contract implied, no guaranteed response time, and no vendor entity behind the images. If you are deploying CoreELEC across a fleet, the operational risk is that your image is your responsibility, including the parts upstream that your changes sit on.

The same applies to contributions. The README points to CONTRIBUTING.md for the process and STANDARDS.md for the conventions, and gates enhancements and pull requests on following them. A patch that builds correctly but violates the standards for build scripts or package files will still need reworking.

Documentation is intentionally lean. Beyond the three files and the forum, the CHANGELOG at the root is the record of what changed, so reading it before and after an upgrade is the fastest way to know what you are taking on.

Editorial conclusion

Use CoreELEC when your goal is a dedicated appliance that boots into Kodi on constrained hardware and you want a distro trimmed to that one job, and expect to write your own packages if you need anything outside the bundled set. Do not expect a general purpose Linux, a desktop environment or a package manager model comparable to a full distribution, because the documented build surface is image targets and a package.mk structure. Before contributing, read STANDARDS.md and packages/README.md, since the project gates patches on conventions for build scripts and package files, and note that the default branch is named for the release line, coreelec-22, rather than a rolling main.

Frequently asked questions

Official sources

1. CoreELEC/CoreELEC on GitHub
2. Issues
3. Project website
4. README
5. Releases