Hackage rejects valid SPDX license bzip2-1.0.6

[hasufell]

Error:

This server does not accept packages with 'license' field set to e.g. AllRightsReserved. See https://hackage.haskell.org/upload for more information about accepted licenses.

License: https://github.com/hasufell/bzip2-clib/blob/bd9965afdf2799943369c6ecd4d9afa8eace8584/bzip2-clib.cabal#L5

SPDX: https://spdx.org/licenses/bzip2-1.0.6.html

[gbaz]

the bzip license is a valid spdx identifier, and is parsed as such.

however, it appears to be neither on https://opensource.org/license or https://www.gnu.org/licenses/license-list.en.html which means it is neither osi nor fsf approved, which is our Source of Truth for what licenses are allowed to be uploaded to hackage. See https://hackage.haskell.org/package/Cabal-syntax-3.10.2.0/docs/Distribution-SPDX-LicenseId.html#v:licenseIsOsiApproved for the implementation of those functions.

[hasufell]

Well, this code is uploaded 3 times to hackage already with an incorrect license:

• https://hackage.haskell.org/package/bzlib
• https://hackage.haskell.org/package/bzlib-conduit
• https://hackage.haskell.org/package/bz2

So should we keep lying about the license?

[gbaz]

hrm i think for these it really should be a joint license -- one for the haskell code, and one for the bzlib code. in all cases the haskell code is intended as bsd-3, but the bundled code is bzip2, but of course we didn't used to be able to express compound licenses, although I think we now can?

To do things right we can add a special bzip exception to the hackage license check, if we're comfortable with it. I think that would require understanding why the bzip2 license is not osi/fsf approved -- I think its the patent clause that deviates?

Curious what others may think!

[hasufell]

The reason is probably that OSI requires a tedious license review process through a mailing list from the 80s and no one really cares what the OSI thinks.

[chreekat]

@hasufell please edit your comments so that I don't have to report them for harassment. I suggest being more accurate in your assertions and more understanding in your assessment of complex issues.

[ffaf1]

The reason is probably that OSI requires a tedious license review process through a mailing list from the 80s and no one really cares what the OSI thinks.

OSI and FSF have actual legal professionals working for them, their opinions carry weight. I disagree with straying from authoritative sources.

OSI Licence Review process promises a decision in a timely fashion (normally sixty days from submission). Anyone can submit a licence, not only the original author.

Have you considered stewarding it yourself? I can help with the process if you are extremely busy.

[hasufell]

@hasufell please edit your comments so that I don't have to report them for harassment. I suggest being more accurate in your assertions and more understanding in your assessment of complex issues.

No, not unless you can explain what about them is harassment. That is a pretty severe allegation. None of my comments are ad-hominem or discriminate anyone.

I do think the OSI is mostly irrelevant when it comes to accepting licenses. That is my opinion.

Have you considered stewarding it yourself? I can help with the process if you are extremely busy.

No interest.

(normally sixty days from submission)

Yeah, I can't work with that in the light of a CVE.

[Bodigrim]

The immediately available solution is to put license: OtherLicense, no? (Probably together with cabal-version: 1.12 or similar, so that cabal check does not get angry)

[hasufell]

Yeah that trick seems to work: https://hackage.haskell.org/package/bzip2-clib-1.0.8.0.99/candidate

But that won't work with newer cabal formats.

[hasufell]

Relevant code:

hackage-server/src/Distribution/Server/Packages/Unpack.hs

Lines 506 to 526 in 7ca3dd8

	isAcceptableLicense :: PackageDescription -> Bool
	isAcceptableLicense = either goSpdx goLegacy . licenseRaw
	where
	-- `cabal-version: 2.2` and later
	goSpdx :: SPDX.License -> Bool
	goSpdx SPDX.NONE = False
	goSpdx (SPDX.License expr) = goExpr expr
	where
	goExpr (SPDX.EAnd a b) = goExpr a && goExpr b
	goExpr (SPDX.EOr a b) = goExpr a || goExpr b
	goExpr (SPDX.ELicense _ (Just _)) = False -- Don't allow exceptions
	goExpr (SPDX.ELicense s Nothing) = goSimple s
	goSimple (SPDX.ELicenseRef _) = False -- don't allow referenced licenses
	goSimple (SPDX.ELicenseIdPlus _) = False -- don't allow + licenses (use GPL-3.0-or-later e.g.)
	goSimple (SPDX.ELicenseId SPDX.CC0_1_0) = True -- CC0 isn't OSI approved, but we allow it as "PublicDomain", this is eg. PublicDomain in http://hackage.haskell.org/package/string-qq-0.0.2/src/LICENSE
	goSimple (SPDX.ELicenseId lid) = SPDX.licenseIsOsiApproved lid || SPDX.LId.licenseIsFsfLibre lid -- allow only OSI or FSF approved licenses.
	-- pre `cabal-version: 2.2`
	goLegacy License.AllRightsReserved = False
	goLegacy _ = True

And in Cabal-syntax:

• https://github.com/haskell/cabal/blob/226983560c130aeec53575947e66eff0d965b650/Cabal-syntax/src/Distribution/SPDX/LicenseId.hs#L1498
• https://github.com/haskell/cabal/blob/226983560c130aeec53575947e66eff0d965b650/Cabal-syntax/src/Distribution/SPDX/LicenseId.hs#L1633

[gbaz]

Now that the pr is up, my thoughts are I'm ok with this, because I don't think osi will approve it (doesn't fall under legacy standards because too specific to one project, and certainly doesn't fall under new standards).

I'm open to merging the pr, but would like to see if anyone has further thoughts. I know @phadej worked on some of this in the past as well, and @hvr though not very active may want to weigh in.

[phadej]

AFAICT, Bzlib (https://spdx.org/licenses/bzip2-1.0.6.html) is essentially the same as BSD-4-Clause (https://spdx.org/licenses/BSD-4-Clause.html), latter is fsf libre license.

-The name of the author may not
-be used to endorse or promote products derived from this software without specific prior written permission.
+Neither the name of the copyright holder nor the names the copyright holder nor the names of its contributors may
+be used to endorse or promote products derived from this software without specific prior written permission.

See https://en.wikipedia.org/wiki/BSD_licenses#4-clause_license_(original_%22BSD_License%22)

This clause was objected to on the grounds that as people changed the license to reflect their name or organization it led to escalating advertising requirements when programs were combined in a software distribution: every occurrence of the license with a different name required a separate acknowledgment. In arguing against it, Richard Stallman has stated that he counted 75 such acknowledgments in a 1997 version of NetBSD.[7] In addition, the clause presented a legal problem for those wishing to publish BSD-licensed software which relies upon separate programs using the GNU GPL: the advertising clause is incompatible with the GPL, which does not allow the addition of restrictions beyond those it already imposes; because of this, the GPL's publisher, the Free Software Foundation, recommends developers not use the license, though it states there is no reason not to use software already using it.[4]

Also https://www.gnu.org/licenses/license-list.html#OriginalBSD

I'd emphasize recommends developers not use the license, though it states there is no reason not to use software already using it.

I'd say, as BSD-4-Clause is there, than allowing the bzlib license just for bzlib-clib package, and nothing else is the most precise approach. Alternatively, uploading bzlib-clib using BSD-4-Clause is IMO not violating the terms too badly to be punished, but IANAL.

At least in the perspective that e.g. ghcup binary cannot be distributed due the license incompatibility, as it depends on cabal-install-parsers (GPL) and bzlib at the same time...

... but nobody cares (I guess I could as a copyright owner of cabal-install-parsers, but I don't feel like being PITA right now).

[ysangkok]

I have read this thread and I merged the PR since a couple of months have passed and nobody voiced any additional concerns.