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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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].
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.
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"
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.
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.
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.
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.
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)
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.
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.
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.
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 :)
#/media/File%3AUnix_timeline.en.svg){kind=link}