theme/liquidprompt: stop vendoring GPL code, detect existing install instead

[seefood]

Summary

• Liquidprompt is GPL-licensed; bash-it is MIT-licensed, so the theme should not git clone it into vendor/ at runtime as it previously did.
• Replace that logic with a thin, oh-my-posh-style wrapper: activate liquidprompt only if the user already has it on their PATH, otherwise print a warning. Nothing is downloaded, installed, or vendored.
• Add themes/liquidprompt/README.md explaining the licensing situation and pointing users at the upstream project for installation.
• As a side effect, this drops the theme's overrides of liquidprompt internals (_lp_git_branch, _lp_time, _lp_temp_*, the --no-activate shim) which had gone stale against upstream's renamed/private functions — fixing the repeated _lp_escape() errors and broken git-branch display reported in [Bug]: Liquidprompt (LP) theme has fallen out-of-sync with the Liquidprompt project #2390.

Closes #2390

Test plan

• shellcheck themes/liquidprompt/liquidprompt.theme.bash
• shfmt -d themes/liquidprompt/liquidprompt.theme.bash
• pre-commit run on the changed files (via git commit, hooks passed)
• Manually verified with liquidprompt actually installed on PATH (not done — no liquidprompt binary available in this environment)

[seefood]

@akinomyoga thoughts? I feel like there's no other clean way to keep it.

[seefood]

also resolves the discussion at #2048

[akinomyoga]

@akinomyoga thoughts?

Sorry, I haven't noticed the mention. Since I'm subscribed to the entire repository, an explicit mention and other notifications are delivered to me in a non-distinguishable appearance at a glance, and I'm not reading through all the notifications. If there are any other mentions that I didn't notice, please feel free to tell me that.

I feel like there's no other clean way to keep it.

As another option, a part of Bash-it can be distributed under the GPL license, by explicitly stating that.

If the core part of Bash-it were relying on a piece of GPL-licensed code, the entire Bash-it would probably have had to be licensed under the GPL license. However, the situation is opposite in the present case. theme/liquidprompt is one module of Bash-it, and it's not a indispensable component of Bash-it. So, I think we can say that the entire Bash-it isn't considered a derivative of liquidprompt.

• Liquidprompt is GPL-licensed; bash-it is MIT-licensed, so the theme should not git clone it into vendor/ at runtime as it previously did.

I'm not sure whether to automatically clone the source tree of GPL-licensed dependency or let the user clone the GPL-licensed dependency would be relevant. If the GPL requirements could be avoided by just letting the user download the GPL code, any software relying on a GPL library can easily avoid GPL requirements by not including the source code of the library in its distribution.

• Replace that logic with a thin, oh-my-posh-style wrapper: activate liquidprompt only if the user already has it on their PATH, otherwise print a warning. Nothing is downloaded, installed, or vendored.

I think this is important when one wants to resolve the subtlety about the GPL license. The original code seems to try to overwrite the internal API of liquidprompt, such as _lp_git_branch. This appears to be tightly bound to the liquidprompt codebase, so I think the original code would be considered to be the target of the copyleft of the GPL license. The new code just calls the public interface of liquidprompt, so I think it is usually considered to be free from the GPL license, although one might say the GPL-licensed liquidprompt is a dependency of module theme/liquidprompt.

[seefood]

Well, I am pretty sure the overwriting of LP's function is an issue (both with bit-rot and license mix), but maybe just offering the user to clone and install it for them is OK. I could ask a few of my fellow GPL-loving friends for their opinions.

[akinomyoga]

Well, I am pretty sure the overwriting of LP's function is an issue (both with bit-rot and license mix),

Yeah, I agree.

but maybe just offering the user to clone and install it for them is OK.

I also think so, though this area should be somewhat controversial.

In the first place, GPL appears to be written primarily for programs that are compiled into a binary, and it seems subtle how we should judge whether a project written in a script language is tightly bound to GPL-licensed external code.