Wiki - https://fedoraproject.org/wiki/Changes/X11Libre Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-x11libre-system-w...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary ==
Replace the X.Org X11 Xserver (<code>xorg-x11-xserver</code>) with the [https://github.com/X11Libre/xserver X11Libre (XLibre) Xserver], an actively maintained fork.
== Disclaimer ==
'''The Change Owner does NOT share or endorse upstream's political views!''' Given that those can be found even in the upstream project-wide <code>README.md</code>, the Change Owner feels obliged to make this clarification.
== Owner == * Name: [[User:Kkofler| Kevin Kofler]] * Email: Kevin@tigcc.ticalc.org
== Detailed Description ==
A long time has passed since the last major release of the X.Org X11 Xserver. Even bugfix releases have become rare. Therefore, this Change proposes replacing the nearly unmaintained upstream with a maintained fork, the X11Libre XServer.
The upstream maintainer of X11Libre had been the most active remaining contributor to the X.Org X11 Xserver before the fork. The Change Owner is well aware of the controversies around the X11Libre upstream maintainer (FreeDesktop.org CoC violations, controversial political views, conspiracy theories, rants against Red Hat), but believes that the benefit of shipping maintained software outweighs the potential annoyances when having to deal with upstream.
There is no intent to ever replace the Xwayland implementation, only the standalone Xserver and its subpackages (Xnest, Xvfb, Xephyr), and possibly the driver packages (<code>xorg-x11-drv-*</code>).
== Feedback ==
The formal discussion on this Change has '''not''' started yet, pending official announcement of the Change.
=== Some earlier X11-related discussion (not directly related to this Change) ===
Ticket: * [https://pagure.io/Fedora-Council/tickets/issue/481 #481 KDE X11 Packages in Violation of System-Wide Change]
Thread: * [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... fedora-devel list archive: GDM dropped support for running X11 sessions in F42 without a Change?]
=== Discussion of this Change started before the formal announcement ===
Thread: * [https://discussion.fedoraproject.org/t/veto-x11libre-inclusion-for-fedora/15... discussion.fedoraproject.org - Veto X11Libre inclusion for fedora]
== Benefit to Fedora == * Fedora will benefit from shipping an actively maintained Xserver instead of a moribund one whose maintainers themselves label as "unmaintained" (pushing Wayland as the replacement). * All the Spins (and Editions, if any) still shipping X11 will benefit from the improvements. The ones that have switched to Wayland (only) will not be affected at all. * One interesting new feature is the [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1865 Xnamespace extension], which aims at bridging the gap in isolation capabilities between X11 and Wayland. '''If and where''' that extension is used, it will no longer be possible to abuse the Xserver for privilege escalation across a security boundary enforced by the extension (e.g., host/container, root/user). (Note that this extension is purely opt-in and will by default do nothing.) * The Xnest nested X server has been ported from the legacy Xlib to the xcb library. * The fact that the Xserver is now maintained again means it will be able to live in Fedora for much longer, and the need to push all users to Wayland at all costs disappears completely.
== Scope == * Proposal owners: Package <code>x11libre-xserver</code> (based on the existing <code>xorg-x11-xserver</code> package), add proper Obsoletes/Provides, get it through the package review process, and try to find comaintainers. (The packaging changes as such are pretty much self-contained. The Change is system-wide due to touching an important package with many users and reverse dependencies.)
* Other developers: Drivers depending on the X11 driver ABI will need to be rebuilt (see the next section ''Upgrade/compatibility impact''). For those that are part of X.Org, instead of just rebuilding the old unmaintained code, it may make sense to move those packages to the forks in the X11Libre project as well. Otherwise, no changes by other developers should be needed.
* Release engineering: [https://pagure.io/releng/issue/12774 Rel-eng says no impact.]
* Policies and guidelines: No updates needed.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: Replacing near-unmaintained software with a maintained version matches the point "Focus Area: Technology Innovation & Leadership" of the Fedora Strategy and "First" in the referenced Four Foundations.
== Upgrade/compatibility impact == The fork is a drop-in replacement for the X.Org X11 Xserver. As such, no compatibility issues should be visible to end users, and RPM-level Obsoletes/Provides will transparently take care of the package rename. No manual configuration or data migration should be needed. No dropped functionality has been announced at this time.
However, as with every new major X.Org X11 Xserver release in the past, the driver ABI has changed. Therefore, any X drivers will have to be rebuilt with the new ABI. The process is the same as for regular major updates of the Xserver, though indeed it has been a long time since the last such major release, so this might come as a surprise to some.
== Early Testing (Optional) == Do you require 'QA Blueprint' support? N
It is planned to bring up a Copr repository as soon as possible to allow for early user testing. The Change Owner does not believe automated testing to be of much use for this Change.
== How To Test == Hardware requirements: Testing is useful on all hardware (except completely headless or text-only systems). No special hardware is needed. However, the more different graphics hardware gets tested, the better.
Software requirements: To test this change, the system only needs to run X11. So install any desktop environment or standalone window manager that uses X11. (If you want to test KDE Plasma, install the <code>plasma-workspace-x11</code> package and make sure you test the "Plasma (X11)" session, not the Wayland one.) Then upgrade your Xserver to the X11Libre one (<code>x11libre-xserver</code>).
Testing: Once you have the requirements, you should try to use your desktop environment (or standalone window manager) as normal, and report any crashes or graphical glitches that come up. The expected result is that everything works without any crashes or glitches. A non-exhaustive list of items that are useful to test specifically is given by the following release criteria: * [https://fedoraproject.org/wiki/Basic_Release_Criteria#Window_manager_functio... Basic: Window manager functionality] * [https://fedoraproject.org/wiki/Fedora_43_Beta_Release_Criteria#Desktop_panel Beta: Desktop panel] * [https://fedoraproject.org/wiki/Fedora_43_Final_Release_Criteria#Default_appl... Final: Default application functionality] * [https://fedoraproject.org/wiki/Fedora_43_Final_Release_Criteria#Default_pane... Final: Default panel functionality] * [https://fedoraproject.org/wiki/Fedora_43_Final_Release_Criteria#Dual_monitor... Final: Dual monitor setup] * [https://fedoraproject.org/wiki/Fedora_43_Final_Release_Criteria#Window_manag... Final: Window manager functionality]
== User Experience == Users will not immediately notice any difference at all. In the long run, they may benefit from fixed bugs, from the Xnamespace extension if and when other software starts using it, and from future features.
== Dependencies == '''RPM reverse dependencies (other packages depending on this package):''' Several packages depend on the Xserver. Thanks to Obsoletes/Provides, most of them will not be affected by this change at all. However, packages depending on the driver ABI will need a rebuild (see ''Upgrade/compatibility impact'').
'''Dependencies on other Changes:''' No.
'''Dependencies on other upstream projects:''' No.
== Contingency Plan == * Contingency mechanism: Revert to <code>xorg-x11-server</code>. With suitably versioned Obsoletes/Provides, that should require only a sufficient bump of Release in <code>xorg-x11-server</code> and adding Obsoletes/Provides to <code>xorg-x11-server</code> to replace <code>x11libre-server</code>. The Change Owner will do it. * Contingency deadline: Beta Freeze. (Late enactment of the contingency plan is technically possible, but means a lot of testing may be invalidated.) * Blocks release? Maybe. If the Change is not implemented at all (or if the contingency plan is enacted): no. If any release-blocking deliverable is still using X11, and if X11 is so broken that it makes it fail the release criteria, then yes, until either the regression is fixed or the contingency plan is enacted. Otherwise, no.
== Documentation == See the [https://www.freelists.org/post/xlibre/Xlibre-250-summer-solstice-release upstream 25.0 release announcement]. There is also [https://github.com/X11Libre/xserver/blob/master/README.md the upstream README.md]. Unfortunately, half of those documents consists of political statements (which are upstream's views and upstream's '''only''', see the ''Disclaimer'' section) and rants.
More details about the Xnamespace extension can also be found in the [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1865 rejected X.Org/FreeDesktop.org merge request].
== Release Notes == In this Fedora release, the X.Org X11 Xserver (<code>xorg-x11-xserver</code>) has been replaced by a maintained fork, the X11Libre Xserver (<code>x11libre-xserver</code>). This affects the Xserver itself (<code>xorg-x11-xserver-Xorg</code>) as well as the subpackages ''Xnest'' (which no longer depends on the legacy Xlib (<code>libX11</code>), but on the xcb library (<code>libxcb</code>)), ''Xvfb'', and ''Xephyr''.
End users are not expected to immediately notice any difference at all, but may in the long run benefit from fixed bugs and future features. Note however that, as with any major release of the Xserver, the X11 driver ABI has changed, so third-party drivers will need to be recompiled for the new Xserver version.
Once upon a time, Aoife Moloney via devel-announce devel-announce@lists.fedoraproject.org said:
Replace the X.Org X11 Xserver (<code>xorg-x11-xserver</code>) with the [https://github.com/X11Libre/xserver X11Libre (XLibre) Xserver], an actively maintained fork.
Given the questionable changes made to X.Org by the lead (only?) developer of X11Libre before being removed from the project, including possible license violations, I do not think following that individual's fork is a good idea. A bunch of patches of dubious quality and/or legality doesn't really mean "actively maintained" - anybody can fork something and make a bunch of commits.
https://www.phoronix.com/news/X.Org-Server-Lots-Of-Reverts
On Tuesday, 24 June 2025 at 14:19, Chris Adams linux@cmadams.net wrote:
anybody can fork something and make a bunch of commits.
For the sake of all of our sanity, I'd really appreciate if FESCo could decide on this one really quickly (e.g. putting out a statement) and avoid what could be a most unpleasant flame-fest on this mailing list.
Richard
On Tue, Jun 24, 2025 at 3:33 PM Richard Hughes via devel devel@lists.fedoraproject.org wrote:
On Tuesday, 24 June 2025 at 14:19, Chris Adams linux@cmadams.net wrote:
anybody can fork something and make a bunch of commits.
For the sake of all of our sanity, I'd really appreciate if FESCo could decide on this one really quickly (e.g. putting out a statement) and avoid what could be a most unpleasant flame-fest on this mailing list.
I appreciate the thought, but I don't think it's a good idea to short-circuit our processes. At least one week between announcement and the proposal being forwarded to FESCo is mandatory. And looking at the discussion threads, it looks like the i686 proposal is more of a flame-fest anyway 🙃
Fabio
Chris Adams wrote:
Given the questionable changes made to X.Org by the lead (only?) developer of X11Libre before being removed from the project, including possible license violations
The "license violations" are actually moving a few lines of mostly trivial declarations from one header file to another without copying the copyright notice.
As I wrote in https://discussion.fedoraproject.org/t/veto-x11libre-replacing-xorg-for-fedo... :
If you mean this one: https://gitlab.freedesktop.org/xorg/xserver/-/commit/346d5f5c352146879c749b2... which got reverted at X.Org for alleged copyright violation: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2019
Seriously? This moves 6 trivial 1-line macros and one 6-line macro (counting only the bodies, otherwise it is 1 1-line, 5 2-line, and 1 7-line macro) from one header file to a new header file with a possibly misleading copyright notice and SPDX declaration. It is not clear to me whether this tiny amount of mostly boilerplate code (do {…} while(0) pattern, delegating to another macro while defaulting some arguments) is even copyrightable at all. And the fix would be to get the copyright notice and the SPDX declaration on that new header file fixed, not to ban the whole project for such a tiny mistake.
Kevin Kofler
On 2025/06/25 5:21, Kevin Kofler via devel wrote:
Chris Adams wrote:
Given the questionable changes made to X.Org by the lead (only?) developer of X11Libre before being removed from the project, including possible license violations
The "license violations" are actually moving a few lines of mostly trivial declarations from one header file to another without copying the copyright notice.
As I wrote in https://discussion.fedoraproject.org/t/veto-x11libre-replacing-xorg-for-fedo... :
If you are going to dig into the issue, might as well go all the way.
The `misc.h` file where this originated has been licensed under `MIT AND X11` since the beginning when the code was written 13 years ago [1]. Whether or not a specific snippet makes sense to have a specific copyright handling is not a valid debate. They could have either moved the code with an over complete copyright notice or asked permission from all the relevant authors of the snippet, which they did not do.
The only explanation I could give is that when they moved the code and wrote it as `MIT OR X11` would be that they thought it meant "I don't know, this code might have be under MIT or X11" instead of "you can use *everything* in here as either MIT or X11". And to be fair, the upstream `COPYING` file does not explicitly note the license they use and they have an easy to misinterpret segment `|MIT/X11`, which could be viewed as a deprecated OR operator in the cargo ecosystem, but I doubt that was the intent in the COPYING file [2].|
|But the main issue I see is that when confronted with the licensing issue, those comments were never addressed [3] even though the person in question was not banned for another 2 months. It hints that this is a symptom of them not handling such a big project appropriately.|
Also in the post you mentioned
And the fix would be to get the copyright notice and the SPDX declaration on that new header file fixed
Well, have you submitted a PR for that? You are probably among the few qualified to work with that upstream given the tone in the README.
They have plenty of opportunities to show that they want to improve the project in a non-hostile manner, but given that the README remains unchanged despite a couple of PRs that suggests toning down the voice (among other gems that you can find in the issue/PR discussions), makes me doubt that that will be taken seriously.
[1]: https://gitlab.freedesktop.org/xorg/xserver/-/commit/2abe83df686ed64c4f4df71... [2]: https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/COPYING?ref_type=h... [3]: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1804
On Tue, Jun 24, 2025 at 8:39 PM Aoife Moloney via devel-announce devel-announce@lists.fedoraproject.org wrote:
Wiki - https://fedoraproject.org/wiki/Changes/X11Libre Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-x11libre-system-w...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary ==
Replace the X.Org X11 Xserver (<code>xorg-x11-xserver</code>) with the [https://github.com/X11Libre/xserver X11Libre (XLibre) Xserver], an actively maintained fork.
== Disclaimer ==
'''The Change Owner does NOT share or endorse upstream's political views!''' Given that those can be found even in the upstream project-wide <code>README.md</code>, the Change Owner feels obliged to make this clarification.
== Owner ==
- Name: [[User:Kkofler| Kevin Kofler]]
- Email: Kevin@tigcc.ticalc.org
== Detailed Description ==
A long time has passed since the last major release of the X.Org X11 Xserver. Even bugfix releases have become rare. Therefore, this Change proposes replacing the nearly unmaintained upstream with a maintained fork, the X11Libre XServer.
This isn't a real suggestion is it, the fork is 2 weeks old and has nobody competent enough to maintain the X server working on it?
If Kevin parallel packages X11libre for 3-4 Fedora releases, and upstream demonstrates competency, some release processes, bug fixes and CVE handling across the next 2 years or so, then it might be reasonable to submit this level of Change, so far this fork is a bunch of patches that breaks stuff, and reverts that kinda fix it after the point.
Just because someone says they are maintaining an X.org fork, doesn't mean the X.org fork is maintained well enough to switch a distro to it.
I strongly recommend FESCO to vote against this at this time, and instead Kevin do the work to show that this proposal might make sense in 3-4 releases time,
Dave.
-
Aoife Moloney via devel-announce -
Chris Adams -
Cristian Le -
David Airlie -
Fabio Valentini -
Kevin Kofler -
Richard Hughes