Troubles with setting the `license` field

[Anton-Latukha]

Describe the bug

Sometimes it is hard to discover & put appropriate license. Especially in proprietary, default case (NONE) or corner cases, or when licenses have compounds in names/versions.

To Reproduce

Lets follow how Haskell developers form a package, & populate license: field:

Because project/package bootstrapping can take quite a time, or there is some customization involved - people frequently use other projects & samples. Previously I copied particular files manually, or used real projects & deleted code from them, or used summoner tool. Now - I've made a bootstrap for myself & so copied bootstrap/sample.

Then during the renaming of things in the .cabal - since project/package is a private project, testing assignment, company project - license field needs to be changed.

Haskeller googles "Haskell cabal licenses" & because person is Haskeller:

(looking into the future - SPDX search also would return nothing particularly useful)

Websearch engine determines as relevant & advertises Hoogle, particularly https://hackage.haskell.org/package/Cabal-3.6.2.0/docs/Distribution-License.html.

Which is great. Seems like License data type is what license field wants.

And in a number of cases that assumption would be true - MIT, BSD* indeed would fit.

Lets look at UnspecifiedLicense or AllRightsReserved.

Since all countries in the world signed the agreement that no license defaults to be https://en.wikipedia.org/wiki/All_rights_reserved

license: UnspecifiedLicense:

> cabal v2-build                                                                 (1)
Errors encountered when parsing cabal file ./project.cabal:

project.cabal:11:35: error:
unexpected Unknown SPDX license identifier: 'UnspecifiedLicense' 

   10 | maintainer:     user@email.com
   11 | license:        UnspecifiedLicense

This error is not healful at all. The #5697 situation strongly applies here. SPDX happens to be an open-source license list - it has no accounting for any default closed source license scenarios.

license: AllRightsReserved:

> cabal v2-build                                                                 (1)
Errors encountered when parsing cabal file ./project.cabal:

project.cabal:11:35: error:
unexpected Unknown SPDX license identifier: 'AllRightsReserved' You can use NONE as a value of the license field.

   10 | maintainer:     user@email.com
   11 | license:        AllRightsReserved

This error is a bit better - it mentions the ability to use NONE for a license field.

After that - I become curious:

1. Why it seems that Distribution.License is a valid source of information - the closest possible source right to reading source code directly, but it does not work.
2. What is the acronym SPDX that tooling keeps referring to. The first idea - it probably some Haskell type, maybe Cabal-internal one, or maybe some conventional filetype, or conventional spec.
3. Hey, cabal asks for SPDX & its module source of truth Distribution.License happens to have function: knownLicenses :: [License], it probably should give the index:

   λ> knownLicenses
   [GPL Nothing,GPL (Just (mkVersion [2])),GPL (Just (mkVersion [3])),LGPL Nothing,LGPL (Just (mkVersion [2,1])),LGPL (Just (mkVersion [3])),AGPL Nothing,AGPL (Just (mkVersion [3])),BSD2,BSD3,MIT,ISC,MPL (mkVersion [2,0]),Apache Nothing,Apache (Just (mkVersion [2,0])),PublicDomain,AllRightsReserved,OtherLicense]
   it :: [License]

(I've tried/experimented to put values literally - maybe that is a universal way of giving the Cabal license values)

> cabal v2-build                                                                 (1)
Errors encountered when parsing cabal file ./project.cabal:

project.cabal:11:35: error:

unexpected Unknown SPDX license identifier: 'AGPL' 

   10 | maintainer:     user@email.com
   11 | license:        AGPL (Just (mkVersion [3]))

Unknown SPDX license identifier: 'AGPL' - confusing :confused:, which values then it accepts.

4. Ok Cabal error message always talks about SPDX values.

In Distribution.License there is [licenseToSPDX :: License -> License - great - a converter to SPDX - which Cabal keept nagging me into:

λ> licenseToSPDX AllRightsReserved
NONE

It works!

licenseToSPDX $ PublicDomain
License (ELicense (ELicenseRef (LicenseRef {_lrDocument = Nothing, _lrLicense = "PublicDomain"})) Nothing)
it :: Distribution.SPDX.License.License

Tried the License .., then entered the ELicense .. value into license: field, received unhelpful messages.

Checked PublicDomain & received a direction toward using anything more substantial then PublicDomain value.

Ok, lets check some default open source license:

λ> licenseToSPDX $ AGPL (Just (mkVersion [3]))
License (ELicense (ELicenseId AGPL_3_0_only) Nothing)
it :: Distribution.SPDX.License.License

Again, now with this SPDX value - tried to enter the License .., then tried to enter ELicense .. value into license: field, received unhelpful messages.

unexpected Unknown SPDX license identifier: 'License' 

   10 | maintainer:     user@email.com
   11 | license:        License (ELicense (ELicenseId AGPL_3_0_only) Nothing)
      |                        ^

...
unexpected Unknown SPDX license identifier: 'ELicense' 

   10 | maintainer:     user@email.com
   11 | license:        ELicense (ELicenseId AGPL_3_0_only) Nothing

So, licenseToSPDX function was not helpful for the user.

Distribution.SPDX.License points to that License ... expression is a SPDX format. But if Cabal wants to get SPDX format, and value is in SPDX format - why Cabal does not accepts the SPDX that is generated with its own functions.

Expected behavior

• [ ] Cabal checker error message form should direct Haskeller into proper direction:
  • [ ] Since it is Haskellers - to make them perfectly happy (also because people love to read/use code directly more then reading long documentation) - give them info on how to locate where to look in Hoogle or in sources/which module API to look into - to give them direction to the proper source of truth to construct/generate the values that satisfy the checker.
  • [ ] Give a function to list simple licenses (unilicenses in Cabal/SPDX expression terms).
  • [ ] Have a permalink into listing of the majority (by use cases) of the values accepted & where it explains the corner cases, as NONE & directs somewhere in situations with complex licenses.
  • [ ] Alternative: Link to the source code of the checker, or mention how to find it, so Haskellers can see what constitutes accepted license: values, since SPDX happens to be a DLS language also.
  • [ ] Since SPDX is also a DSL language Maybe , maybe it is sound to allow SPDX expressions (seems like expressions are allowed, just happens that produced by licenseToSPDX expressions are not SPDX expression language), or Distribution.License values to be accepted in the license field.

System information

cabal-install version 3.6.2.0
compiled using version 3.6.2.0 of the Cabal library

[fgaz]

First of all, as you found out, hackage/haddock is not a meaningful documentation source for executables and file format specifications, it's only for library apis. You wouldn't expect to find documentation about eg. pandoc flags, or the spec for pandoc templates there.

I don't know how/if we could make this clearer. The cabal website already links to readthedocs and not to hackage, and we can't really control what google says.

As per https://github.com/haskell/cabal/issues/5697#issuecomment-1036449858 I'd welcome a pr improving the license section of the docs, clarifying that the field is optional (though default: NONE already implies that). The spdx docs are already linked from that section.

Alternative: Link to the source code of the checker [...]

I think linking to the source of anything (or to hoogle) would be a step in the wrong direction.

The "unexpected Unknown SPDX license identifier" error could certainly link to https://cabal.readthedocs.io/en/latest/cabal-package.html#pkg-field-license though

[ptkato]

I'd welcome a pr improving the license section of the docs, clarifying that the field is optional (though default: NONE already implies that)

I have that already underway.

[Anton-Latukha]

I mainly denoted the experience, even if for myself for later action.

An error message is generally the best place to put the documentation in some of the enumerated cases.

A lot of things can be solved with the docs. But there is a limit to docs design. Programmers try to skim the web first. Docs desync from the source code all the time. Yes, the problem with the docs - that Google mostly directs to the main init pages of Cabal & almost never directs into the proper place in the docs, but I do not thing the Google search engine can be blamed there, as the length of doc articles are huge that for the search engines exaggerate the issue & is probably the main problem of undiscovrability, so the web search can not direct the user to the proper part of the docs, the part of the thread subparagraph needs to be actively inferred/found by the reader. And in many cases the place where the content is - can not be inferred, for example - licensing information - it is either in the initial documentation, or in some advanced part, or in some legal section, or in package description section for the field. Docs approach works only up to some volume & beyond that limit of volume - volume becomes unmaintainable (through classical source code process means), which makes docs out of date, which makes people do not trust the docs, which makes people not read the docs.

For example - in the mentioned section: cabal.readthedocs.io/en/latest/cabal-package.html#pkg-field-license it is hard to infer wherever the Pre-SPDX Legacy Identifiers are available in new versions. On the first read I thought that those are just accepted old-time ways of providing license (and I used to refer & use Distribution.License.License as a reference - and it worked in the past in the majority of cases). Try shows that project responds differently to different Distribution.License.License entries, but docs are unclear on the state is it possible to use them or not in new releases. And for example, the docs give listing of main license entries examples for the deprecated way, but does not provide a set of the frequently used licenses for SPDX case & essentially sends to read the SPDX manual & run trials on the tool to find a proper way to set LGPL 3.1 through SPDX. So the docs essentially direct & encourage people to use the old way which is said to been deprecated. This unclearness in the docs & situation - links directly to the situation I started report with - I went into that Pre-SPDX Legacy Identifiers datatype & started using it. If I'd found & read the pkg-field-license - probably ended up pretty much on the same path, but was a bit less confused.

Docs are a great tool, they frequently seem a great way of solving everything, but thunking things into docs is not always a great design. On errors of parsing license: - linking people back into the docs - is indeed the main part of the solution, linking people in error messages from the tool into docs - is a pretty good desing/way to guide them. But also error messages are docs in themselves.

Also, CI needs to run checks that links into docs are valid.

So, annotated the situation, would try to submit/close this, solving particular details, accordingly in the future, as these details are nice tasks to solve for a newcomer.

[Anton-Latukha]

Well, I was quick to promise to solve it. Because the war is approaching & everything hangs in the air constantly here. So, lets say "maybe I would not be able".

[Mikolaj]

Take care, @Anton-Latukha. No pressure, obviously.

[Anton-Latukha]

[Edit by @Mikolaj: this is off-topic and to a large extent not about technical matters.]

Want to inform that I am currently seeking a Haskell Foundation DevOps position.

Because Haskell jobs are in US/EU mostly & because of the dire situation in Ukraine - corporations continuously were rejecting me without explanations in my 2.5 ~ 3 years of jobsearch. So I am quite in distress now.

For a long time - I wanted to help Cabal as a DevOps, because I know Cabal is severely understaffed, the most crucial, complex understaffed project in core of Haskell freedom giving IT system. But circumstances always were such that I quite could not to get the position to reach to participate properly in such a cornerstone piece of Haskell infrastructure, as for years I was always refused to earn any money - I could not alleviate all compounded problems that keep compounding which constantly force me to continue job search, 3-4 level interview systems, 40-60h long work assignments for free & by the corporations my biography and skill never were respected. Never even once in ~3 years corporations given "deep concern" - the main diplomatic export to Ukraine in the last 30 years. GPS coordinates I was born in - by corporations always were chosen to be the main factor against helping me rather than a reason to even at least try to help me.

While I sacrificed everything I could to help others.

So wherever opened & read I Cabal bootstrap code, or not - does not matter - oppression system does not allow me the position to help the project. I need to find money, search for a job, do assignments while simultaneously I also need to plan & prepare for what to do & overall prepare for the war (I'd better go got training at least several weeks ago), dodge the decayed Russians (totalitarian decaying sympathizers) who threaten me on the streets frequently (somehow in 3 years of threats, not once I got threats in Ukrainian), do that & somehow live without any money or property to leverage or rely on. & in that position constantly work, participate in Free Software/Open Source movement, search for work, do "Implement Queuing theory modeling engine" assignments & continuously accept that I did bit amount of work & was rejected for petty reasons that not hold any critique & while not once was given "concern", & trying to analyze & find my fault to improve from it.

The reality is - I can talk about math fields, history, application of methodologies & results of scientific thought, thoughts of Nietzsche, the brilliance of Simone de Beauvoir, or study thoughts of Jacques Lacan, find implications of architecture, people processes, find the design that fits into unseen rules which are hard to express or formulate, find Wu Wei path, and explain to people implications between different ideas - but most who reject me - can not hold a conversation on any of those themes, or even not aware of basic logical biases.

While I recently was interviewed by Senior Haskell Developer to work under him in the company, during the interview he felt a moment of honesty & confessed he started learning Haskell 2 weeks ago. But I somehow in 5 years & writing a book on the subject & working for the public good - I mean - that not compare to 2 weeks of reading Haskell on the side, it is like comparing Zappa & mumble rap levels - of course, mumble rappers with blings know more about musical composition, hey - they have blings after all. Zappa - has none. We can not compare - (he is Ukrainian - don't take him)! :rofl:

I had a better opinion of Haskell community than this.

[Anton-Latukha]

[Edit by @Mikolaj: this is off-topic and to a large extent not about technical matters.]

In face of the amount of experience & facts, I ask from Haskell Foundation to accept me, with my biography of IT architect, moreover, one which was both classical DevOps & specializes in Haskell & Nix & Nix DevOps, for 356$/m a month to work on Haskell infrastructure, it is 0.04 of the budget they planned for that position. I reason that taking 1 infrastructure engineer - is a bad design choice (Gamari would need either constantly control the work, or system design choice implies no control on methodologies, decisions, design, code quality, understandability, reproducibility, documentation, lock-in, errors, bus factor), so Haskell Foundation should be interested to hire at least 2 DevOps people. So far I repeatedly got silent refusal to help me in imminent danger.

So I would ask, please, if you found me in any way a reasonable person - Haskell community should be interested to accept my sacrifice.

[Mikolaj]

@Anton-Latukha: I sympathise, but I think writing on a bug-tracker is not an effective way to apply for a job or to turn people's attention to any problems not directly related to the bugs in question. I guess https://discourse.haskell.org may be a better venue for general remarks (but please, mark it so in the topic), but beware than writing lengthy manifestos, especially with personal notes, is a red flag for any recruiters. That's not because manifestos are bad, but because of a an evolutionary pressure: those recruiters and corporation employees that take the time to read 100 manifestos, 99 of which are irrelevant and emotionally taxing, 1 of which turns out after a long time to be very accurately diagnosing the situation and having accurate predictions, fall behind the recruiters and corporations that read none and spend the time and energy doing their actual job.

Let me repeat, I sympathise, I've read it all, instead of doing my Cabal job, and if you'd like to chat about it, please email me at mikolaj.konarski@gmail.com --- I'm not recruiting ATM nor affecting any recruitment, so you can speak freely. I'm marking your comment as off-topic so that others don't read it in error, thinking it's about technical issues.

[Anton-Latukha]

Yes, thank you.

I am just under tremendous pressure & stress.

I just try to be most polite & solve the question by diplomacy & not post to public forums, to not hit the Haskell Foundation reputation.

Just for 3 last years I applied for jobs & was refuted for all of them, except 2 (but I have not time to explain, they were cryptocurrency scheme companies, so I declined).

So in 3 years I was not given any work.

People could understand me.

It is a question of life and death for me.

[gbaz]

@Anton-Latukha I have tried to message you on irc but not received a reply. Please ping me at sclv on liberachat.

[asarkar]

~How would I specify Apache 2.0 license in the package.yaml so as to correctly translate to Cabal?~

https://spdx.org/licenses/