
Google to Reimplement Curl in Libcrurl - Leace
https://daniel.haxx.se/blog/2019/06/19/google-to-reimplement-curl-in-libcrurl/
======
jkaplowitz
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.)

~~~
mijoharas
While that may be the case, given that he says they are _morally_ within their
rights to do it implies that he won't want to consider a trademark dispute.

(Also, just to point out, lawyers cost money, and I wouldn't want to pick a
fight with Google's lawyers if I didn't have to)

~~~
jkaplowitz
He may have been considering just the moral rights to fork and ship a
derivative, not the confusing naming which he called out himself in the
article. But indeed it's possible he doesn't care about sustaining or
enforcing the curl trademark. Or he didn't know how the trademark laws can
still apply without a formal registration.

And you're right, Google legal is not easy to go up against. But maybe they
haven't yet been consulted on this plan and would agree with a politely but
firmly worded letter from him on the naming question specifically. The
original public source of these Google plans is merely an issue in the
Chromium bug tracker, not yet a fully vetted blog post or press release.

~~~
mijoharas
That's a very fair point.

Though it would probably be prudent to try sending an email with "hey, do you
mind changing your name to something else" first.

Then again, given the article and a bit of HN Buzz, that may already be
happening.

Definitely worth you pointing out the rights that the author likely has in the
comments though.

~~~
signal11
I wish Google learned from Go/Golang (i.e., where a nontrivial number of
people refer to Go as Golang, much to the displeasure of some of the authors)
and use names which are easy to search for.

I'm not looking forward to people mistyping libcrurl as libcurl and people
having to second guess what the intention was.

curl might not be a trademark but EU has 'moral right of the author' rules. In
my mind libcrurl is right up there with a search engine named G00gle or a
software company named MikeRowSoft.

~~~
bsg75
> where a nontrivial number of people refer to Go as Golang

[https://golang.org/](https://golang.org/)

Simple names in the era of the web are not always a good idea. Also see
[https://www.r-project.org/](https://www.r-project.org/)

~~~
signal11
Sadly, there’s a fair amount of sniping[1] in parts of the Go community if you
use “Golang” instead of “Go”.

[1]
[https://news.ycombinator.com/item?id=18717303](https://news.ycombinator.com/item?id=18717303)

------
willnorris
Hey, Will from Google's Open Source Office here.

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.

This project is still very experimental in nature (as discussed at
[https://bugs.chromium.org/p/chromium/issues/detail?id=973603...](https://bugs.chromium.org/p/chromium/issues/detail?id=973603#c4)),
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.

To make things clearer, the team is renaming the project, and adding some more
docs outlining the goals and intent of the project: [https://chromium-
review.googlesource.com/c/chromium/src/+/16...](https://chromium-
review.googlesource.com/c/chromium/src/+/1652540)

------
glenndebacker
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.

~~~
kalleboo
Googling for "libcrurl" currently gives you a "results for _libcurl_ " as an
autocorrect. If Google succeeds you'll get the opposite.

I'd say the name is definitely too close for comfort.

~~~
Phemist
It would be interesting to keep track of what the results will be in several
search engines across time when you type:

'libcrul'.

Will the suggestion be a) you switched the 'r' and 'u' and get libcurl, or b)
you missed an 'r' and get 'libcrurl'.

------
bla3
[https://groups.google.com/a/chromium.org/forum/m/#!topic/chr...](https://groups.google.com/a/chromium.org/forum/m/#!topic/chromium-
dev/0TmXyy_G9_o) 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.

~~~
CydeWeys
Ouch, that's a rough start to an internship, being called out on the front
page of HN like this.

~~~
lallysingh
It'll make for great fodder in their YC application

------
skybrian
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++.

I'd guess this bug is more about making it easier to use from C.

[https://developer.android.com/guide/topics/connectivity/cron...](https://developer.android.com/guide/topics/connectivity/cronet)

[https://medium.com/@cchiappini/discover-
cronet-4c7b4812407](https://medium.com/@cchiappini/discover-
cronet-4c7b4812407)

------
Daemon404
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.

Doesn't make it a good look, though.

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.

~~~
shereadsthenews
It sound to me more like they want an easy way to exercise QUIC.

~~~
Daemon404
Possibly, yes.

Although, having a usable QUIC library and/or adding it to libcurl would have
been less controversial.

------
lallysingh
Woah, I feel like this is all blown out of proportion.

AFAICT, nobody's actually trying to replace the curl that people will have
installed on their workstations or laptops.

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.

I don't think the authors are trying to replace curl, as much as imitate it
for a development utility.

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.

[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]

~~~
consp
> I think the name was chosen only to indicate how it should be used ("like
> regular curl")

Or, like my colleague just suggested: to improve typesquating in search
results. Considering it is both a Google thing and as mentioned before an
internship both are likely.

------
shereadsthenews
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.

~~~
jonathanyc
Interns at Google (and other large companies) almost never come up with their
own projects. Rather they choose from a list created by their manager and
their manager's manager, typically from a grab bag of smallish projects that
were already on the roadmap. Whether or not there is malice (or just
impoliteness) in this, dismissing people's concerns about _Google_ because
libcrurl is just "the plans of an intern" is a non sequitur.

------
Sir_Cmpwn
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.

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.

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.

------
tyingq
Somewhat related, the reason curl is called curl: [https://ec.haxx.se/curl-
name.html](https://ec.haxx.se/curl-name.html)

~~~
mxuribe
Thanks; i always love reading little nuggets like this!

~~~
jordigh
Boy do I have the page for you...

[https://wiki.debian.org/WhyTheName](https://wiki.debian.org/WhyTheName)

------
AdmiralAsshat
"libcrurl" seems tailor-made to cause confusion.

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.

Suggestions:

\- libcoil

\- libtwist

\- libcrimp

\- libswirl

------
pdkl95
> pretty strong indication that their API will not be fully compatible

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.

However,if the incompatibility is from an _extension_ of the API introduced
after initially _embracing_ the _de facto_ 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.

[1]
[https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...](https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish)

[2]
[https://web.archive.org/web/20140222133423/http://www.networ...](https://web.archive.org/web/20140222133423/http://www.networkworld.com/news/2000/0511kerberos.html)

------
klagermkii
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.

~~~
skybrian
Yes, I'm guessing Google would want to get all their HTTP-using apps switched
over to QUIC (and adopting any other HTTP-level network improvements they come
up with), so they'd want to encourage at least their own developers to switch
from libcurl to something built on cronet and picking up performance tweaks as
soon as they add them to cronet.

Seems like they should also be helping libcurl itself to keep up with HTTP-
level networking changes though, given all the software built on it.

------
peterwwillis
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.

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.

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.

------
carlsborg
Dear Google Chrome Folks,

Please rename your library.

Thanks

~~~
EwanToo
libcrurl vs libcurl, I know naming things is hard but this just seems hostile
against the Curl developer.

~~~
jsty
Admittedly they're a little hard to differentiate at first glance, but is
'hostile' not pushing things a little too far? There's a long history of
derivatives of open source tools having similar-ish names, often differing by
a single letter - just look at all the 'make' derivatives: pmake, bmake,
fmake, gmake, rmake, nmake, ... to name but a few that Wikipedia mentions [0].

[0]
[https://en.wikipedia.org/wiki/Make_(software)#Derivatives](https://en.wikipedia.org/wiki/Make_\(software\)#Derivatives)

~~~
EwanToo
If you launched an alternative search engine called Gooogle, I don't think
Google would consider it a friendly move :)

~~~
jsty
Very true. I probably should've caveated that I don't actually think it's a
good name choice, just that I doubt it was chosen to mislead / as an attack on
(lib)curl. Given my own uselessness with naming things sometimes, I tend to be
forgiving!

~~~
Spivak
Like we're talking about software developers here. I think it's funny that
when a Google engineer does it there's some shadowy motivation to usurp a FOSS
downloader library -- like they aren't like the rest of us picking silly names
for things.

"Hey, curl is a super useful tool, it would be nice if it used our new fancy
network protocol"

"Yeah, what should we name it?"

"Uhh -- wait, I got it. crurl and the library could be libcrurl"

"Hilarious! It's perfect!"

------
ptah
Embrace, Extend and Extinguish

------
tempodox
A Google-copyrighted network library will make sure that Google users will
only see Google-authorized parts of the Internet.

------
kerkeslager
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.

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.

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.

[1]
[https://bugs.kde.org/show_bug.cgi?id=365327](https://bugs.kde.org/show_bug.cgi?id=365327)

[2] [https://blog.mozilla.org/blog/2013/10/30/video-
interoperabil...](https://blog.mozilla.org/blog/2013/10/30/video-
interoperability-on-the-web-gets-a-boost-from-ciscos-h-264-codec/) (note:
OpenH264 is free as in beer not free as in freedom, a.k.a. gratis not libre).

~~~
693471
I don't think you understand the relationship between FreeBSD and MacOS

~~~
codezero
Just to save the GP a google search:
[https://en.m.wikipedia.org/wiki/Darwin_(operating_system)#/m...](https://en.m.wikipedia.org/wiki/Darwin_\(operating_system\)#/media/File%3AUnix_timeline.en.svg)

~~~
kerkeslager
Perhaps you should read the actual article for the image you linked, which
mentions that Mac OS was synchronized with FreeBSD in 2003. The fact that this
gets a one-line mention shouldn't be mistaken for belittling the effort
involved in feature-syncing a mature operating system.

I wasn't sure of my memory, so I had checked my FreeBSD statement before I
said it.

~~~
codezero
Thanks for pointing this out, a bit more detail about the shared code is here:
[https://en.wikipedia.org/wiki/XNU](https://en.wikipedia.org/wiki/XNU)

I did read the article, but "BSD layer synchronized with FreeBSD 5" somewhat
late in the project didn't itself give me the impression it was derived from
work in FreeBSD. That said, I appreciate the poke to go do some more work :)

