Skip to content

remove cases where cabal2nix produces a stringy license - #677

Open
jopejoe1 wants to merge 6 commits into
NixOS:masterfrom
jopejoe1:licenses
Open

remove cases where cabal2nix produces a stringy license#677
jopejoe1 wants to merge 6 commits into
NixOS:masterfrom
jopejoe1:licenses

Conversation

@jopejoe1

@jopejoe1 jopejoe1 commented Oct 18, 2025

Copy link
Copy Markdown
Member

I'm working on removing all stringy licenses in nixpkgs, and currently the only ones left are the ones in haskellPackages and node2nix packages. This change fixes the ones for Haskell packages.

@sternenseemann sternenseemann left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also add a changelog entry, ideally noting when nixpkgs added support for lib.licensesSpdx.

Comment thread cabal2nix/src/Distribution/Nixpkgs/Haskell/FromCabal/License.hs Outdated

fromCabalLicense :: Distribution.License.License -> Distribution.Nixpkgs.License.License
fromCabalLicense (GPL Nothing) = Unknown (Just "GPL")
fromCabalLicense (GPL Nothing) = Known "lib.licenses.gpl2Plus"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These cases are intentional as there is not enough information to conclude what variant of the license in question is used.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do realize they were intentional, but they can't stay in their current form. I'm currently working towards disallowing stringy licenses in nixpkgs, and those are pretty much the only ones left. Other options would be to make it even less informational with lib.licenses.free or to add a new custom license (not really a fan of this).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked at a few packages in more detail and I think we can reasonably do two things:

  • interpret GPL as gpl2Plus as done here. That's because they could have used GPL-2 or GPL-3 if they wanted to be more specific.
  • just use free as fallback for this.

For me, both are fine.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

free as a fallback seems reasonable for GPL without further specification, that is a good idea. (But not in general as a fallback for unknown, see #677 (comment)).

Comment thread cabal2nix/src/Distribution/Nixpkgs/Haskell/FromCabal/License.hs Outdated
Comment thread cabal2nix/src/Distribution/Nixpkgs/Haskell/FromCabal/License.hs Outdated
Comment thread cabal2nix/src/Distribution/Nixpkgs/Haskell/FromCabal/License.hs Outdated
homepage = "https://github.com/blamario/incremental-parser";
description = "Generic parser library capable of providing partial results from partial input";
license = "GPL";
license = lib.licenses.gpl2Plus;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upstream has changed to GPL-3 by now.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is probably fine to update these test expressions to newer versions of the cabal file, but some of them may test something specific that has since been removed.

homepage = "http://github.com/jgm/highlighting-kate";
description = "Syntax highlighting";
license = "GPL";
license = lib.licenses.gpl2Plus;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upstream still uses GPL, and has gpl2Only, I think: https://github.com/jgm/highlighting-kate/blob/master/LICENSE

homepage = "https://github.com/skogsbaer/HTF/";
description = "The Haskell Test Framework";
license = "LGPL";
license = lib.licenses.lgpl2Plus;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upstream has now LGPL-2.1, which renders as LGPL-2.1-only on hackage.

homepage = "https://wiki.haskell.org/Lambdabot";
description = "Social plugins for Lambdabot";
license = "GPL";
license = lib.licenses.gpl2Plus;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lambdabot-social-plugins has GPL, but.. the license looks like BSD/MIT: https://github.com/lambdabot/lambdabot/blob/master/lambdabot-social-plugins/LICENSE

homepage = "http://github.com/jgm/texmath";
description = "Conversion between formats used to represent mathematics";
license = "GPL";
license = lib.licenses.gpl2Plus;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

texmath has updated to GPL-2, which renders as GPL-2.0-only on hackage.


fromCabalLicense :: Distribution.License.License -> Distribution.Nixpkgs.License.License
fromCabalLicense (GPL Nothing) = Unknown (Just "GPL")
fromCabalLicense (GPL Nothing) = Known "lib.licenses.gpl2Plus"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked at a few packages in more detail and I think we can reasonably do two things:

  • interpret GPL as gpl2Plus as done here. That's because they could have used GPL-2 or GPL-3 if they wanted to be more specific.
  • just use free as fallback for this.

For me, both are fine.

@sternenseemann

sternenseemann commented Oct 24, 2025

Copy link
Copy Markdown
Member

For context, see also #520.

One thing to keep in mind is that while cabal2nix mostly deals with Hackage, it may also process arbitrary cabal files. We can make some assumptions in Nixpkgs since additions of unfree packages would always have to be manual, but it does not seem wise to have such assumptions leak into cabal2nix which may be used in arbitrary ways on arbitrary inputs.

In particular,

  • I don't like mapping ambiguous licenses to something we reckon is probably right. If we don't have enough information to accurately determine the license from metadata, we should not guess. Instead, such information needs to be set manually via overrides in Nixpkgs. This gets the desired effect (no stringy licenses) without requiring questionable behavior. Also, it creates an incentive to get upstream maintainers to update their meta data. (Edit: Mapping GPL to free as suggested in remove cases where cabal2nix produces a stringy license #677 (comment) is correct, so we could do that.)
  • We also should not map anything to lib.licenses.free because it only holds for Hackage packages. cabal2nix can't tell a package descriptions origin in all cases, so this is an exercise in futility. If license information is missing, I would propose we just do not set license and change haskellPackages.mkDerivation to allow for this.

Apologies for the inconsistent messages. Some of my earlier comments were informed by an incorrect assumption how we decide on free/nonfree.

(Note that prior to #520, cabal2nix would prevent “unfree” packages from being built on Hydra, but Nixpkgs seems to consider stringy licenses as free by default (?). So from cabal2nix's perspective, we are currently always reporting the license accurately without any illegitimate transformations and letting Nixpkgs decide whether it is free or unfree. This should be preserved, in my opinion.)

Comment thread cabal2nix/src/Distribution/Nixpkgs/Haskell/FromCabal/License.hs Outdated
Comment thread cabal2nix/src/Distribution/Nixpkgs/Haskell/FromCabal/License.hs Outdated
Comment thread cabal2nix/src/Distribution/Nixpkgs/Haskell/FromCabal/License.hs Outdated
@sternenseemann

Copy link
Copy Markdown
Member

Cherry picked 7a5af01 onto master.

@sternenseemann

Copy link
Copy Markdown
Member

We currently have about 250 packages with a string license we actually are building and distributing. In total, haskellPackages contains about 1000 packages with a stringy license, about 75% of those are currently marked as broken or depend on a broken dependency.

github-merge-queue Bot pushed a commit to NixOS/nixpkgs that referenced this pull request Oct 26, 2025
`stdenv.mkDerivation` does not require meta.license to be passed, so there
is no reason `haskellPackages.mkDerivation` needs to enforce this. This
would free up cabal2nix to not report a license if it is not sure.

As I have argued in NixOS/cabal2nix#677 (comment),
it is better not to report a license than reporting an inaccurate one.

This would also allow to stop generating arbitrary strings as licenses
in cabal2nix to remove string values to facilitate more cleanliness in
the spirit of #445672, though the
question is whether it is wise to remove the meta data altogether.
@jopejoe1

jopejoe1 commented Dec 6, 2025

Copy link
Copy Markdown
Member Author

Sorry for not being really active in here was working on an improvement for licenses in nixpkgs for making this nicer to implement here. see NixOS/nixpkgs#468378

@jopejoe1
jopejoe1 marked this pull request as draft January 14, 2026 10:18
@jopejoe1
jopejoe1 force-pushed the licenses branch 3 times, most recently from 002da57 to 02b5459 Compare April 20, 2026 11:01
@jopejoe1 jopejoe1 changed the title make parsed license to be less like tobe a stringy license reduce the cases where cabal2nix produces a stringy license Apr 20, 2026
@jopejoe1
jopejoe1 marked this pull request as ready for review April 20, 2026 11:03
@jopejoe1

Copy link
Copy Markdown
Member Author

Did a larger refactor based on the changes done in NixOS/nixpkgs#468378 and the feedback that was given here.

@jopejoe1
jopejoe1 requested a review from sternenseemann April 20, 2026 12:57
@jopejoe1 jopejoe1 changed the title reduce the cases where cabal2nix produces a stringy license remove cases where cabal2nix produces a stringy license Apr 23, 2026
@jopejoe1

jopejoe1 commented Jul 6, 2026

Copy link
Copy Markdown
Member Author

Now that compound licenses are supported in all supported nixpkgs versions, could this be moved forward?

@sternenseemann

Copy link
Copy Markdown
Member

Yes, I'd be interested in that!

Though, I'm still of the position that we should not fall back to something nondescript like licenses.free if we don't recognize the license. That can be solved manually in Nixpkgs or upstream (ideally). Probably a lot of packages affected by this would also wind up excluded eventually.

jopejoe1 added 6 commits July 11, 2026 14:25
make use of the new compaund licenses in nixpkgs to get more correct licensing information
we do our own logic in nixpkgs based on is writen in meta.licenses with more complex logic than this
if we don't know the specific version of a license fallback to a generic free license
@jopejoe1

Copy link
Copy Markdown
Member Author

Should work like this now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants