Really shitty move for a giant company to create a competing library with such a similar name to an existing project. Bound to cause confusion and potentially steal libcurl users because so many people associate Google with networking and the internet.
Holy shit! It’s with a Ru in the middle instead of a Ur! I actually missed that until I read your comment and reread the whole thing letter-by-letter. Google knows full well that this will cause confusion since they added a feature to chrome for this exact problem. Egregious and horrible.
Google knows full well that this will cause confusion
I’m not part of the team anymore and have no connection to this project, but my guess is that some engineers thought it was a funny pun/play on words and weren’t trying to “trick” people into downloading their library. I’m not saying you shouldn’t be careful about perceptions when your company has such an outsized influence, but I highly doubt this was an intentional, malicious act.
Honestly, their lack of empathy here, and the need to extend rather than collaborate indicates in my opinion a concerning move away from OSS. I hope to be corrected though.
I can agree that using such a similar name is in poor form. Is there a trademark on the Curl and Libcurl names? If so, there could be some legal action, perhaps.
Part of the reason I prefer GNU Wget is the license. If Curl were under the AGPLv3, this wouldn’t happen. In any case, we’ll see how this progresses, I suppose. It would be an interesting case study if Daniel Stenberg has his project ripped out from under him by the same mechanism that he’s approved of in the past for proliferating it.
Using the AGPLv3 license for curl would not prevent Google from reimplementing the API. Only the implementation can be protected by copyright, not the API.
That’s what everyone thought until Oracle sued Google over the Java API and won the appeal. Now we’re waiting to see if the Supreme Court reverses that.
It therefore reversed the district court on the central issue, holding that the “structure, sequence and organization” of an API is copyrightable.
The question of whether APIs can be copyrighted is not settled in the USA, and is currently leaning towards “yes, they can be” unless the Supreme Court reviews and reverses.
The article says about reimplementing it in part. I made a reasonable assumption that it could mean culling some of the existing API surface.
And again, I totally agree on the naming disaster. I’m waiting now when they invent a “plausible” explanation of why they chose this name, and how it’s totally not going to screw anything up.
Why is that necessarily wrong? It’s a complex problem space; there are going to be options, or there are going to be locally floated patches in forks all over the place.
The shitty move is the naming convention, which is literally two letters in the middle transposed from the original library name. People might get Google’s offering simply by typo.
That is a very generous interpretation. Why would I have to typo libcurl when my browser, or my search engine, can infer my “real” meaning and “helpfully” point me to the “corrected” name?
[I’m writing this after Google’s “clarification” that the name will be libcurl_on_cronet because I don’t think that version is any better. It literally contains the name of the other project.]
It literally contains the name of the other project
Supposedly because it literally implements the libcurl API on top of cronet?
As I understand it (having heard of cronet for the first time through this issue despite working on Chrome OS firmware), this allows Chrome (and its third parties, like imported libraries) to conduct all communication through cronet (a http-and-friends library) even if they use the libcurl API.
This hints to me that they want to unify the way such connections are made across the application, and it’s easier to reimplement the subset they need (the API surface used by chrome + dependencies) rather than forking all those libraries and tools (Chrome OS) and rewrite their libcurl uses into cronet uses.
Oh! Sorry about that! Misunderstood totally. I get what you mean about it being fine though. I’m also fine with them reimplementing it if they called it something obviously distinct. Forks and clones happen!
This whole muddy “libcurl but not that project” game is messy. Imagine if Linux was called “Minxi” or “Minix_as_monlith” or something…
I hope there’s an uproar about the name.
Really shitty move for a giant company to create a competing library with such a similar name to an existing project. Bound to cause confusion and potentially steal libcurl users because so many people associate Google with networking and the internet.
I wonder how long it takes for google autosuggest to correct libcurl to libcrurl.
Looks like crurl was just an internal working name for the library[0]. They’ve changed it already in their bug tracker to
libcurl_on_cronet[1].[0] https://news.ycombinator.com/item?id=20228237
[1] https://chromium-review.googlesource.com/c/chromium/src/+/1652540
Holy shit! It’s with a Ru in the middle instead of a Ur! I actually missed that until I read your comment and reread the whole thing letter-by-letter. Google knows full well that this will cause confusion since they added a feature to chrome for this exact problem. Egregious and horrible.
I’m not part of the team anymore and have no connection to this project, but my guess is that some engineers thought it was a funny pun/play on words and weren’t trying to “trick” people into downloading their library. I’m not saying you shouldn’t be careful about perceptions when your company has such an outsized influence, but I highly doubt this was an intentional, malicious act.
I’d bet this is exactly what happened. I’ve given projects dumb working names before release, and had them snowball out of my control before.
Honestly, I had to double check that I wasn’t reading
libcrule.Honestly, their lack of empathy here, and the need to extend rather than collaborate indicates in my opinion a concerning move away from OSS. I hope to be corrected though.
The ‘i’ in crurl stands for ‘innovation’
I can agree that using such a similar name is in poor form. Is there a trademark on the Curl and Libcurl names? If so, there could be some legal action, perhaps.
Part of the reason I prefer GNU Wget is the license. If Curl were under the AGPLv3, this wouldn’t happen. In any case, we’ll see how this progresses, I suppose. It would be an interesting case study if Daniel Stenberg has his project ripped out from under him by the same mechanism that he’s approved of in the past for proliferating it.
Using the AGPLv3 license for curl would not prevent Google from reimplementing the API. Only the implementation can be protected by copyright, not the API.
That’s what everyone thought until Oracle sued Google over the Java API and won the appeal. Now we’re waiting to see if the Supreme Court reverses that.
https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.#Appeals_Court_and_finding_of_copyrightability_of_the_API
(And if you ever needed yet another reason not to support Oracle, this is it.)
The question of whether APIs can be copyrighted is not settled in the USA, and is currently leaning towards “yes, they can be” unless the Supreme Court reviews and reverses.
Embrace. Next up: Extend.
About curl being standard, only on c and php no?
And also a lot of functionnality in it is just here because it is supposed to support any code using the existing code.
Also as far as I know, that anyprotocol not only http was a big source of security bug in php
This is a shitty move, no doubt about that. But on a purely technical reasoning I can sorta see why someone might want to reimplement curl:
No, they are talking about re implementing those options. If they wanted a new thing they could have done that without mentioning curl.
The article says about reimplementing it in part. I made a reasonable assumption that it could mean culling some of the existing API surface.
And again, I totally agree on the naming disaster. I’m waiting now when they invent a “plausible” explanation of why they chose this name, and how it’s totally not going to screw anything up.
Why is that necessarily wrong? It’s a complex problem space; there are going to be options, or there are going to be locally floated patches in forks all over the place.
The shitty move is the naming convention, which is literally two letters in the middle transposed from the original library name. People might get Google’s offering simply by typo.
That is a very generous interpretation. Why would I have to typo
libcurlwhen my browser, or my search engine, can infer my “real” meaning and “helpfully” point me to the “corrected” name?[I’m writing this after Google’s “clarification” that the name will be
libcurl_on_cronetbecause I don’t think that version is any better. It literally contains the name of the other project.]As I understand it (having heard of cronet for the first time through this issue despite working on Chrome OS firmware), this allows Chrome (and its third parties, like imported libraries) to conduct all communication through cronet (a http-and-friends library) even if they use the libcurl API.
This hints to me that they want to unify the way such connections are made across the application, and it’s easier to reimplement the subset they need (the API surface used by chrome + dependencies) rather than forking all those libraries and tools (Chrome OS) and rewrite their libcurl uses into cronet uses.
Sorry, I was reacting specifically to the suggestion that the existing curl API is too big and complicated, and I should have made that clear.
Oh! Sorry about that! Misunderstood totally. I get what you mean about it being fine though. I’m also fine with them reimplementing it if they called it something obviously distinct. Forks and clones happen!
This whole muddy “libcurl but not that project” game is messy. Imagine if Linux was called “Minxi” or “Minix_as_monlith” or something…
I didn’t say it was wrong. I said I understand why someone might genuinely want a simpler API.
[Comment removed by author]