dict-en-gb has become GPL preventing cspell updates

[CreativeTechGuy]

Info

Kind of Issue

• runtime - command-line tools
• building / compiling
• security
• change in behavior
• crash / error

Which Tool or library

• cspell -- the command-line spelling tool
• cspell-tools -- used for building dictionary files
• cspell-lib -- library that does the actual spell checking.
• cspell-trie -- tool for working with trie files.

Which Version

Version: @cspell/dict-en-gb 2.0.1, cspell 5.9.1

Issue with supporting library?

• No
• cspell-glob -- library for matching glob patterns
• cspell-io -- thin file i/o library
• cspell-trie-lib - trie lib
• cspell-trie2-lib - trie lib alternate format

OS:

• Macos
• Linux
• Windows
• Other

version:

N/A

Bug Description

Describe the bug

@cspell/dict-en-gb has become GPL and is not a modular part of cspell. Therefore if an organization cannot use GPL libraries, this effectively makes all of cspell impossible to use as one dictionary has a less permissive license.

I understand that the cspell-dicts is a separate repo, but the change there directly affects the legality of using cspell as a whole since it is not modular.

To Reproduce

1. Organization prohibits GPL licenses
2. Cannot install cspell as it is missing a required dependency @cspell/dict-en-gb

Expected behavior

I see a few possibilities to fix this:

• Find another dictionary for en_GB which is MIT licensed so all of cspell can stay MIT
• Make cspell dictionaries optional peer dependencies so an end user can choose to install only the dictionaries that they want/need. This will make it more cumbersome to use but will give a way to avoid certain dictionaries that have less permissive licenses.

Screenshots

N/A

Additional context

This was introduced via this commit in an effort to change the underlying dictionary dependency

cspell.json

N/A

Example Repository (Optional)

N/A

[Jason3S]

I understand the issue about GPL. It is very sticky. Which is why I try to keep everything MIT.
Some of underlying words for the en-GB dictionary are LGPL, so I had to change the license of the dictionary.
I can release another version of the en-GB dictionary that is LGPL. But I'm not sure if that solves the issue, but it might.

There are a couple of things going on here.

1. Package Install Requirement
   The @cspell/dict-en-gb is listed as a dependency and will get installed.
2. Run-time requirements.
   The CSpell CLI and libraries do not need the the @cspell/dict-en-gb to run. It is only loaded on demand if:
   1. The language is set to en-GB
   2. The path associated with dictionary ID en-gb is @cspell/dict-en-gb. This can be overridden by user configuration.

Because of the loose coupling described in 2, CSpell does not need to be GPL.

Depending upon your use case, that might also be true.

For more in depth support, please use the contact information at Street Side Software.

[CreativeTechGuy]

Thanks for your reply. LGPL would not solve the issue for me but I cannot speak to if that'd make a difference to anyone else.

I am completely blocked from installing @cspell/dict-en-gb due to the license, so even if it isn't used at runtime due to my configuration, I cannot use cspell at all because it fails to install. I've had to lock all of our packages to 5.8 because of this.

It sounds like as long as any dictionary has a GPL license (or anything GPL-like) we won't be able to upgrade cspell beyond 5.8 as it doesn't seem like there is a way to skip installing certain dictionaries we don't use.

[Jason3S]

I might be able to change it so that the dictionary is an optional install.

To give me a better idea, what is your use case for cspell? Do you use it to check code and documents or bundle it with another product?

[CreativeTechGuy]

We just use it to check code during development. I have filed for an exemption with my legal team for using this GPL code given the nature in which it is used, but it'll still be a pain as someone will need to file a new exception for every new version of this package.

My intent with filing this report was to make sure you were aware of the impact of this which it sounds like you already are, which is good. If there is a way this can be solved, and I can be of any help, do let me know. I am a huge advocate for everyone using cspell at my company and it is definitely going to be a harder sell now that it is more difficult to install.

I might be able to change it so that the dictionary is an optional install.

While selfishly I think this would be great, I can see how this would be confusing for most people given that all other dictionaries are bundled. I am a big fan of consistency so I'm curious if it'd be better to have dictionaries act like plugins (think like Webpack, Rollup, ESLint, etc). Where whenever you include one in your config, you have to install that dictionary too. If that is the pattern for all dictionaries then it'll be far less confusing. And I'm sure there could also be a "omni-dictionary" dependency that would include all of them like the current behavior.

This would also have a nice side benefit of reducing the install size. I know I only use a very very small fraction of the included dictionaries.

[Jason3S]

Dictionaries are plug-in style.
By default, it is bundled with English.

To add German @cspell/dict-de-de - npm:

1. npm i -S @cspell/dict-de-de
2. cspell.json

   { "import": ["@cspell/dict-de-de/cspell-ext.json"] }

[CreativeTechGuy]

Ah I guess I was focused on the dozens of programming languages that were included by default but didn't consider the human languages. I wonder if that plug-in approach would be good for all dictionaries? So out of the box cspell is just the runner/cli and you would always need to install at least one dictionary to use it.

And thank you for the rapid turnaround on the optional gb dictionary! ❤️

[CreativeTechGuy]

Oh and I realized I was wrong about being able to lock the version of cspell to fix the issue. We'd need to lock to a very old version because since the package that has an issue is pretty deep in the tree, it'll still take the latest version even if we don't update cspell. So your optional fix has become even more important now! :)

[Jason3S]

Would you please try cspell@5.10.0-alpha.6

[CreativeTechGuy]

I'm testing this on a non-work project where I can see what gets installed. I removed the package-lock.json and node_modules, installed alpha.6 but for some reason it shows the following (trimmed to remove anything not related to @cspell/dict-en-gb):

"@cspell/cspell-bundled-dicts": {
    "version": "5.10.0-alpha.6",
    "requires": {
        "@cspell/dict-en-gb": "^2.0.2",
    }
},
"node_modules/@cspell/cspell-bundled-dicts": {
    "version": "5.10.0-alpha.6",
    "dependencies": {
    },
    "engines": {
        "node": ">=12.13.0"
    },
    "optionalDependencies": {
        "@cspell/dict-en-gb": "^2.0.2"
    }
},

This is with NPM v7 BTW which is why there is a node_modules/ entry there. That is the one that looks correct actualy, but yet @cspell/dict-en-gb is still installed.

It's also interesting that @cspell/dict-en-gb (with a lower version) doesn't appear in the dependency list as I saw in your PR.

This seems to be an issue with NPM v7 (see here) but apparently has been fixed. I'll try it out on another machine with NPM v6 and report back. Interesting to know, but not directly related to this issue.

[CreativeTechGuy]

Actually that NPM issue might be important as it says to not include a dependency in both optionalDependencies and dependencies.

If I run it with npm install --no-optional then it doesn't install any version of @cspell/dict-en-gb. So yeah it seems that optionalDependencies is overriding the same name in dependencies.

We could go with an approach of making all of the dictionaries optionalDependencies. It seems these get installed by default so the experience will be the same for most users. But from the npm package.json docs it seems that if an optionalDependency is not found or fails to install, it'll continue installing the parent. So that can effectively give us the full plug-in system but rather than having to explicitly install each that you want to use, it tries to install all of them by default and if some fail, it carries on regardless. I assume this will require a code change though to support these possibly being not present.

[Jason3S]

I'll roll back to the v1 version of en-gb since it is a breaking change. I'll have to think about the right way to move forward.

[Jason3S]

I have published 5.10.0. It rolls back @cspell/dict-en-gb to 1.1.33

[CreativeTechGuy]

Thank you so much for this and the incredibly fast turnaround. :)

[Jason3S]

Please let me know if it fixes the issue.

[CreativeTechGuy]

I'll definitely let you know when I am able to test it. Due to license scanning requirements, all packages are delayed by a week or so before we are able to install. But it looks good on paper so I'm pretty confident it'll work. I'll report back late next week when I can confirm.

[Jason3S]

@CreativeTechGuy,
Please find out your companies policy on LGPL libraries. It would be useful to get a feel for their reasons to accept or reject them.

[CreativeTechGuy]

LGPL has most of the same issues as GPL. If a library is allowed to be used that has some specific legal requirements around bundling/minifiying there's a chance that some team will miss that requirement and accidentally minify the code or bundle it in some way. Both of which are prohibited under LGPL. They are erring on the side of caution to ensure that no one can accidentally use code in some way that would be illegal. Even if something like cspell probably won't be bundled or redistributed, it technically can be and that is enough of a concern that we stay away.

[Jason3S]

@CreativeTechGuy,
Thank you.

I'll close this for now, since I rolled back the change.
I will release the English GB dictionary separately with the LGPL license.

[CreativeTechGuy]

I was finally able to install cspell 5.10.1 successfully. Sorry for the daly in response, there were tons of unrelated issues due to npm's CouchDB upgrade. 😑

Thanks again for your help!

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.