Deno vs. Oracle: Canceling the JavaScript Trademark(deno.com)
deno.com
Deno vs. Oracle: Canceling the JavaScript Trademark
https://deno.com/blog/deno-v-oracle
31 comments
Claim #2 is particularly egregious. If it actually has merit, and if a judge is willing to hold a large corporation accountable for breaking the law (lol), someone at Oracle needs to be charged and prosecuted for it.
jail is for us peasants. the corporation will likely have to pay a fine & lose the trademark if found guilty.
[deleted]
Related:
Oracle, it's time to free JavaScript (277 points, 70 days ago, 127 comments) https://news.ycombinator.com/item?id=41557383
Deno is filing a USPTO petition to cancel Oracle's JavaScript trademark (7 points, 3 days ago) https://news.ycombinator.com/item?id=42212949
Oracle, it's time to free JavaScript (277 points, 70 days ago, 127 comments) https://news.ycombinator.com/item?id=41557383
Deno is filing a USPTO petition to cancel Oracle's JavaScript trademark (7 points, 3 days ago) https://news.ycombinator.com/item?id=42212949
Can anyone speak to whether this is likely to succeed on its merits, or point to analysis of same by competent professionals?
Obviously, it looks like a pretty egregious case of Oracle-ness, but it's the job of Deno's lawyers to make it look like that. I'd be interested to see disinterested commentary.
Obviously, it looks like a pretty egregious case of Oracle-ness, but it's the job of Deno's lawyers to make it look like that. I'd be interested to see disinterested commentary.
I just started following a show on twitch called the litigation disaster tourism hour which is a lawyer commenting on various cases, and currently covering the WordPress stuff. Seems like it might be up his alley if somebody asks in his chat, though I generally can't catch it live to do that because of time zones
JavaScript is of no use to anyone, everyone has been using JS for a long time - it's simpler, more understandable, more convenient. All activists can call their standards and conferences "JS Conf", "JS Specification" without any problems. What, for example, is wrong with the name "Rust for JS Developers"?
As many people know, there are one-letter names of programming languages, why not a two-letter one? By calling the language JS, we remove the unnecessary association with Java, to which the language had and has no relation + we stop emphasizing the derogatory "Script".
And anyway, who cares what the programming language is called? Is it really the general public?)))
I don't think the community needs to fight and defend the name JavaScript - it's an extremely unfortunate name that is not worth the effort. This energy is worthy of a better use.
As many people know, there are one-letter names of programming languages, why not a two-letter one? By calling the language JS, we remove the unnecessary association with Java, to which the language had and has no relation + we stop emphasizing the derogatory "Script".
And anyway, who cares what the programming language is called? Is it really the general public?)))
I don't think the community needs to fight and defend the name JavaScript - it's an extremely unfortunate name that is not worth the effort. This energy is worthy of a better use.
Didn't know about Oracle using Node as an example of them building/selling things utilizing the "JavaScript" trademark. I think the post's framing of this being fraudulent is accurate, but even if it didn't legally qualify, it is at the very least extremely dishonest and unethical.
It soo easy for Oracle to be a hero here. They can win so much by just releasing the name.
Oracle is the kind of company that would understand that and then do the opposite purely for spite.
When I hear "Oracle", the last thing that comes to mind is "Heroes". But then again I've been through this industry a long time, new gen might see it differently.
Well, no, still, acquiring names and doing nothing with them but cockblocking the industry, to then releasing them is not a hero move, regardless of the era.
Well, no, still, acquiring names and doing nothing with them but cockblocking the industry, to then releasing them is not a hero move, regardless of the era.
As far as I know, the creator of Deno, Ryan Dahl, posted on his personal website about that trademark two years ago: <https://tinyclouds.org/trademark>.
Oracle remains silent.
Oracle remains silent.
Oracle's only customer for the first three years of its existence was the CIA. There are no heroes there.
This is either for the greater good of the whole JavaScript community or a PR stunt to just get in the news. Or both.
even if it's a PR stunt, it's good thing if JavaScript becomes free
GraalJs, it would seem, would count.
It’s not “obscure” or “exotic;” at least, no more than Node was when it was released. Honestly this is such a lame take to those of us who are working in JS outside of Node and Deno.
And people do work at that intersection.
IMO Deno is the worst option of all new JS runtimes and taking on this fight kind of makes sense that way. If you can’t win mindshare, start a fight. I guess. (In my opinion they should have simply designed Deno to be NPM compatible, but here we are.)
And people do work at that intersection.
IMO Deno is the worst option of all new JS runtimes and taking on this fight kind of makes sense that way. If you can’t win mindshare, start a fight. I guess. (In my opinion they should have simply designed Deno to be NPM compatible, but here we are.)
Deno is NPM compatible
Only recently... and yes, to Deno's great credit. Deno has an amazing team and this isn't commentary about their hard work; just disagreement with one of the early decisions.
`is:open is:issue label:bug label:"node compat"` -> 203 issues currently open.
Neat. But for a relevant query, try searching for "npm" instead. 0 issues listed. Further, in the `deno_npm` repo for npm resolving by the deno cli, there are two open issues. One is a feature request, and the other is not clearly an important issue.
> Neat. But for a relevant query, try searching for "npm" instead
`is:issue is:open npm` 467 open
https://github.com/denoland/deno/issues?q=is%3Aissue+is%3Aop...
`is:issue is:open label:bug npm` 199 open
https://github.com/denoland/deno/issues?q=is%3Aopen+is%3Aiss...
For the record, "NPM compat" probably does include many feature requests (legitimately), not just bugs.
`is:issue is:open npm` 467 open
https://github.com/denoland/deno/issues?q=is%3Aissue+is%3Aop...
`is:issue is:open label:bug npm` 199 open
https://github.com/denoland/deno/issues?q=is%3Aopen+is%3Aiss...
For the record, "NPM compat" probably does include many feature requests (legitimately), not just bugs.
I did make a mistake. Thanks for pointing that out.
However, the point that deno is npm compatible is still true, contrary to what you originally said.
However, the point that deno is npm compatible is still true, contrary to what you originally said.
Deno is probably not "fully" NPM compatible, arguably, because you still need to prefix imports with "npm:" in a lot of cases. I've filed PRs to that effect, is why I know -- a breaking change for many widely-deployed libraries that need to maintain older node compat. That should not be necessary for a runtime that is "fully" NPM compliant.
Aside from that, Node compliance is a much larger ball of wax than simple NPM compliance, and as far as I know Deno is not there and will not be there for some time.
My gripe with Deno is the choice to hard-fork. That is core to the idea; so, we will disagree. No big deal. As a result of Deno's choice, people now have many runtimes to choose from: Bun, LLRT, and the one I have written on top of GraalJs, Elide. Many others, too.
Most of these runtimes shoot for as full NPM / Node compat as they can muster without intolerable contortions in the code. Why? Because a ton of software out there runs on NPM, or on Node APIs. Users think of server-side JavaScript and Node as the same thing -- this is not true, Node is both the "Node APIs" and the V8-based engine underneath it.
But this is exactly what I mean: for Deno to claim that Oracle does not "use" the JavaScript trademark requires a completely ignorant stance about technologies like GraalJs. Last we benched, Elide (on top of GraalJs) outperformed Deno by a wide margin. Oracle has invested years of engineering work into it. Enough that it outperforms Node (by a long shot) and Deno, and typically ties with Bun. So why does Deno get to say what happens with the trademark? It makes no sense to me.
I might even agree that Oracle should not own it or control it the way they do. I don't know. But I do know that Deno's demands are Node-centric, and the JavaScript ecosystem is simply way bigger than that.
Aside from that, Node compliance is a much larger ball of wax than simple NPM compliance, and as far as I know Deno is not there and will not be there for some time.
My gripe with Deno is the choice to hard-fork. That is core to the idea; so, we will disagree. No big deal. As a result of Deno's choice, people now have many runtimes to choose from: Bun, LLRT, and the one I have written on top of GraalJs, Elide. Many others, too.
Most of these runtimes shoot for as full NPM / Node compat as they can muster without intolerable contortions in the code. Why? Because a ton of software out there runs on NPM, or on Node APIs. Users think of server-side JavaScript and Node as the same thing -- this is not true, Node is both the "Node APIs" and the V8-based engine underneath it.
But this is exactly what I mean: for Deno to claim that Oracle does not "use" the JavaScript trademark requires a completely ignorant stance about technologies like GraalJs. Last we benched, Elide (on top of GraalJs) outperformed Deno by a wide margin. Oracle has invested years of engineering work into it. Enough that it outperforms Node (by a long shot) and Deno, and typically ties with Bun. So why does Deno get to say what happens with the trademark? It makes no sense to me.
I might even agree that Oracle should not own it or control it the way they do. I don't know. But I do know that Deno's demands are Node-centric, and the JavaScript ecosystem is simply way bigger than that.
I think the history, causes, and goals here are getting a bit wobbly. Ryan has been outspoken about what he thinks he did wrong with Node and why he decided to make Deno. I'm obviously not him, so I can't speak much about all of that.
Node compatibility is interesting because it's only useful until it's not. If all these other runtimes eat away enough at node's share, it won't make sense to be compatible with node anymore.
Just to finish the original discussion, as much as I love talking about the current state of js (heh) runtimes: the mention of graaljs supports deno's argument. Oracle, for whatever reason, used "js" rather than "JavaScript".
Node compatibility is interesting because it's only useful until it's not. If all these other runtimes eat away enough at node's share, it won't make sense to be compatible with node anymore.
Just to finish the original discussion, as much as I love talking about the current state of js (heh) runtimes: the mention of graaljs supports deno's argument. Oracle, for whatever reason, used "js" rather than "JavaScript".
GraalJs is just a name. It was created by Oracle so they can use the trademark if they want to. I have no idea what you are talking about.
> Ryan has been outspoken about what he thinks he did wrong with Node and why he decided to make Deno
Yes, I explained that we disagree. Clearly he also feels he was wrong about Deno’s NPM choices since he reversed course and added NPM support. So Ryan agrees with me, I guess.
> If all these runtimes eat away enough at node’s share
WinterCG and other efforts are formalizing APIs that can be shared across runtimes. Which is great. Many of these APIs are at least informed by, if not outright standardized versions of, Node APIs. They are here to stay.
> Ryan has been outspoken about what he thinks he did wrong with Node and why he decided to make Deno
Yes, I explained that we disagree. Clearly he also feels he was wrong about Deno’s NPM choices since he reversed course and added NPM support. So Ryan agrees with me, I guess.
> If all these runtimes eat away enough at node’s share
WinterCG and other efforts are formalizing APIs that can be shared across runtimes. Which is great. Many of these APIs are at least informed by, if not outright standardized versions of, Node APIs. They are here to stay.
Good luck
[deleted]
[deleted]
freejs(1)