(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)
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.
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.
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.
"Crurl" is in "rural juror" territory.
Simple names in the era of the web are not always a good idea. Also see https://www.r-project.org/
See also - Rust
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.
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.
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.
Wait, this makes more sense if I do it for chat systems. Google loves making chat systems.
But I reserve the right to be mightily annoyed by the confusion that any partial implementation of the library and CLI tool will cause.
I didn't try very hard, but I couldn't find a "curl" trademark here for software:
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.
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".
Not true. Unregistered marks can still be defended (it's just harder).
That's why there's both ™ and ® symbols. Trademark and Registered Trademark.
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'd say the name is definitely too close for comfort.
Will the suggestion be a) you switched the 'r' and 'u' and get libcurl, or b) you missed an 'r' and get 'libcrurl'.
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".
I'd guess this bug is more about making it easier to use from C.
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.
Although, having a usable QUIC library and/or adding it to libcurl would have been less controversial.
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]
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.
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.
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 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.
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.
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.
Please rename your library.
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.
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> wget https://example.com
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.
> A new chemistry search engine has been forced to change its name from ’Chmoogle’ to ’eMolecules’ following pressure from the search engine Google.
But if you mess with someone's actual products that make them money you'd probably hear from their legal team.
"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!"
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.
mcake knead && mcake bake
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.
Whereas your make examples are much easier to visually differentiate.
If curl was trademarked then they would have a strong case here.
Which clearly reads as "the g(oogle) implementation of libcurl"
In any case I admire curl has a binary size of ~1MB, which is 1/5 the size of my filter list for Chrome.
Pros: main class c'tor could be called TrurlTheConstructor
Cons: everything else
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 and pressuring the introduction of non-free components even in otherwise free browsers 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.
 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 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 :)