I don’t know what that is, but their docs very prominently and strongly say this:
> However, we do not maintain a stable Go language API or ABI, as Git LFS is intended to be used solely as a compiled binary utility. Please do not import the git-lfs module into other Go code and do not rely on it as a source code dependency.
I made Kubernetes into a library once. Like the apiserver and default controllers, running in-process. Copying and pasting were involved. I was not expecting support.
If code is out there under a compatible license, you can do whatever you want with it. If it breaks, you get to keep both pieces.
That you technically have the ability to call into an internal module does not in any way constitute it "offering itself up as a library", and doesn't make it effectively useful in that way.
A library and a module are the same. Having an open and available module does not make it "offered up as a library," was the point I was trying (and failing, evidently), to make.
You made the point perfectly. So did the docs in the first place.
It's not on you that someone decides not to agree the sky is blue because they use their own definition of blue.
yeah, it does:
https://godocs.io/github.com/git-lfs/git-lfs/v3