It looks like, due to a separate issue with the JS, such packages won't be clearly marked as "unfree", since license information for most (all?) packages is not displayed. This should be a fairly easy fix (and in fact FIXME #49 already exists for it) to look for info.meta.license.fullName if info.meta.license is an Object rather than a String.

Sorry, but Nixpkgs is intended as a free software distribution, so it should not promote the availability of unfree packages. It also shouldn't show broken packages unless they are conspicuously marked as broken.

The reason for this change is that somebody tried to package sublime text, and discovered after 3 hours that we already have it.

@edolstra there's a difference between promoting and actively hiding. All we want is a good user experience, and hiding existing work from users because of a philosophical stance doesn't seem helpful in the long run. It causes wasted work, as @LnL7 mentioned, and also causes people to incorrectly conclude that Nix and nixpkgs is less mature and capable than it really is.

It seems possible to at least openly acknowledge that we have the packages in the system while still not building or distributing them over Hydra and getting people to opt into installing them, right? I'm not looking for magic "oh shit my system is full of unfree software how did that happen???" situations, but there has to be a happy medium between forcing people to clone and grep nixpkgs to find out that we have e.g., Spotify or Steam and installing it on their system by default, right?

@edolstra I'm not convinced that showing them in the index clearly marked as "nonfree" counts as "promoting" them; if you're that concerned, maybe make it an opt-in "show packages with nonfree licenses" tickbox on the page somewhere rather than making it on by default. Even debian, who are fairly hardcore about this, don't go so far as to completely hide nonfree packages from the index. Neither does SUSE, although they relegate nonfree packages to a separate repo.

Also, even if they are listed in the index and someone doesn't realize they're nonfree, there's still no chance of accidentally installing nonfree software, because as soon as you try it'll error out and tell you to enable allowUnfree if you really mean to do this.

I do agree that this shouldn't be merged until displaying package licenses is fixed.

@edolstra how would you feel about hinting to users that an unfree package exists, especially if they get zero results? that's a suggestion by @alexfmpe over at NixOS/nixpkgs#17126 (comment)

if not, probably this PR should be closed with prejudice.

@copumpkin right in his comment.

Potential users look for apps in https://nixos.org/nixos/packages.html , if they don't find commercial apps like sublime, proprietary nvidia driver, like in
https://packages.gentoo.org/packages/app-editors/sublime-text
https://aur.archlinux.org/packages/?O=0&K=sublime
they'll think that package unavailable, resulting in thinking that nixpkgs is poor and other distros more practical to satisfy needs.

@edolstra you either win users by letting them see that nixpkgs capable to provide modern desktop apps, or users will pick other distros.

Please merge & include unfree the search index.

NixOS/nixpkgs#17126
gained 46 supporting comments, and 21 upvotes out of 23 participants.

I think an option to "Show proprietary packages" like in #78 would be a good solution. Maybe with tooltip to clearify what free software is and why you might not want to use proprietary software.

Hi, I've been watching the thread here for a while.

I have a solution I have been working off and on (mostly off) for that problem, which is a re-implementation of the packages searcher with more features, including regex search, switching channels and showing unfree packages. Furthermore, channels switching would help with #193 and #56. As the app's state is in the URL, #23 and #57 too could be handled.

Here's a demo: https://nix.samueldr.com/explorer/

I haven't yet made "official moves" to get this on the website since I still need to

1. Cleanup the code.
2. Integrate it into the website build.
3. Misc minor improvements.

The code isn't bad, but I want to at least put my eyeballs on every lines once more. The code isn't hidden away. The biggest thing I wanted to tackle was split out the searcher/lists logic from the views to make a common codebase be used for the options list and the packages list.

Let's make this comment a commitment to try harder to upstream this effort.

@samueldr great!

This still don't fixes the issue i just commented in #57.

https://nix.samueldr.com/explorer/?channel=nixos-unstable&page=1&query=screen&unfree=true

Also, regex is not something a normal user is able to use. Instead it should not be necessary to use it.

Let's say I can subtly insert a way to permalink to a particular attribute 😅, as this would be a better experience than using a regex. Using such link could also unfold the result row automatically.

I'm closing this PR due being inactive and also since many things changes since this was opened. we will probably continue on this topic here -> #300