Cabal: license: BSD3 not recognized

[angerman]

Needs to be rewritten to BSD-3-Clause.

That can't be right.

Error is:

unexpected Unknown SPDX license identifier: BSD3

[erikd]

This is to distinguish between licenses that are versioned, like GPLv2 and GPLv3 and variants of the BSD license like BSD-3-Clause and BSD-2-Clause.

[angerman]

alright, so every package that bumps the cabal version, must change BSD3 to BSD-3-Clause?

[gbaz]

As per https://github.com/haskell/cabal/pull/5050 it looks like @phadej is still taking comments on the design. I think this migration is a bit too rough and some alternate approaches were laid out here: https://github.com/haskell/cabal/issues/2547#issuecomment-120965735

Personally I wouldn't mind if a few "super-common" things like BSD3 were grandfathered in forever. At a very minimum we should emit a better error message for the time being that indicates what the suggested rewrite of the field should be.

[hvr]

I'd rather make sure we migrate quickly to proper SPDX style identifiers, after all we got everything version guarded now via cabal-version:2.2 (if you upgrade the spec version via cabal-version, you need to pay attention anyway if your package declaration semantics have changed, or if you need any other changes; setting the spec version your package conforms to is supposed to be a willful act; it's not something you do w/o reason). If we "grandfather" BSD3, at the very least I'd expect is to have cabal check tell you what the proper SPDX identifier is you have to use when uploading to Hackage. The point of SPDX is to use a standardised token scheme, but if you build in backdoors, this undermines the standardization effort of SPDX imo (note also that tools which only understand the SPDX tokens may want to scan cabal files for them; they wouldn't recognise BSD3).

[gbaz]

I agree on cabal check if we grandfather things in. If people don't want the complexity, I'd still reiterate that the minimum should be to give the suggested fix with the error (since we have the information at hand, its almost perverse not to provide it :-P)

[phadej]

I'm against grandfathering things. If you have to update to cabal-version: 2.2 to get something else (be it virtual-modules, or elif or ...) then you can update the license field too.

Better error message is a always good thing. See #5113

[angerman]

alright.

[erikd]

@phadej What about keeping support for BSD3 for the next three releases? As a commercial user (at Ambiata we have 10 engineers and over 300 cabal files for over 300 interdependent projects) breaking changes like this create a lot of unnecessary work.

[angerman]

As far as I understood this only happens if you bump the cabal-version as well. If that is not the case, that would be rather sad.

@erikd just do a global /BSD3/BSD-3-Clause/ ?

[gbaz]

Yes, as I understand it, this only kicks-in on existing projects if you're updating the cabal-version anyway, presumably to take advantage of other new features as well. So it shouldn't cause any extraneous commits -- rather it would be part of the process of modifying a cabal file for some other reason anyway.

[erikd]

@erikd just do a global /BSD3/BSD-3-Clause/ ?

@angerman It is nowhere near that simple.

@gbaz If it only kicks in when modifying the cabal-version then I am fine with it.