I don't see how this claimed issue is valid.
https://github.com/ollama/ollama/blob/main/llama/llama.cpp/L... says:
"The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
The issue submitter claims:
"The terms of the MIT license require that it distribute the copyright notice in both source and binary form."
But: a) that doesn't seem to be in the license text as far I can see; b) I see no evidence that upstream arranged to ship any notice in their binaries, so I don't see how it's reasonable to expect downstreams to do it; and c) in the distribution world (Debian, etc) that takes great care about license compliance, patching upstreams to include copyright notices in binaries isn't a thing. It's not the norm, and this is considered acceptable in our ecosystem.
Maybe I'm missing something, but the issue linked does not make the case that there's anything unacceptable going on here.
The need to extract license and copyright information for binary distribution is universally accepted among Open Source license compliance practitioners and lawyers.
There is a whole industry of tools around it (Fossid, Fossa, BlackDuck, Snyk), as well as Open Source projects ( FOSSology, scancode, oss-review-toolkit).
Re: Debian, they have copyright files in their packaged that are manually curated by Debian Developers and should include all those license texts and copyright notices.
Ah - we're talking about different things.
I was concerned about the implication (or so I thought) that a binary executable should provide the required documentation (eg. via --version or similar). You are thinking about the text being included as part of a binary redistribution. That did not occur to me, because to me, GitHub issues refer to sources, not binary redistributions.
But of course GitHub does have a Releases page. If those binary redistributions do not contain the license text, then I accept that's something that Debian does do, and is the norm in our ecosystem.
But as other commenters have said, it's not completely clear that this is actually a violation of the license, since https://github.com/ollama/ollama/releases/tag/v0.7.0 for example bundles both source and binary downloads and the bundle does contain the license text via the source file download. Certainly anyone who downloads the binary from the maintainer via GitHub does have the required notice made available to them.
I won't address the rest, but:
> b) I see no evidence that upstream arranged to ship any notice in their binaries, so I don't see how it's reasonable to expect downstreams to do it
Downstream is not in compliance. The fact that upstream has made that compliance hard/impossible is not relevant to the fact that downstream is infringing.
And it's not hard at all. You just include a text file with a third party software notice that has all the licenses, alongside the binary. All major companies shipping F/OSS in their products somehow manage to do this just fine (I have personally done so for three different products at two different companies).
It's so normal and common that your car's infotainment screen has a page for it, and it causes the guy who built a useful open source project to get hate mail, because his email address is listed there.
> in the distribution world (Debian, etc) that takes great care about license compliance, patching upstreams to include copyright notices in binaries isn't a thing
On Debian, you will find the llama.cpp copyright notice in /usr/share/doc/llama.cpp/copyright if you have installed the llama.cpp binary package.
You cannot argue successfully in court that the copy of the binary compiled code is not a copy of a substantial portion of the software. The fix is very trivial. This should not be an open issue.
a) Correct. b) Not relevant. The license says what it says regardless of what upstream does or doesn’t do. If someone wants to use the code they should comply with the license requirements.
A README is often included with binaries. That’s a good place to include any licensing information.
If it's not valid, why was this ticket not disputed and/or closed?
Not really a fan of the “failure to sufficiently deny an accusation is an admission of guilt” line of thought.
Maybe they’re getting a legal opinion. Maybe they’re leaving it open while they talk business to business. Maybe the right person to address the issue is on vacation.
Lots of people and companies choose not to engage in public battles. I don’t think that should be read as a sign of guilt (or innocence).
> Maybe they’re getting a legal opinion.
Acknowledging the issue is something you are looking into does not incriminate you.