On Sun, 12 Aug 2018 at 13:52:57 +0200, Wouter Verhelst wrote:
> The obvious objection to that would be the fact that the SPDX
> identifiers are not set in stone; a future update of the SPDX
> identifiers might then conflict with one of the identifiers that we add.
> Either we'd need [...], or a rule to not have non-SPDX identifiers.
>
> Personally, I have a preference towards the latter; it seems simpler,
> and there is benefit to be had to encourage creating a new SPDX
> identifier over having a "local" fix.
I don't think we should have a policy that forbids packaging useful
software whose license happens to be absent from the SPDX list. It can
be harder, it can need special cases, but it should not be impossible.
For example, if I was a maintainer of the SPDX license list, I wouldn't
want to include the license of the Return to Castle Wolfenstein engine
(see src:iortcw), which is GPLv3 with additional terms that will probably
never be used as-is by any other upstream; adding instances of license
proliferation to the list just because they are used by a leaf package
really doesn't scale. However, it's a valid GPLv3-compatible free software
license, and we should be able to include software under that license
in Debian (iortcw is in contrib because it needs proprietary game data,
but if someone extracts or derives code from iortcw that does not need
the proprietary game data, it should be allowed in main).
I am not defending license proliferation, but as a downstream maintainer
I don't get to decide whether my upstream participates in it.
smcv
