The curl author writes in the linked article that Google has a right to do this both morally and legally. He should check with a trademark lawyer immediately since they don't have a right to pick such a confusing name and the curl trademark is probably strong enough to be enforceable even in unregistered form. (I'm not a lawyer and this is not legal advice, but I have been involved in administering and enforcing other open source trademarks.)
Hey, Will from Google's Open Source Office here.<p>I apologize for the confusion this caused; that was certainly not the intent. Mea culpa! The name "libcrurl" was just an internal working name for this effort that wasn't expected to gain much attention.<p>This project is still very experimental in nature (as discussed at <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=973603#c4" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=973603...</a>), and there are no plans here to try and replace or compete with libcurl. We have huge respect for the tireless work Daniel does to maintain curl, and didn't mean to cause any confusion or extra work for him.<p>To make things clearer, the team is renaming the project, and adding some more docs outlining the goals and intent of the project: <a href="https://chromium-review.googlesource.com/c/chromium/src/+/1652540" rel="nofollow">https://chromium-review.googlesource.com/c/chromium/src/+/16...</a>
I’ve read the title as “Google to reimplement curl in libcurl”. I only noticed the libcrul after reading the article so they certainly have a point that’s it’s very confusing.
<a href="https://groups.google.com/a/chromium.org/forum/m/#!topic/chromium-dev/0TmXyy_G9_o" rel="nofollow">https://groups.google.com/a/chromium.org/forum/m/#!topic/chr...</a> suggests this is an intern project. My guess is that some proof of concept will be committed, then the internship will end, then nobody is going to use this for anything, and in a few years it's going to be deleted again. This seems more like a project that's happening because it's technically possible, not like one that's actually all that useful.
Some context here: cronet is a high-performance HTTP/QUIC library. It seems to be promoted as an alternative to HttpUrlConnection and OkHttp for Android developers, with a Java API and implementation in C++.<p>I'd guess this bug is more about making it easier to use from C.<p><a href="https://developer.android.com/guide/topics/connectivity/cronet" rel="nofollow">https://developer.android.com/guide/topics/connectivity/cron...</a><p><a href="https://medium.com/@cchiappini/discover-cronet-4c7b4812407" rel="nofollow">https://medium.com/@cchiappini/discover-cronet-4c7b4812407</a>
Their motivation isn't really made clear in the bug (easier for developers to switch to is a little too vague), but if I had to guess, I'd bet the actual reason is that they want the debug/insight/whatever features from cronet available to all the third party dependencies in their monorepo, and a shim was the easiest way.<p>Doesn't make it a good look, though.<p>As an aside: Given history with Google's other OSS libs, I have absolutely no faith in them having a concept of a stable ABI, or even API. This is anecdotal of course.
Woah, I feel like this is all blown out of proportion.<p>AFAICT, nobody's actually trying to replace the curl that people will have installed on their workstations or laptops.<p>The cronet http/quic library (cronut url: crurl) could use some command-line tools to test it and make the underlying protocols (e.g., quic) useful outside of a browser. I think this is a test tool/utility to ship with that library. I don't think it's going to be installed by default anywhere. Maybe I'm wrong? I think the name was chosen only to indicate how it should be used ("like regular curl"), not to indicate that it's a competitor. curl does all kinds of useful things that I don't think this one is intended to do.<p>I don't think the authors are trying to replace curl, as much as imitate it for a development utility.<p>But, I can imagine that it sucks to spend a ton of time on developing proper curl and suddenly hearing that Google's going to replace it with one developed by a big team of big-company engineers. I don't think that's what's going to happen, but I can imagine that Daniel Stenberg had a nasty pang in his heart when he heard about libcrurl's curl implementation.<p>[disclaimer: I'm an ex googler that did some work on chrome while never being part of the chrome team, I don't think I know any of the involved people]
Only hacker news can impute so much malice into the plans of an intern. If she can really disrupt free software in only 12 weeks then good for her I guess.
If Google is just hoping to get their new protocols implemented in something curl-like, they ought to implement them in curl and send it upstream.<p>However, it's totally fine to provide several implementations of the same API. If it applies to Oracle's Java then it applies to Daniel's curl, even if we like one more than the other.<p>HOWEVER, that name has got to change. If an unambiguous pronunciation is not evident then it comes off as a deliberate attempt to muddy the waters and capture mindshare of an open source project.
Somewhat related, the reason curl is called curl: <a href="https://ec.haxx.se/curl-name.html" rel="nofollow">https://ec.haxx.se/curl-name.html</a>
"libcrurl" seems tailor-made to cause confusion.<p>If they wanted to follow usual fork/clean-room-implementation alternative norms, they could use some kind of synonym for "curl" such that the intent is clear without being infringing.<p>Suggestions:<p>- libcoil<p>- libtwist<p>- libcrimp<p>- libswirl
> pretty strong indication that their API will not be fully compatible<p>If the compatibility problems are from an incomplete implementation of the API, it will simply be an inferior inferior implementation, perhaps optimized for different uses or environments.<p>However,if the incompatibility is from an <i>extension</i> of the API introduced after initially <i>embracing</i> the <i>de facto</i> standard set by te widely-used original implementation that is outside their control, it will be a clear example of the Embrace, Extend, Extinguish[2] method. The canonical example of EEE is when Microsoft introduced an incompatible "security feature" in their implementation of Kerberos. Hopefully, Google won't do the same thing to HTTP with a new and supposedly-important "security feature" in their re-implementation of libcurl.<p>[1] <a href="https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish" rel="nofollow">https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...</a><p>[2] <a href="https://web.archive.org/web/20140222133423/http://www.networkworld.com/news/2000/0511kerberos.html" rel="nofollow">https://web.archive.org/web/20140222133423/http://www.networ...</a>
Does this mean that QUIC and other protocols implemented by Chrome will be available through this Google library? That would be a benefit over existing cURL.
Back when I forked and redesigned an embedded network analysis and packet dumping tool, I did not change one letter in the name. I gave it a completely different name, and credited the original author, even after 95% of the original code was changed.<p>The purpose was twofold: 1) respect to the original author whose ideas and work made it easy for me to attempt this project, and 2) I didn't want my bastardized horrible code to reflect on the original project or cause confusion.<p>Curl is the most widely used HTTP request tool outside of a browser. Calling your fork of it "crurl" is like forking "Linux" and calling it "Linox". This is a dick move.
The stated reasoning behind this seems pretty vague to me, and this follows an increasingly common business pattern in the software industry: clone or fork an existing free software solution, and then fund it massively so that it pulls ahead of the original free software.<p>In the most extreme cases, i.e. FreeBSD->MacOSX, the free software is replaced by software under a non-free license. If there is mention of how libcrurl will be licensed, I missed it, but there's actually a subtler attack on free software which has happened with i.e. GCC->Clang or Konqueror->Safari/Chrome. What makes this attack subtle is that it allows companies to release under a free license, while not actually making any commitment to a free ecosystem. By providing massive amounts of funding and manpower to these projects, large companies can ensure that their version of the software remains dominant, and they get to choose what to include and exclude. This has predictable results: breaks in support for related free software[1] and pressuring the introduction of non-free components even in otherwise free browsers[2] after people have committed to the new, corporately-controlled platform.<p>As noted, I don't know what license this will be released under, or how this power will be used if they supersede the original curl tool. I'm just saying that projects like this should be seen as attacks on free software and viewed with suspicion.<p>[1] <a href="https://bugs.kde.org/show_bug.cgi?id=365327" rel="nofollow">https://bugs.kde.org/show_bug.cgi?id=365327</a><p>[2] <a href="https://blog.mozilla.org/blog/2013/10/30/video-interoperability-on-the-web-gets-a-boost-from-ciscos-h-264-codec/" rel="nofollow">https://blog.mozilla.org/blog/2013/10/30/video-interoperabil...</a> (note: OpenH264 is free as in beer not free as in freedom, a.k.a. gratis not libre).