Google to Reimplement Curl in Libcrurl | Hacker News Reader

Google to Reimplement Curl in Libcrurl

daniel.haxx.se

281 pointsLeace118 comments

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

Given that it's his trademark, it seems like he has no interest in enforcing such rights.

I thought it was more or less required to defend your trademark, else you could loose it.

That's true. But he's allowed to choose to lose it, or to discuss with Google and grant a trademark license.

He also needs to have registered it in the first place. Trademarks are not automatic like copyright is.

I didn't try very hard, but I couldn't find a "curl" trademark here for software:

http://tmsearch.uspto.gov/bin/gate.exe?f=tess&state=4808:iz1...

Sort of. The USA you can claim trademark rights without a registered trademark; that's the difference between ™ and ®.

But the law follows "use it or lose it" rules. If you don't defend your trademark, then in the eyes of the court it is no longer a trademark.

Hold on, that's "defend it or lose it". Author of libcurl clearly is using the name, there are new releases coming out quite often.

My wording was unclear, yes. If you aren't defending it, you aren't using it as a trademark.

Think of the term literally; if it's not exclusive to you, it's not longer a "mark" of your specific "trade". It's just a "mark".

Fair enough.

>He also needs to have registered it in the first place.

Not true. Unregistered marks can still be defended (it's just harder).

That's why there's both ™ and ® symbols. Trademark and Registered Trademark.

But why would he want to protect himself from Google picking a confusing name for _their_ software?

So that he doesn't get the bug reports, feature requests, user support requests, or any reputational problems that stem from Google's confusingly named release.

Just to add to that, since libcurl is used everywhere, he gets all sorts of strange messages:

https://daniel.haxx.se/blog/2016/01/19/subject-urgent-warnin...

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)

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.

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.

Yes, an informal first approach is generally best, agreed. My suggested trademark lawyer consultation was not meant to bypass that, but merely to advise on it and to assist with any subsequent steps that the situation may merit.

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.

EU rules aren't the only relevant ones, either. They are certainly among the relevant ones since the curl author is in Europe, but Google has enough ties to the US that he can probably benefit from whichever set of trademark laws are more favorable. And US laws recognize unregistered trademarks too.

For whatever reason, "alternative" languages seem to have weird naming issues.

See also - Rust

C, D, and C++ on the other hand... And the naming of JavaScript had certainly never caused any confusion. Let's face it, programming languages have weird names.

There is a non trivial overlap between the people present for the creation of C (which followed B) and the creation of Go - so there may have been something weird in the water at Bell Labs sometime around 1980. D just followed the existing convention and C++ started out as an extension on top of C.

JavaScript on the other hand was an entirely intentional marketing move. Only issue was that the programmer they hired to create the language wasn't on the Java hype train.

Your point is very valid, but I cant even SAY it, so I havent even gotten to the typo stage.

"Crurl" is in "rural juror" territory.

"Searching for libcrurl. Click here if you really meant libcurl."

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

https://golang.org/

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

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

He's going to have a hard time against google for the trademark after not fighting MS for aliasing invoke-webrequest by default in powershell.

In order to claim a trademark you need to actively enforce it. That is, a defense for trademark infringement is 'but they allowed X to infringe it to'. Hence, their might be a reason to dispute this just to preserve the trademark.

Popular misconception.

Allowing someone to do something means there is estoppel (my explicit action to let you do X is considered in law to prohibit me later going after you for doing X even if you'd otherwise have no right to do it) but doesn't magically abolish my right to forbid others.

Claims require that you actively use the mark, if you last sold Rocqua brand hats in 1987, your claim against me for using that mark in 2019 won't work, but they don't require you go around suing or even threatening to sue anybody. That's just lawyers getting themselves a few extra bucks off the unenlightened, mixed with people who want an excuse for behaving badly.

It doesn't magically abolish your right, but it is evidence against you if a competitor actively and overtly uses your mark and you don't enforce it even to the level of writing to them seeking a rename or a license.

Not only is there a risk of estoppel (probably not if they can't show anything explicit or intentional by you), even other competitors can point to your willful inaction in support of their argument to a judge that your trademark has become generic.

As noted above, I'm not a lawyer or giving specific legal advice here, but I have worked with lawyers in dealing with trademarks.

Agreed. I think the fact that Google would not tolerate a company who picked off gooogle.com, googel.com or any other TLDs that would impinge on their brand, yet someone at Google has decided they have the flex to do something Google itself (legal) would not tolerate.

I think you're right. Presenting it as a moral matter may be a signal that he's not looking to pick the legal fight but take matters up in a more public social court, if you will.

Btw, gooogle.com isn't a TLD. com is a TLD, gooogle.com is just a domain (sometimes called a second-level domain, but--eh).

It harkens back to when they stomped on the original go language with thoughtless naming

Issue 9, never forget:

https://github.com/golang/go/issues/9#issuecomment-66047467

That hurts to read.

I'm going to start squatting programming language names with lisp dialects. I'll demand extensive lip service and Google Summer of Code resources every time they stomp on one.

Wait, this makes more sense if I do it for chat systems. Google loves making chat systems.

If the creator of curl doesn't consider this to be morally grey action by Google, I won't argue (though I do disagree).

But I reserve the right to be mightily annoyed by the confusion that any partial implementation of the library and CLI tool will cause.

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...), 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...

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.

That's what I read too and felt my brain break momentarily.

I misread it, too. Ir's actually L-i-b-c-r-u-r-l.

I misread the new name as "libcruel".

while libgurl would have been so fit

I only read the title, not the article, and I had to scroll back to the top after reading your comment. Got fooled as well.

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.

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

I had to re-read the title maybe 5 times before I got it, so I can definitely agree with your sentiment. The repetition of the "r" is definitely easy to miss.

I know that naming stuff is hard and I'm definitely pretty bad at it but when you're working at Google or some other tech giant I think you should have the elegance of being a bit more thoughtful with that stuff. I predict that it's going to make it significantly more painful to... google for libcurl in the future.

I invite the libcurl folks to name their next project "groogle".

https://groups.google.com/a/chromium.org/forum/m/#!topic/chr... 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.

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

It'll make for great fodder in their YC application

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://medium.com/@cchiappini/discover-cronet-4c7b4812407

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.

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

Possibly, yes.

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

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]

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

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.

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.

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.

Somewhat related, the reason curl is called curl: https://ec.haxx.se/curl-name.html

Thanks; i always love reading little nuggets like this!

Boy do I have the page for you...

https://wiki.debian.org/WhyTheName

Link appears to be dead?

"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

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

[2] https://web.archive.org/web/20140222133423/http://www.networ...

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.

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.

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.

Dear Google Chrome Folks,

Please rename your library.

Thanks

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

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

At least those all have the decency to be prefixes. Those are much easier to parse.

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

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!

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!"

Case in point from 2006 - https://www.chemistryworld.com/news/google-chmoogle/3001845.... :

> A new chemistry search engine has been forced to change its name from ’Chmoogle’ to ’eMolecules’ following pressure from the search engine Google.

We're talking about two categories of people. The software developers would have no problem with stuff like this. Go ahead and create a UX toolkit called Fluttershy.

But if you mess with someone's actual products that make them money you'd probably hear from their legal team.

If not for Google's recent spate of scraping people's stuff and publishing it verbatim with zero attribution, they'd get the benefit of the doubt regarding maliciousness. See genius.com's recent accusations

The smell like some "developer's developer" who thinks he can do a better job of libcurl and is so cocksure that he's going with the name libcrurl. Perhaps he'll put his name on it. Unlikely, as that would require skin in the game.

Neither of those make derivatives has a likelihood of being readably confused with the original similar to the libcurl/libcrurl comparison.

Prefixing a word with another letter is perceptually different from slipping one in the middle, especially when the new letter is one of the four letters already in the name. What Google has done here would be more comparable to releasing a new utility called 'mkake'.

As the author of curl points out, it just looks like a typo. When it's this egregious, your only choices are to assume either incompetence or bad faith.

I mean don't think for a second that mcake couldn't be the name of a build utility that uses baking terms.

    mcake knead && mcake bake

Then Google should follow that pattern and call it glibcurl

Which clearly reads as "the g(oogle) implementation of libcurl"

It could easily be mistaken as a GNU implementation (ref glib, gmake, etc).

Fair. But crurl is something my auto-correct extensions would assume I fat fingered.

In your examples the first letter is different, the names do not suffer of the confusion issue, me and other people read the name wrong(our eyes or brain tricked us)

crurl and libcrurl look almost visually identical to curl and libcurl - to the point that many on HN genuinely misread Google's names to be their original counterparts.

Whereas your make examples are much easier to visually differentiate.

If curl was trademarked then they would have a strong case here.

Slightly different in that case that they're introducing a new different letter at the start. What if I called my tool mmake, or mkake?

Chrome and curl seem like competing products. But I agree. I don't see this as that bad relative to the other things they're doing at the moment (i.e. breaking uBlock, user agent blocking).

In any case I admire curl has a binary size of ~1MB, which is 1/5 the size of my filter list for Chrome.

Could be worse - like when MS added curl as a powershell alias. https://github.com/PowerShell/PowerShell/pull/1901

Windows 10 builds have included a 'real' curl for about a year now (build 1803 onwards IIRC)[1]

[1] https://daniel.haxx.se/blog/2018/01/13/microsoft-curls-too/

Just to reiterate- in Windows 8/Server 2012 (PS ~3-5), writing "curl" would just alias to "Invoke-WebRequest". Prior discussion from 2016 on hn[0].

But since December 2017, Windows 10 build 1803 includes curl.exe (along with ssh!) These deprecated my use of chocolatey, and hopefully moves people away from Putty.

[0] https://news.ycombinator.com/item?id=12319670

I really don't see what all the drama was over. Those aliases are incredibly valuable to me. I can never remember the PS equivalents of unix-y commands and those aliases let me use my current muscle memory.

Sure the options are different but it's really not all that different than switching between GNU/Linux, MacOS, and BSD and having to deal with differences.

    PS> cd C:\Users\
    PS> ls
    PS> wget https://example.com

And it makes discovery super easy when you can Get-Help just about every unix command and it will show you more-or-less the appropriate equivalent. The thread just looks like a bunch of people with a bone to pick against MS trying to take some moral high-ground with a change that was added to genuinely help users.

don't assume malice when "we suck at names and the first dumb name seems to stick without a marketing department overriding the naming choice" is also an option.

Marketing is busy branding the next 5 years worth of annual messaging applications.

A company I once worked for spent $40,000 to find a good product name. It ended up being the same name people had already pitched for free internally.

They missed a trick by not naming it libgurl.

How about libcruel - Chrome reimplementing usable external libraries

Or libcrocurl and crocurl. Lots of better options.

libchrurl

It's visually more distinct than libcrurl while retaining an appropriate resemblance to libcurl.

One could argue that some resemblance in name is a good thing for curl. But libcrurl is too close and likely to cause confusion.

Is it too late for them to name it “Goorl”?

LibGurgurl

libcruller is available, is close enough to be clearly related and far enough away not to look like a typo. Also … mmm, tasty crullers.

Propose LibTrurl

Pros: main class c'tor could be called TrurlTheConstructor

Cons: everything else

How about "gurl" or "gurgle"?

It's doubly egregious given they work for a search engine that will immediately try to autocorrect that.

It'll be even worse when the search engine later magically ranks their's higher even when searching for the original.

The irony is when I've searched for "libcrurl" using Google, I got the result for "libcurl".

Of course it should be renamed to libdivergence. But joking aside, is "crurl" even a word after all?

and lets not be clever, if its a libcurl api for this cronet thing, call it cronet-libcurl or libcurl-cronet or something

on it: https://news.ycombinator.com/item?id=20228237

Embrace, Extend and Extinguish

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

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

[2] https://blog.mozilla.org/blog/2013/10/30/video-interoperabil... (note: OpenH264 is free as in beer not free as in freedom, a.k.a. gratis not libre).

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

Just to save the GP a google search: https://en.m.wikipedia.org/wiki/Darwin_(operating_system)#/m...

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.

Thanks for pointing this out, a bit more detail about the shared code is here: 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 :)

Reply on news.ycombinator.com