[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Package inclusion criteria
From: |
Ludovic Courtès |
Subject: |
Re: Package inclusion criteria |
Date: |
Thu, 01 Feb 2018 00:48:14 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
address@hidden skribis:
> On Wed, 31 Jan 2018, address@hidden (Ludovic Courtès) wrote:
>> Hello,
[...]
>> 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 ..."
Like I wrote, these are quite unusual situations and special cases. I
don’t expect to be able to have a policy document covering possible
cases.
(Linux is not included because it contains non-free software; that’s the
one inclusion criterion that’s very clear and unambiguous.)
Ludo’.