<jxself>My understanding is that they have numerous games available to play, in essence acting as a store or maybe a repository. "...nor should the distribution refer to third-party repositories that are not committed to only including free software..." which is what it seems would kinda be happening.
<jxself>So, I think it is not appropriate for inclusion in a free system unless all of their games were required to be free and they had a policy to remove non-free games if they were discovered to have been included by accident.
<mark_weaver>my understanding is that it's okay if only the game artwork/maps are non-free.. but yeah, they'd have to be committed to including only free software.
<mark_weaver>and I don't get the impression that they have any such commitment.
<jxself>Indeed - the non-functional parts (sounds, pictures, etc.) don't need to be free but do need to allow for (at least) verbatim distribution both commerically & non-commercially.
<mark_weaver>yeah, I forgot to mention the requirement to allow verbatim redistribution.
<mark_weaver>actually, I'm not sure what RMS's position would be on whether it's okay for a free distro to merely _steer_ users toward downloading non-functional data that does not allow verbatim redistribution.
<davexunit>but isn't this what is done with browser addons and such already?
<davexunit>there would have to be someone willing to do such work.
<jxself>In a way, yes. But it's additional administrative work, so just pointing it out as something to consider.
<gzg>jxself: That's an interesting prospect, but too a big if. That being said, as/if Guix gets a *lot* more popular -- I think it'd be good to have clear package guidelines out there, for those less familiar with such ideals/standards. We probably don't want to be flooded by commits which are some factor of unusable, if the platform gets picked up on/to any major degree. :^P
<jxself>gzg: I think it's already clear enough in the FDSG on gnu.org/distros?
<jxself>If not, a clarification can be brought up on the gnu-linux-libre mailing list? I understand that there is FSF staff subscribed there.
<gzg>jxself: I'm saying, making such specifications more easily discoverable to those hacking on Guix. Not really an obvious place to find such info and if you are using Guix for a technical reason, then such prospects might not be active in one's mind. :^P
<gzg>mark_weaver: Well yes, I know that -- but my concern is that it's not obvious for those in the future (if/when gets a flood of new contributors for packages) and we get a flood of patches for expressions that break these, because they aren't using/hacking GNU for ethical reasons, but technical ones "strictly" (primarily). Though, I might just be worrying for little to nothing. :^P
<jxself>Yep, and hopefully people hacking Guix will at least read that, since I think it's linked to in the documentation? If not, perhaps it'll come up when patches are submitted to the mailing list and get caught there? Even if something that shouldn't be there makes it all the way in that's not necessarily a bad thing as long as the distro makes a good faith effort to only include appropriate stuff and removes stuff when it's discovered.
<gzg>jxself: I might just be a bit anxious, with the "recent" gotcha with Emacs awhile back -- that there was a far amount of flack for.
<civodul>fixing it is really important for us, but i'd like to get help with that
<jmd>What are "native-inputs" and how are they different to "inputs" ?
***jmd` is now known as jmd
<Steap>civodul: so, what happened with the eog patch series is that I was away from home :)
<mark_weaver>jmd: the distinction between 'inputs' and 'native-inputs' is important when cross-compiling. 'native-inputs' are inputs that will run on the build machine at compile-time, and 'inputs' will run on the host at run-time.