Replies: 10 comments 15 replies
-
Uh, I was not aware of any wish for your work to be removed, in fact, I made the PRs solely based on your comment here: #256 (comment) I chose to submit these to |
Beta Was this translation helpful? Give feedback.
-
TBH I overlooked that you added yourself to the copyright notice, I looked at diffs only. It's simple to fix though, I can add it to any file that has your code merged into it.
Please don't blame anyone else than me, I do not represent |
Beta Was this translation helpful? Give feedback.
-
I'm sorry if this came across as a critique/attack on you. That was not the intent, and it has nothing to do with you. It is between ggerganov and me. Given the history, and there is 15 years of it even before |
Beta Was this translation helpful? Give feedback.
-
This puts me in a bind though, my intention was to upstream what I could (with the hardware I have available to test) as it seemed you were suggesting that this should be done (but not willing to do yourself). You have made a great number of awesome contributions here, and I still wish for them to be merged into mainline, as it would improve it greatly, and it might make it simpler for you to rebase and get newer features from mainline as well. This should be a win-win. |
Beta Was this translation helpful? Give feedback.
-
@CISC @JohannesGaessler As you both refer to what I wrote in #256, here it is:
Meaning there is nothing I can do to prevent that from happening as I'm publishing under a MIT license. I don't think I said that I do not expect upstream to abide by the terms of the license. |
Beta Was this translation helpful? Give feedback.
-
So, this is becoming interesting. Here is what @ggerganov has to say about my copyright notice being included in the file(s) where stuff was copied from my work:
The discussion 6934 was about Intel engineers copy-pasting CUDA kernels that I wrote into the SYCL implementation and slapping their copyright notice on it (and, to add insult to injury, they were copy-pasting the code into wrong places, and refusing to accept PRs fixing it, which was the actual reason to start the discussion in the first place). The very knowledgable conflict resolution expert with no legal education who came to resolve the conflict said that was OK, because according to the Berne Convention they couldn't take away the copyright from me by doing that (I wonder if software was covered in the original Berne Convention agreement of 1886? Just kidding). The copyright is collectively owned by the authors of the project, and their copyright is established by the AUTHORS file, so copyright notices do not need to be present in every file (but apparently it is OK for Intel to have their copyright notice in the file, without further copyright notices). @ggerganov The work from which it is being copied is not work contributed to your project by me and therefore covered by my name being in the AUTHORS file of your work. Can you please point me to the text in the Berne Convention where it is established that if you copied my work into your work, it would be OK to ignore the terms of the license under which I published my work, and not include my copyright notice in your work as requested by the MIT license? If you don't like copyright notices "sprinkled inside the code", you have the option to reject the PRs or add my copyright notice to the copyright notice of your project. Oh, another option (if you trust your legal expertise) would be to accept the PRs as is, and then make your own PRs removing the copyright notices. In that way it would be you not being nice to a fellow open source developer with whom you want to "freely exchange ideas" (and possibly violating the terms of their license), not your contributor. I think asking a contributor to do that is going too far. But at the end of the day it is your project, so yes, you can ask your contributors to play by your rules. |
Beta Was this translation helpful? Give feedback.
-
For the record: Do you find it acceptable for people to read your code and to then submit a PR to llama.cpp/ggml with the same functionality? |
Beta Was this translation helpful? Give feedback.
-
Yes, of course, as predicted. |
Beta Was this translation helpful? Give feedback.
-
A based thing to do would be to license your repository under AGPL3.0, solves all problems. |
Beta Was this translation helpful? Give feedback.
-
I'm sorry you ended up in the middle of this. I hope this has not damaged your relation with, and your ability to contribute to, the |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
We have this merged PR and this pending PR in the ggml repository copying code from
ik_llama.cpp
. It is an interesting choice of venue. ggml is well known, but much lower profile than llama.cpp. We know that changes added toggml
quietly make their way intollama.cpp
with "sync: ggml" PRs such as this one.The merged PR went into
ggml
without attribution (other than the source being mentioned in the PR). The pending PR attributes the change to<[email protected]>
, so me, but me as one of the (currently) 335 ggml authors. But I definitely did not write the code with the intent of contributing it toggml
,llama.cpp
, or any of ggerganov's projects. Does that mean that since I once contributed tollama.cpp
, the copyright on everything I produce from there on is jointly owned by the 335ggml
authors, or perhaps even by the (currently) 1106 llama.cpp authors?ik_llama.cpp
is open source, and it uses the same MIT license asggml/llama.cpp
. The MIT license saysHmm. The PRs are definitely not a copy of
ik_llama.cpp
, but are they a "substantial portion" of it? How is "substantial" being measured? By LOCs? By utility? By some other measure?Let's take the merged PR. It is just 50 LOC of trivial code. And yet, it does improve prompt processing of
bf16
models by a factor of 2 compared to this PR, which added CUDAbf16
support tollama.cpp
. The pending PR is just a 69 LOC change of only slightly less trivial code. And yet, it improves PP performance of MoE models with many experts such as DeepSeek-V3/R1/Lite by more than this 2000+ LOC rework of the CUDA matrix multiplication kernels and flash attention implementation. Let's take a look at this ik_llama.cpp PR that has not been discovered yet. The relevant change that improves MoE PP performance is the rewrite of this kernel. It is just 60 LOC or so, but the performance gain is many times more than the grand total of all modifications made to theggml/llama.cpp
Metal backend since I left these projects in March of 2024.So, again, is it utility or number of LOCs that define the copied code as "substantial portion" of the software it was copied from?
But, hey, IANAL, so it is maybe better to focus on the moral side of things. When I left the
llama.cpp
project, I expressed the wish that all of my contributions be removed. They didn't need to do it legally, but wouldn't it have been nice if they still did? ggerganov cited too much impact on downstream projects. Not onllama.cpp
itself, but on downstream projects. Because, you know, downstream projects are too inept to add back k-quants, i-wuants, and imatrix after their removal from upstream. In any case, it is known what happened, so it should be obvious to anyone that I don't want my work to be copied into ggerganov's projects. If they were nice, they would have re-implemented these changes - it is not rocket science. And if they were really nice, they would have acknowledgedik_llama.cpp
for the inspiration. Or, if they didn't feel like re-implementing it, they would add my copyright notice, legally required or not, so we don't need to ponder at what point what they copied became a "substantial portion" of the work they are copying.Beta Was this translation helpful? Give feedback.
All reactions