Re: Package inclusion criteria

[ng0@n0.is]

On Wed, 31 Jan 2018, ludo@gnu.org (Ludovic Courtès) wrote:
> Hello,
>
> Leo Famulari <leo@famulari.name> skribis:
>
>> On Mon, Jan 29, 2018 at 06:09:16PM -0500, Mark H Weaver wrote:
>>> Hi ng0,
>>> 
>>> > commit 57f9671d22bb4ee37962c31b9eed0ae50859398a
>>> > Author: ng0 <ng0@n0.is>
>>> > Date:   Wed Jan 17 22:42:55 2018 +0000
>>> >
>>> >     gnu: Add badass.
>>> [...]
>>> > +  (package
>>> > +    (name "badass")
>>> > +    (version (git-version "0.0" revision commit))
>>> [...]
>>> > +    (synopsis "Hacking contribution graphs in git")
>>> > +    (description
>>> > +     "Badass generates false commits for a range of dates, essentially
>>> > +hacking the gamification of contribution graphs on platforms such as
>>> > +Github or Gitlab.")
>>> 
>>> Why do you think this belongs in Guix?  Do you intend to use it
>>> yourself, or do you have reason to believe that Guix users would want
>>> this?
>>> 
>>> There's a lot of garbage out there.  Guix doesn't need to include every
>>> script that someone uploaded to github.  Frankly, I'm embarrassed to
>>> have a package like this in Guix.
>>
>> As the committer, I thought of this as an amusing toy, and we do have a
>> couple of those.
>>
>> But if people would rather we not distribute it, I won't object.
>
> I can understand Mark’s concerns, though I don’t have a strong opinion
> on this particular package (I find it both “weird” and “amusing”; it
> reflects on how people use those Git services.)
>
> The only formal acceptance criterion for packages in Guix is that it
> must be free software and FSDG-compatible.  However, there might be
> software we’d rather not include in Guix proper for various reasons.
>
> One example we discussed recently is a package that allowed users to
> exploit specific security vulnerabilities, IIRC, and at the time we
> chose not to include it.  I suspect there are other situations where we
> might be inclined to reject the package, but it’s hard to anticipate
> them; I suspect it’s going to be rare, though.
>
> Thoughts?

I think we should do the following:

* list examples of what has been previously rejected or dropped,
  there we can list LISPF4 (accepted, never worked, code to be
  considered not really copyright worthy, dropped), the recent
  black/greyhat / PoC package I've sent, software not aligned
  with the guidelines of Guix (for example linux),...
  Probably best in full sentences "Software packages which are
  intend to be used by professionals bla bla bla ..."
* include a way for exceptions..
  the list we provide should give a clue about
  what's possible and what not, but we should decide per
  case, so that exceptions can be discussed.

> Ludo’.
>
>

-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/