Github messages for voidlinux
 help / color / mirror / Atom feed
From: reback00 <reback00@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [proposal] templates without official binaries
Date: Sat, 31 Oct 2020 17:58:03 +0100	[thread overview]
Message-ID: <20201031165803.CmQxzDv96zkYNv95dz1a48myiXx9ZWbWWut_qZl0nLE@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-25901@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 3588 bytes --]

New comment by reback00 on void-packages repository

https://github.com/void-linux/void-packages/issues/25901#issuecomment-719959943

Comment:
@hippi777 
> (btw i saw on the way that the ryf cert has even more crazy requirements, like the nonfree repo couldnt even exists...

Well, [RYF](https://ryf.fsf.org/) is for libre hardware and [FSDG](http://www.gnu.org/distros/free-system-distribution-guidelines.html) is for Free/libre distros. So, I think you're referring to FSDG.

Yes. That's true. FSDG has many strict rules. Those are to ensure that packages remain "pure". There are so much telemetries, nonfree advertisements pointing to other apps + plugins and nonfree dependencies within the packages we use, that GNU had to be this strict to ensure distros and their packages are truely respecting our freedom and privacy. Even Linux kernel has become somewhat poisonous. Hyperbola went so far as to wanting to [develop their own BSD system](https://www.hyperbola.info/news/announcing-hyperbolabsd-roadmap/) in order to escape the issues with Linux kernel and the current state of FOSS licensing and nonfree dependencies.

However, in the current state of Void it is impossible that it can be accepted as libre. Even Fedora and Debian which do not have repos with proprietary packages enabled by default, were [refused](https://www.gnu.org/distros/common-distros.html) because their default repo has some nonfree parts or they host the nonfree repo on their own server.

So, in order to get Void to be FSDG approved there has to be a massive undertaking of sorts, like:
- totally deleting `restricted` repo from server and system as if it does not exist,
- cleaning up existing packages and removing packages from main repo that can't be liberated ever,
- getting rid of `linux` kernel and only offering `linux-libre` kernel,
- changing documentations and every text to erase everything related to nonfree things (unless criticizing nonfree options),
- and there could be more things to take care of?!

@drake-newell started a [project](https://github.com/ymir-linux/void-packages) to create linux-libre kernel packages for Void. Then I joined him to contribute on "liberating" nonfree packages. As much as I understand Drake and myself, we would really be happy if we could include these packages on Void's ecosystem. We came to know that [due to resource limitations](https://www.reddit.com/r/voidlinux/comments/g3v6hl/linuxlibre_kernel_built_with_xbpssrc/fnwex2y/) custom kernels (like linux-libre) can't be accepted. Drake didn't want to create a separate project, but he had to, because how much of the package we had to liberate + custom kernel had to be kept separate. We are still friends to, and grateful to the Void Linux community.

> rejected stuffs like kernel variants (like libre/xanmod/zen), browsers etc

If you mean you want to have libre packages to be available on a Void repo, I think this would be a great idea. A separate `libre` (or some other chosen name) repo can be created. Packages with [minor issues](https://github.com/ymir-linux/void-packages/issues/8) can be there with liberated versions of them. It can be a bunch of patches over the existing srcpkgs specifying the changes to be applied on templates and files in order to liberate them. This way we can eliminate the need to merge changes from master everytime a change comes. I think this is doable.

This will not be a 100% FSDG compliance by any means, but it would be a step in the right direction. People will be able to enjoy "reasonable freedom" on their Void system.

  parent reply	other threads:[~2020-10-31 16:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-26 15:53 [ISSUE] " hippi777
2020-10-27 11:53 ` Duncaen
2020-10-27 11:53 ` Duncaen
2020-10-27 13:20 ` hippi777
2020-10-31 16:58 ` reback00 [this message]
2020-10-31 17:23 ` hippi777
2020-10-31 17:47 ` reback00
2020-11-01  9:56 ` hippi777
2020-11-01 10:29 ` Duncaen
2020-11-01 11:45 ` hippi777
2020-11-01 12:05 ` Duncaen
2020-11-01 12:06 ` Duncaen
2020-11-01 18:13 ` reback00
2020-11-01 18:14 ` reback00
2020-11-01 18:17 ` reback00
2020-11-01 20:06 ` hippi777
2020-11-01 22:31 ` fosslinux
2020-11-01 22:34 ` fosslinux
2020-11-02 16:12 ` reback00
2022-04-22  2:14 ` github-actions
2022-04-22 15:56 ` [ISSUE] [CLOSED] " Duncaen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201031165803.CmQxzDv96zkYNv95dz1a48myiXx9ZWbWWut_qZl0nLE@z \
    --to=reback00@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).