Hacker News new | past | comments | ask | show | jobs | submit login
A notable JavaScript developer shamelessly copied one of my most downloaded nod (twitter.com/jorgebucaran)
291 points by todsacerdoti 20 days ago | hide | past | favorite | 298 comments



I keep thinking about this event and it seems like a fractal of bizarre phenomena. The act of stripping git history and attribution while forking is itself malicious, but then aggressively creating pull requests across major projects to use the new version and rack up your download count (???), then picking petty fights with the creator of the original over attribution (????), and the fanbase (?????) of the forker dogpiling the original creator (??????) is... what? I struggle to attribute these to normal, healthy motivations. Something is very, very wrong with the JS Open Source community if naked clout chasing like this is not only tolerated but also rewarded with fans!


The absolutely crazy thing is the person who caused this doesn't even think they did anything wrong: https://github.com/babel/babel/pull/13783#issuecomment-92724...

And there are people supporting their position.

I think because JS is such a large tent, there are folks not familiar with licenses and general norms in this space. I don't think it's something that being reasonable and pointing things out wouldn't fix.

As an aside I'm now extremely uncomfortable if I find any of ai's work as a transitive dependency for my company's own work because of their attitude towards adhering to licenses.


> I think because JS is such a large tent, there are folks not familiar with licenses and general norms in this space.

It's worth pointing out that this is all about a bunch of packages that decorate strings with ANSI colour escape sequences... I'm not saying it's worthless, or that there is nothing wrong in principle - but it's a lot of noise over something easily replicable from scratch - something simple enough that you may even choose to not bother with a library, (i've always just used ANSI codes directly in JS command line tools, sometimes defined in a few constants and interpolated for readability).

So perhaps the reason why one author is so pissed at misattribution, and the other allegedly doesn't seem to care much about it, is explained by a large difference in perceived value of the code.

To make my point more potent, imagine it was the same debacle over one of the many infamous one line NPM packages like "is-odd" which currently has half a million downloads per day and ultimately consists of the code "return (n % 2) === 1;"... excluding all of the fluff, and even with some unnecessary parenthesis.


I don't think this is a fair framing. This isn't left-pad - it's a library that abstracts something people find annoying, and finding the right abstraction can be difficult even if the final code doesn't seem complicated. Add in a few years of bug fixes and whatnot, and it seems pretty rude to dismiss the result as "easily replicable from scratch".


I think I made it clear enough that I was suggesting these packages are somewhere above the one-liners. While I agree finding the right abstraction is useful and takes time, I find it hard to apply that to a package that provides a function that wraps strings... I think it's fair to say that it's somewhat useful, but easy to replicate from scratch, and that's ok it deserves to exist - it does however considerably affect how different people perceive it's value.

But perhaps for contrast we should compare to the other end of the spectrum... Intel uses Minix3 in intelME which is part of every modern intel CPU [0]. Minix3 has a 3 clause BSD license which requires reproducing the copyright notice for basic attribution [1]. Which they failed to reproduce. Now in Tanenbaum's public letter, he politely suggested it would have been courteous if they had merely informed him of what it was being used for [2]... no mention of lack of attribution, no hysteria, no invoking of the mob on twitter, he didn't make even 1/10th the fuss this NPM package developer made.

Lets cut to the chase: The difference between these two people is that one cares about attribution way more than contributing to FOSS. They care about it to such a degree that makes me uncomfortable to touch their code, in-case of any perceived injustice against them or missed opportunity for self-promotion.

[0] https://en.wikipedia.org/wiki/Intel_Management_Engine#Hardwa...

[1] https://github.com/minix3/minix/blob/master/LICENSE

[2] https://www.cs.vu.nl/~ast/intel/


The difference is that someone pirated another person's software and tried to get away with it. Then that person's fan club wrote a bunch of nonsense to distract, deflect and cloud their malfeasance.

Attribution may not be a concern for career criminals but FOSS tries to stay on the side of the law. Otherwise, projects risk being "tainted" by copy-pasted code that could lead to even larger legal repercussions. ReactOS had its development shut down in 2006 because of mere allegations; they had to prove all their code was written by themselves

https://reactos.org/project-news/reset-reboot-restart-legal-...


wow... listen to yourself, this is FOSS, we aren't the MPAA. You are just banging the drum louder for the OP, nothing to do with what I said at all.


If you don't care about software licenses or attribution, then you're not apart of FOSS. Sorry, Tom


I think it's worth pointing out that these pull requests replace a totally unrelated package with either one of these two packages that claim to be copying each other.

The way it was framed was that someone forked a packaged and started replacing all users; not what happened.

Also: I don't even use JS, so, I have no idea who these people or libraries are.


I was replying to GP's suggestion that the argument is over relatively trivial code, not to anything about the core dispute.


There can be a lot of value in value in a code base such as this. Just copy an existing open source lib, add a small speed up, push for fast adoption across common OS build tools, now you can sell committer rights for a high price to anyone wanting to launch a supply chain attack. Could be very profitable.

This is of course unlikely to be ai’s motivation. I just wanted to present a count point to the argument that such modules have low value.


Very true, this is a reason i'm trying to distance myself from the NPM ecosystem actually... It's a cultural problem as much as a technical one, and it is ripe for exploitation... In combination with some of the NPM CVEs revealed in the past, it's pretty scary the reach and potential a single NPM package has for destruction and exploitation... and that is before even considering packages that get included in front and back end code for the web.


I thought it was a joke your is-odd comment. But no it is at version 3.0.1 and has 2.1 million downloads a month[0]... And it has a dependency to is-number. With the performance of today's tree shaking systems I wonder why there is not a simple math lib.

[0] https://www.npmjs.com/package/is-odd


It's pretty crazy. For whatever reason there is a substantial culture around NPM usage of preferring to depend on lots of trivial packages, over writing simple inline equivalents. And it's recursive, which can mean depending on what seems to be a modest but useful package at the top of that hierarchy ends up pulling down 10k packages.

I think this makes it easier to acquire an inflated sense of importance when an authors package reaches popularity - most of the small packages have some value and aren't as ridiculously worthless as "is-odd"; yet they also don't embody anything particularly unique or difficult to replicate.

> I wonder why there is not a simple math lib.

There are some non-standard but comprehensive math libraries such as MathJS. Although I don't think "is-odd" could be attributed to an absence of standard math libraries.


In fairness to the OP he did optimize the hell out of his colorette lib, it's about 1/10th the size of the widely adopted chalk lib and performs way better. Back in the day I remember he was (rightly) complaining that the chalk author submitted PRs to get chalk used in as many libs as possible, while colorette (or whatever it was called--it has a different name before) was the technically superior solution to the problem.


Then he should have made a PR, or at the very least retained the commit history to recognize the original programmer's work. That's non-negotiable, because commit history can be essential to understanding breakage in mature libraries. The fact that anyone would feel comfortable erasing it leads me to believe there's an ulterior motive.


If I understand correctly, the parent is talking about the original author of the library, not the person who forked it.


Yes, this is correct, I was referring to colorette's maintainer. Sorry for confusion.


For what it's worth, this is also all the work of one person who spammed NPM with micropackages to boost his download counts. This meme attacking `npm` for nonsense like `is-odd` is quite literally the result of one person resume boosting.

For every one thing, he broke it down into as many possible packages as possible, and all of his packages depend on 20 more of his packages. It's like a fractal of resume boosting.

https://github.com/jonschlinkert/info-symbol https://github.com/jonschlinkert/success-symbol https://github.com/jonschlinkert/warning-symbol https://github.com/jonschlinkert/error-symbol

My personal favourite is making every single ansi colour into a separate package, and then making `ansi-colors` which depends on all of them, and all of these packages are just a single function call with a provided number. It's honestly insane.

https://github.com/jonschlinkert/ansi-black

https://github.com/jonschlinkert/ansi-reset

https://github.com/jonschlinkert/ansi-bold

https://github.com/jonschlinkert/ansi-dim

https://github.com/jonschlinkert/ansi-italic

https://github.com/jonschlinkert/ansi-underline

https://github.com/jonschlinkert/ansi-inverse

https://github.com/jonschlinkert/ansi-hidden

https://github.com/jonschlinkert/ansi-strikethrough

https://github.com/jonschlinkert/ansi-black

https://github.com/jonschlinkert/ansi-red

https://github.com/jonschlinkert/ansi-green

https://github.com/jonschlinkert/ansi-yellow

https://github.com/jonschlinkert/ansi-blue

https://github.com/jonschlinkert/ansi-magenta

https://github.com/jonschlinkert/ansi-cyan

https://github.com/jonschlinkert/ansi-white

https://github.com/jonschlinkert/ansi-gray

https://github.com/jonschlinkert/ansi-grey

https://github.com/jonschlinkert/ansi-bgblack

https://github.com/jonschlinkert/ansi-bgred

https://github.com/jonschlinkert/ansi-bggreen

https://github.com/jonschlinkert/ansi-bgyellow

https://github.com/jonschlinkert/ansi-bgblue

https://github.com/jonschlinkert/ansi-bgmagenta

https://github.com/jonschlinkert/ansi-bgcyan

https://github.com/jonschlinkert/ansi-bgwhite


Wow, this person's Github about says it all.

> Several years ago I switched careers from sales, marketing and consulting to learn how to program, with the goal of making the world a better place through code. Whether that means giving people access to information, the tools and technology to level the playing field with big corporations, or empowering people in impoverished regions to participate in the world economy.

> To date, I've created more than 1,000 open source projects in an effort to reach my goal.

They're good at marketing, I'll give 'em that.


Wow, that is no joke. ansi-colors relies on ansi-blue, which relies on ansi-wrap and makes a single call to ansi-wrap, providing the constants 34 and 39. It’s a couple dozen packages whose sole purpose is to provide a distributed set of constants. That is pretty blatant. On his bio he boasts about having over 1000 open source projects, and I can’t help but think he could have a few useful ones in there that are overshadowed by this embarrassing display of clout-chasing.


His explanation on Reddit:

"The way I learned how to program was by publishing one project a day that used a specific language feature I was trying to learn. No one even looked at my projects or used them until I had quite a few published. I didn't even want people to use them at that point, since I had no idea what I was doing. Then one day I realized that people were actually using some of the things I published as a learning exercise, and I started going back and fixing and improving that code. Rinse and repeat. That's pretty much all I did.

Why is the default for people to assume the worst all the time? It's depressing as hell."

If true, it's kind of sad so many people badmouth him.


Maybe public common repository shouldn't be used as a dumping ground for every random guy learning how to make their first script. It's a bit like learning to drive by going to a public highway and just starting driving at random directions and then saying "why are you folks screaming? I'm just learning, it's depressing you always assume the worst!"


Ever publish a Java project to Maven Central? It's a massive pain, but it also acts as a bar to make sure you're publishing something of value you think others might use.


Unlike a public highway, you can't actually harm anyone by publishing to a public repository. The code is just there; you can ignore if you prefer (you can't ignore a swerving car in a highway).

What's actually harmful is the blind trust most developers have on adding dependencies without proper vetting. But if someone publishes a package they are not responsible for vetting it for inclusion in your project. So shifting blame to the library author gets responsibilities backwards.

Perhaps you would prefer a curated package registry, but in this case you would need actual curators. Something like Debian has maintainers, but doesn't have every library in existence (and what it has is often outdated anyway). Npm and other language registries aren't curated, by design. You could create a curated registry on top of npm but, again, you need curators.


By publishing one single script - not likely. By publishing 1000 scripts - yes, you can, by polluting the public space and making it so much harder to find real supported code that can be relied upon. It's like throwing garbage on the street. One can won't do much, do it many times - and your neighborhood is a dump.

Same argument as with spam. Sending an email is not a crime, and sending an email to somebody you didn't know to ask them maybe they want to do business with you is not that bad. Do it couple of millions of times, and it breaks the whole system.

> What's actually harmful is the blind trust most developers have on adding dependencies without proper vetting.

Now comes the victim blaming. Nope, the fact the people should verify stuff does not absolve the guilt of those who put garbage into the public space. On the contrary, they are making the problem so much worse. And yes, there are means to deal with the problem, but again "you can clean up" is not an argument that absolves the guilt of somebody who throws trash around. They are doing bad thing, and should feel bad about it.


I have nothing against them as a person - I don't know them at all. However, the ANSI colours one is blatant package-downloads optimisation. Infact, the READMEs were clearly copied and pasted,

> The color reset, in ansi. [1]

> The color strikethrough, in ansi. [2]

etc.

Which don't really make any sense.

[1] https://github.com/jonschlinkert/ansi-reset [2] https://github.com/jonschlinkert/ansi-strikethrough


It sounds like he's just making excuses. If he really thought his contributions were just for learning, he wouldn't be bragging in his bio that he's "created more than 1,000 open source projects". That's like saying "I've written more than a million lines of code" because I copy-pasted one line of code a million times in college.


> I hope he didn't brag about "more than 1,000 open source projects." That number's so large it's a red flag that he's never build anything complex.


It kind of stretches credulity for him to say these are just test projects that he doesn’t want people to use when his profile is bragging about having 1000 open source projects.


Exactly. I almost believed it until I saw shameless self-promotion and soliciting donations under it. I mean I have nothing against people getting paid for their work, especially open-source developers, but you can't both claim you were just learning and didn't expect anything, and use that to brag and solicit donations.


Agree. And also when you publish something on NPM you could expect someone to download it and you would need to maintain it. You cannot say later "Ohh I didn't know or I had no idea".


> I wonder why there is not a simple math lib

This [0] might be what you are looking for, it has both is-number and is-odd.

[0] https://github.com/stdlib-js/stdlib


Am I right that this is the important part of the library?

https://github.com/jorgebucaran/colorette/blob/d1ff3a7/index...

I agree that the author clearly spent a lot of time polishing it, hence the pride and feeling of betrayal.


> The absolutely crazy thing is the person who caused this doesn't think they did anything wrong.

And now he's saying this of the person he took the work from [1]:

1. "I believe he is a good person, but love colorette too much and prefer impulsive actions ... Impulsive behavior can be very dangerous."

2. "Comments like this [https://news.ycombinator.com/item?id=28662796] shows that his behavior in that case was very questionable. Seems like he is systematically put himself in conflicts."

True or not, I find his claims of the victim having impulsive or questionable behavior, and systematically creating conflicts, ironic.

On a more positive note - it looks like both parties are starting to discuss a resolution [1]; maybe even co-maintainership of the original work in question [2]. I personally think that would take a lot of guts, from both parties, given everything that's transpired.

I also think johnnyshields in the linked GitHub thread [1] deserves acknowledgement for some noticeably simple, but effective, attempts at facilitating resolution.

[1] https://github.com/ai/nanocolors/pull/14#issuecomment-927346...

[2] https://twitter.com/jorgebucaran/status/1442055448899641348


GitHub / NPM / Twitter together with the conference scene seem to be leading to some form of insta-gramification of open source and programming in general it seems.

Edit: Maybe HN is to blame as well.


You are right I keep hearing in interviews, videos and blogs people talking about how many stars, please star me etc

There is something of a insane competition going on at various levels, people judging languages by their rank on various sources. Saying a specific language is "winning the race". We all know since the 70s that no language is winning ever. Calm down, code in what you like and people around you can use and understand. Create a new language, have fun... Things in life are not always a competition, you can relax.


I do like releasing everything I develop as FOSS, but we all agree that something like this can happen when we do, even though most of us (me included) find it at least distasteful.

Unfortunately this is what happens when any space gets super-competitive, then some people stop caring about spirits and anything else that's impossible to police in a meaningful way. JS is one of the, if not the, most popular programming language in use and it's incredibly accessible. It'd be (and I say this in the most polite and constructive way I could think of) silly to expect that stuff like this won't happen and that there won't be any group of people even cheering this kind of behavior.

We all seemingly live in bubbles, at some point we have to realize that we have the whole world in front of us in this crazy place called internet. Well, wasn't that the idea behind the "Eternal September"[0]? It'll not get better unless the whole world gets better.

[0]: https://en.wikipedia.org/wiki/Eternal_September


Somewhere around the 2012'ish era, programming attached itself to the "modern" world of politics, political correctness, etc. This was all facilitated through the hard-use of Twitter, an already politically polluted field.

Honestly the best thing you can do is just not use Twitter or Github for social reasons. It's almost a sport at this rate. People trying their best to create drama and false gods. It's almost as bad as LinkedIn.


That's Andrey Sitnik's MO. He's done it before (size-limit vs bundlesize, nanoid). Copy. Tweak. Logo. Repeat. He then goes around opening pull requests painting himself as author.


That development went social is really awesome. Like having the flu or something.



That does not at all explain their overly aggressive approach and (initial) lack of attribution.


It explains their course of action, as Jorge was not flexible in his "my way or highway" approach. And I would also either ditch or fork earlier version, if maintainer of API is sabotaging my project.

IMO, making fork, instead of integrating or writing their own(without the need to acknowledge original author due to significant changes to a code) shows struggle of dealing with this situation. I think that it is too harsh to declare it as intent that is directed specifically towards Jorge, but they took that route where they were vulnerable to attack. In the place of users of Jorges API(because I'm not related in any way to anyone here - I'm just reading this piece an making my comment), if I knew that Jorge would be taking this to public and rally a mob to torch other side, I would be making my own code, but then I don't exactl'y understand using so many unowned modules on personal project, as it is vulnerable to do so in first place(it saves some time initially, but if they are improving code so much, that it is running faster, then that is not an issue to write their own) - and one of the vulnerabilities is exactly this situation.

I am sympathising here with Jorge, but only on that side where his efforts in making that API might be significant to him. I don't see anything else good from this situation, as he is not going to get back his main user and others might avoid using his other works because of this conflict. Well, he might have a temporary victory in getting his name in fork, but that will just lead to ditching any code of his in future. The important part is distinguishing author side and his ability to communicate with users and once again I can sympathise with him as author, but not as user, as his communication and solving issues are taken from defensive-aggressive side. You can like or dislike my opinion, but that does not change that fact.


> It explains their course of action, as Jorge was not flexible in his "my way or highway" approach.

I don't understand where this conclusion is coming from as it doesn't seem Andrey raised any concerns with colorette prior to his aggressive actions.


> The act of stripping git history and attribution while forking is itself malicious,

Well, okay, the forking could have been more politely, but author is a bit fast to pull the pirate card. It's a free/libre fork of a free/libre project after all.

> nanocolors implementation and API are the same as Colorette. You essentially pirated my work.[0]

[0]: https://twitter.com/jorgebucaran/status/1441728642711572486


free/libre != Do what you want

Copying and redistributing software without a license IS the definition of software piracy.

The current version appears to be MIT licensed. It is safe to assume that the fork was made under the same license. Given this assumption, and given that the MIT license requires copyright information to be preserved, stripping attribution is a license violation.

The claim of piracy is valid.


free/libre does not equate to unlicensed.

Fork has violated the license of original by stripping the attribution and history.


I'm losing my mind with people who keep replying with "That's open source baby! Don't make it open source if you don't like!"

The problem with this behavior is as follows:

- The MIT license requires attribution of the original work. The author contacted the person who forked this privately [1]. It wasn't done until the Twitter thread.

- Questionably the fork was renamed and didn't include git history to make the first point even worse. Git history was only rebased in after the Twitter thread [2].

1 - https://twitter.com/DerianAndre/status/1441851684095811585

2 - https://github.com/ai/nanocolors/commits/main?after=566a49b0...


I was on the forker’s side of things until those last two points: I don’t think anybody should have to justify creating a fork, but the (seemingly intentional) stripping of the revision history and absence of attribution indicates a bad actor to me.


It does not indicate a bad actor. It is bad actor. Attribution is not a "wish" of the original creator that you should feel morally obliged to follow. It is a legal prerequisite of you being allowed to make a fork of it for free, under the licence given by the author.


I think you read too far into “indicate,” since I agree with everything you’ve said. I was only trying to emphasize that it’s my observation.


It’d be helpful for anyone downvoting this to point out the factual error that I can’t see.


It's downvoted because it's a semantic nitpick based on a misunderstanding; it doesn't have enough meaning to contain a "factual error".


If it's just a misunderstanding, why try to punish him with the karma hit? That's just bullying, imho.


I don’t think this particular comment deserves any downvotes (and I didn’t downvote either it or its parent), but remarking on a comment’s vote status on HN is a general faux pas.


I am aware that complaining about your own downvotes is against the site rules. That is not what's going on here.

Instead, danw1979 was asking for someone to explain why a reasonable comment was getting downvoted into oblivion. Neither danw1979 nor lmilcin did anything to deserve the random dogpile they received.


The guideline is about discussing upvotes/downvotes in any comment, not just your own:

> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.


AFAIK, there’s no actual site rule about this. It’s just a faux pas in general, whether it’s your downvotes or someone else’s.

We’re on the same page about them not deserving it.


From the guidelines:

> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.

https://news.ycombinator.com/newsguidelines.html


And effectively censorship since such a comment will end up as the last child of its parent and with a text-color barely darker than the page background. Or hidden entirely if a couple people hit "flag" instead since "showdead" is opt-in.


The comment provides negative value, noise with insufficient signal. Getting such comments out of the way is exactly what downvotes are for, regardless of whether the intent was malicious.


Many legal things are immoral.


What is this a response to? I don’t believe I made a legal claim in my comment.


Don't forget when this was first brought up in Babel he was describing it as having an API "inspired" by colorette instead of what it was (a fork).


So he was straight up lying?


IIUC lack of attribution in this case is enough to invoke GitHub's DMCA process against the violating repo.


Any violation of the license. Lack of attribution is a violation of the license.


We'll but's that is what in the LICENSE, MIT, so yes it just this..


> Git history was only rebased in after the Twitter thread [2].

Any source to this? Your referenced link does not support your hypothesis.


You can see the original commit history in forks of nanocolor that occurred before Andrey Sitnik rebased:

* https://github.com/antonk52/nanocolors/commits/main

* https://github.com/corysimmons/nanocolors/commits/main?after...

You can, indeed, see that they lack all of the original repo's commits.


In addition to what others have pointed out:

https://twitter.com/jorgebucaran/status/1441886210998239238

The commits in nanocolor's git history also don't include Jorge's verified signature, which would come with the fork.


What is even going on here? https://github.com/jorgebucaran/colorette/issues/78. They're arguing about who should have attribution for adding a single "!s &&" to improve performance? What happened with the world where open-source was about creating cool projects together, not about who has the most stars on GitHub?

To be honest, this is the general feeling I get from the JavaScript community: Instead of working together to improve existing projects it's all about launching new alternative packages and get everyone to switch to your new fancy project. This causes a never ending churn where we jump between (incompatible) libraries with very little actual improvements.


> not about who has the most stars on GitHub?

It's the Instagram-ification of the open source world. All of the feedback and social signaling mechanisms are there. Likes, stars, followers, and charts of "contributions". It's just an extension of LinkedIn for many people.

Let's not forget the DigitalOcean Hacktoberfest debacle a few years ago. I still stumble upon repos with pull requests that contain nothing more than a single character change to a README. Just for a stupid SWAG t-shirt.


Holy shit that guy looks insufferable. At this point having PostCSS as a dependency just looks like a liability


Yes you should remove that creepy dependency


Behind the pretty facade there's a hyper competitive environment inside the JS community, sometimes with very low stakes. What's the incentive to fix fundamental issues if the metrics for success are stars and forks?

The best way to avoid their insanity is to use JS as a target language, pick some of their good tools and move on with life, working with safer languages.


That's just bullying from Sitnik. Stealing the entire repository and then blaming the victim for stealing a few letters back.


I mentioned Colorette in docs and license even before this Twitter thread. Why is it a stealing?


GitHub should remove stars, it has become a petty metric.


What's the term for when people with little to lose in low-stakes conflicts just have at it?


I first encountered this in the basement A/V department at my high school.


Cascade of attention deficit[0]?

JS is a vast ecosystem with little barriers to entry, and

> Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.

I don't think there's anything malicious going on, except a lot of people doing JS.

[0] https://www.jwz.org/doc/cadt.html


> I don't think there's anything malicious going on

The dev who copied the code forked someone’s repo, went out of his way to remove attribution and git history, sent PRs to replace the original package in other libraries with his own version, and when called out on it got defensive instead of apologizing. I think malicious is a fair way to describe his behavior.


I wasn't talking about the specific case, but about the general attitude of the JS ecosystem to replace a library very frequently.


> sent PRs to replace the original package in other libraries

Would you mind sharing a link to such PR?


This is Nano Colors author.

Even before this Twitter thread we had talk with Colorette author and I added mention to the docs, his name to LICENSE and promised him to not replace Colorette by Nano Colors.

The Colorette mention was there 5 days ago.


>promised him to not replace Colorette by Nano Colors.

And was that before or after you opened several PRs to replace Colorette with Nano Colors?


In my PRs I replace chalk to nanocolors


While I think you have a valid point about the javascript community reinventing the wheel often, the problem in this thread is simply that some people are inconsiderate, rude, and hostile, and that is in every software community and ecosystem in some way or another.


I think the forker here just crossed one of those invisible lines by a collection of actions that smell bad when seen as a whole.

He forked, stripped attribution and history [+] (license violation, but on its own probably just rises to the level of minor dickishness and is often a misunderstanding)

He started advertising his fork to replace the originally forked repo (a bit rude).

If the original library was unmaintained or unused, this probably would have been a big nothing-burger. But apparently the library that was quietly forked had a fairly big install base and contributing to that library first would have been a better choice.

What is missing from the discussion (and often unaccounted for in licenses themselves) is that there's a massive personal value to having a library used by large numbers of people.

[+] EDIT (to clarify): as gcr points out, this was not a standard github-style fork but rather a copy and re-commit as original history.


>> there's a massive personal value to having a library used by large numbers of people.

I have no experience with this - would you kindly explain that value? I am guessing that it has something to do with personal brand (my library is popular => I am good at this, hire me) - am I on the right track? Is there more?

(edited grammar)


That's exactly it. As someone else in this comment section described, there's "clout" from being the maintainer of a popular library and this particular action could be seen as "clout-chasing".

It's terrible that clout is such a thing in open-source, but there are complex incentive issues that led to this point.


You're forgetting the fact that he also went out of his way to strip the git history at first.


I clarified the comment a bit -- I considered that attribution-stripping, but I think you're right that it's more than just that.

Tangentially: it's somewhat interesting that we don't consider the source code history in our OSS licenses...


FWIW, I don't see anything wrong with stripping the git history. I think it's stupid and short-sighted, but whatever, it's allowed. One use case I've seen, sometimes you want to pull a single file from another project without a bunch of baggage.

Your license should cover the history, in that every source file should bear a license header, going back to the first commit.


> Your license should cover the history, in that every source file should bear a license header, going back to the first commit.

This is one way to do it. Problem remains when these important parts, even whole files - e.g. COPYRIGHT - are removed from the archived copy.

From what the original author reports, this is what happened.


I fully agree with that. Stripping licenses is a Bad Thing™.

When I've imported foreign files from other projects that don't have license headers, I give them license headers and also append their LICENSE or COPYRIGHT file into mine; I like belts and suspenders.

Removing history, itself, is not especially problematic. History is for maintenance, merges, and downstream compatibility issues.


> it's somewhat interesting that we don't consider the source code history in our OSS licenses

I think it would be too restrictive. It might prevent you from working differently for no clear benefits. However, keeping the history is an easy way to track who contributed what so you probably should keep the history of projects with more than one contributors or you lose precise attribution in practice (apart for the other obvious reasons to keep the history).


> it's somewhat interesting that we don't consider the source code history in our OSS licenses

Developing is in the burden of the single developer/project and which kind of version control system is used to produce releases can hardly be mandated by copyright law.

It is only one reason to use a F/L/OS/S license for contributing back, that is taking part in the development project. So on the other hand, it sort of does consider that, but it's merely then in the social interaction.

What so hurtfully happened here is that a collaborator tried to break the ties (forcefully) and was powerful enough to do so.

Sure, this renders the OSS license less effective, and I guess this can be seen or felt by many developers.


> Tangentially: it's somewhat interesting that we don't consider the source code history in our OSS licenses...

IIUC, IANAL, we don't have to worry about it.

Versions of software can have different licenses, and the license for each version is the license that the repo was under when that version was committed.

As far as I know, if you replace every instance of "version" in the previous paragraph with "commit", it still applies.

I think this means that every commit is under a specific license, and therefore, the entire history is under one or more licenses.


> Versions of software can have different licenses, and the license for each version is the license that the repo was under when that version was committed.

Not particularly wrong, just adding: There can even be additional licensing terms that aren't documented in the git history so they wouldn't be visible there.

And there is another sticky detail:

So if the original copy would have violated any of the licensing terms of the revision/release being copied (e.g. by removing copyright/authoring information), any more of these copies may become tainted if that resulted in a broken license chain. At this stage it is already regardless which licensing is announced in the new repository (and at which commit).

This poses some problems on very public systems like Github as it may not be directly visible any longer.

One way to deal with it is to block the violating user on Github. It's not perfect but can help with bookkeeping.

And in general you normally should just do Github forks to file pull requests, not to actually fork projects. Not saying that you can't - you can perfectly - but more on the level of day to day operations. For a full fork, you should have actual reasons. Otherwise its ruining the benefits of copying code.


Yes, I think your comment adds a lot to mine.

Licensing of version control history might need to have a legal debate, actually.


You can put it under proprietary reciprocal terms and void the right to copy when history is damaged. Copyright should cover that.

You can't do this with lax permissive licenses nor with copyleft as they allow to modify the work, which would mean the right to modify the history.


Those are good points.

Is there any way to have an open source license that protects history?


None that I can think of. History of projects is by the people who do/participate.

If you want to remove the right to modify the project (which includes the history if shared as common on Github) it is not open source (free/libre) software any longer.

In this case such a license wouldn't be needed either honestly. There would be no win with it, b/c it would have been similarly easily violated and that's it. Don't hope for a strong "legal" thing here, it won't help to solve these kind of problems (IMHO).

And for the license troll:

Instead declare the repository on Github as Database Work. Put it under a proprietary license. Github _might_ falsely read a license from a software stored in that database as the database's license, but you can easily leave an "all rights reserved" in the project description that is more prominently visible than that.


https://twitter.com/equinusocio/status/1441732243727192087?s...

> You should think this "wow, the author of one of the most popular frontend tools of today just used my work as reference. It's an honor."

By far my favorite and most ridiculous tweet I've seen in this thread.


That is by far one of the worst takes I've seen. Beyond the fact that he A) has no skin in the game, so why comment, he B) is assuming to know "how" someone should feel about anything.


Welcome to Twitter!


I've seen this argument before, when someone copied a piece of software (by me) and, when caught, advertised the replacement of the copyright statement and reattribution as significant "improvements and extra functionality" to his fan base. This attitude has been around for a while.


I feel like I'm in a bizarro world the number of people supporting the forker or trying to make it off like its just an innocent mistake.


That reads like obvious sarcasm, but the follow-up comments by same author made me doubt it.


The JS Open Source Community is filled with people grifting things like this. Quite notably, there's a linter called JS Standard Style, which actually has nothing to do with JS Standards.

It's marketed as if it was a standard, the fact that it isn't is tucked away in the readme, and also -- the entire project is just a wrapper around someones .eslintrc file, yet barely any credit is given to the ESLint devs who do all the work.

Go ahead and read the readme here, https://github.com/standard/standard. Could you genuinely tell this wasn't really a JS Standard at a glance? Could you tell this was just a config file for someone elses work? None of the donations go upstream to eslint by the way.

Hell, the actual config file is hidden inside a sub repo:

https://github.com/standard/eslint-config-standard

which has the audacity to claim

> This module is for advanced users. You probably want to use standard instead :)

It's a config file for someone elses program! Why does this library go through so much effort to hide that it's just someones config file? Why on earth is it called JS Standard Style?

The whole community is filled with slimy nonsense like this.

EDIT: also, this was the project that displayed ads in a million terminals on installs[1]. It's 100% clear to me that this package is misleadingly marketed for personal gain.

[1]: https://github.com/standard/standard/issues/1381


Wow, how cringey. They reference "standard" as not being used the same way, but instead like "high quality standard". Do they not know that high quality itself is a verified standard, that's why it's sought after? Just weird and writes like a child.


See also, the "StandardRB" wrapper around somebody's RuboCop config:

https://github.com/testdouble/standard

https://github.com/testdouble/standard/blob/main/config/base...


Then again, companies like Github and Heroku use it, and even UK Government. Maybe it does produce value for them?


They copied the idea of gofmt; they could be a bit fairer with attribution to ESLint though.


I don't really think the idea is copied at all. The idea of formatting code is fairly common. I just think they should stop using deceptive advertising.


I meant copying without a negative connotation, as it is a good thing to copy good ideas.

But ESlint there does all the work, it's a self proclaimed "standard" that works very well in the modern working environments due to hype.


He literally took his project and branded as his.

https://github.com/ai/nanocolors/commits/main?after=566a49b0...

Disgusting.


the mantion of colorette is on top of Nano Colors docs with clear list of why fork was created and the changes

https://github.com/ai/nanocolors#nano-colors


As others have pointed out, Andrey Sitnik only added the mention after the twitter thread blew up.


iskin is ai/Andrey Sitnik - he hasn’t made it obvious here, but see other comments in this thread.


Check project’s history. I added Colorette mention in docs and LICENSE just after Colorette’s author asked me (before the Twitter thread). We even agreed on the text.

Colorette’s author created this thread because of my PR to Babel.


We'll thats legal, and that's all about it when using MIT.


I wouldn't be so sure of that. Most of the world's copyright laws follow the Berne Convention, which in addition to the economic rights that US copyright law provides also provides "moral" rights including the right of attribution.

The US sort of half-heartedly added moral rights about 30 years ago in order to join Berne, but they are limited mostly to works of visual arts and would not apply to code.

They are not so limited in most of the rest of the world. Furthermore in much of the world (such as most of Europe) an author cannot waive or assign their moral rights and so any license term that purports to do so would be invalid in those places.

Even if I was the kind of person who would want to misattribute someone else's work as my own, unless I was very very sure that I only had to worry about US copyright law I would tread very carefully.


MIT requires copies to retain the original copyright notice and license info.


It looks like nanocolors is a fork of colorette with a few (substantial?) changes, see https://github.com/ai/nanocolors/wiki/Colorette-Changes. However, the author of nanocolors, Andrey Sitnik, only added attribution info about colorette after Jorge Bucaran went public about the fork on Twitter. If the fork had attributed colorette from the start, would there be drama here?


Colorette author here. I put the benchmarks in a CI workflow so anyone can check. Click Benchmarks to see the results:

https://github.com/jorgebucaran/color-bench-test/runs/371243...


Wonder how “ai” would feel if you just forked postcss without attribution and opened PRs against popular projects to replace.

Something tells me they wouldn’t be so calm about the whole affair


I promote PostCSS alternatives in PostCSS twitter account

https://twitter.com/PostCSS/status/777344095748579328


Which is nowhere near no_wizard's point. And nowhere near what you've done.

Gorge Bucaran, author of Colorette, summarizes your actions here https://github.com/ai/nanocolors/pull/14#issuecomment-927134...:

"Colorette isn't some obscure project either. It is well used. Now imagine I find a project that meets that description. Clone it. Erase the .git directory. Initialize a new repository. Make a few extraneous changes. Incorrectly benchmark it. Falsely claim improved performance. Tweak the docs. Change the name. Add a logo. Start aggressively promoting it and sending PRs to high-profile projects while leveraging a non-trivial social media following. I'm not against forking a project and adding new value to it. I encourage that. But that's not what's going on here. This is the collector getting away with a new piece for their collection."

Comparing that, to "promoting alternatives" to one of your projects on Twitter, shows a creepy lack of acknowledgement.

But that's why we're here, isn't it?


You have a new benchmark results after you backported Nano Colors optimizations and refused to mentioned it

https://github.com/jorgebucaran/colorette/issues/78

Just look at performance changes history,


lol, when it comes to one tiny change (which is highly unlikely to actually meet any copyright standard) suddenly they really care about credit? What a dick.


Any ANSI color library is a very simple thing.

Nano Colors mentioned Colorette in docs, COPYRIGHT and keep origin git history.

If Nano Colors was open about credits, why Colorette’s author should not do the same?


was? The main problem here is that it wasn't doing these things until the noise started. Nobody cares about it being a fork, the entire problem is how it was forked.

EDIT: lol, I only now realized you are ai. So now you are here, pretending you did all this the entire time and did not only add it all back after being called out on misrepresenting it? And at the same time trying to point at the other guys mistakes?


I added Colorette mention before the Twitter thread.

Just after Colorette’s author asked me. We even agreed on text form of this mention.

He started Twitter thread because of my PRs to Babel.

After Twitter thread I just copied git commits (only because another person helped my with doing it right) and created COPYRIGHT file (but Colorette author was mentioned in LICENSE before the threat anyway).


Please tell me why didn’t you just click the fork button or mentioned Colorette from the very beginning but instead started out maliciously and tried to use your influence to your advantage? To me there’s no other explanation than you tried to sweep it under the rug but it didn’t work out so you’re playing the victim card.


As I mention here, because Nano Colors it's not just fork of Colorette. It was created as a mix of Colorette and kleur.

https://twitter.com/sitnikcode/status/1441827379454746637?s=...

Fork button will not work for this case.


You didn’t acknowledge the second part of my question


Were those new benchmark results before or after Andrey Sitnik removed a lot of the edgecase handlers from colorette?

https://news.ycombinator.com/item?id=28660536


He is Sitnik



it's also worth pointing out the author of nanocolors https://github.com/ai has multiple PRs in the last few days asking libraries to replace chalk/colorette with his nanocolors. smells bad to me but maybe that's how the whole thing works.


He does seem very aggressive in his attempts to get this into as many popular packages (and/or onto as many machines) as he can in the shortest amount of time.

According to the original project's author, he even silently removed loads of edge case handlers until he was called out on it [0]. That seems to have been a really quick and dirty tactic to get his performance numbers up.

My spidey senses are tingling too.

[0] https://github.com/ai/nanocolors/pull/14#issuecomment-927152...


Wouldnt be surprised if the package then gets sold to some shady people.

Desperate people do desperate things and this surely looks desperate.


Only just now noticed I've worked with Andrey on several issues in other projects he's involved with (there are many).

For what it's worth, these dealings left me with a very solid impression of his person, one that his current behaviour does not at all match.

It is either just a really bad judgement call and an even worse handling of the resulting fallout, or, if something fishy is indeed going on, the result of some external source of pressure (blackmail, money problems, compromised account, ect.).


The third possibility is that is your impression of him was wrong.


This is a massive leap and really shouldn't be on HN.


Frankly I do not appreciate most of the comments in that thread by others, a lot of then border on or enter "victim blaming", and others are straight up gaslighting, either intentionally or through negligence. Totally unhelpful to "OpenSource" to take this kind of attitude toward people when the terms of their license are exploited.


Agreed. It's like this person's fan club is out in full force to defend their honor. Impossible to see this as anything other than both unethical and a violation of the MIT license.

The issue only being resolved [1] when public shame was involved should close this case.

1 - https://github.com/ai/nanocolors/blob/main/COPYRIGHT#L1-L3


This is how things have worked in the JS community for a long time. It's easy to say that new library X "is already used by Y and Z" which have millions of downloads, when you're the author of X, Y and Z and have a following. The library gets instant adoption, collaborators and good search rankings.

It's not always bad, but it stifles creativity and I believe has caused us to be stuck with libraries just because "they are popular and well-maintained" versus finding the actual ideal solution, the React ecosystem being a strong example of that. Not to mention that, contrary to what you would expect, the larger the company, the more often decisions will be made based on github star count, almost completely ignoring technical merit.

</rant>


This is going to sound like a dumb question and is certainly going to be an unrelated tangent, but: why in the world does the Node ecosystem have half a dozen competing terminal colorization libraries? Is that much CLI tooling really being written in JavaScript?

I spend virtually my entire workday in a terminal, and I’ve never once needed a CLI tool written in JS. Where is all this code going?


Because a lot of the JS community comes from the design world, and they care about colors more than other communities.

In Python, the experience has been the opposite. We had to wait until recently to have once very good decent terminal coloring lib: rich.


It's because it's something that can be easily influential. At some point every sufficiently large CLI tool needs a terminal color library, and if you can make yours 1% better than anything else, then you can make a library that touches a lot of projects, which is great for your resume and improves your job prospects (at least that's what they hope).


There's lots of CLI tools around JavaScript itself. And many third-party developer oriented services ( Firebase, Netlify, etc.) have their CLIs in JS as well.


Thanks for the context. I do very little work with SaaS services, so I’m extraordinarily ignorant of their CLIs!


If you ever are interested, there's some cool stuff in the area like oclif framework. (from heroku) for building nice CLI tools...

Very interesting mix of JS+CLI indeed


Javascript is the opposite of a batteries-included language, so there is and has been an enormous amount of wasted effort duplicating functionality that should have been in a standard library.


We’re talking about a terminal colorization function though. Fragmentation of packages aside, are there any other languages that have terminal text colorization built into the standard library?


Every serious programming language I've ever used...

https://docs.microsoft.com/en-us/dotnet/api/system.console.f...

It's even easier on UNIX-like terminals, where ANSI escape codes should work.


Okay? You gave one example, C#, and extrapolated that to every single serious programming language you've ever used. I just took a quick look and none of Java, ruby, python, and PHP has this functionality in its standard library. Also yes ANSI codes work but it's not easy to write or read, so that's what these libraries are for. I'm not a JS apologist but it seems inaccurate to imply that its need for a terminal colorization library is a unique deficiency of the language.


Are there any movements towards creating a standard library for JavaScript (or at least server-side JS)?


There are many, many, many such movements. Which somewhat defeats the point, really.


This is why I have 107 different point-releases of lowdash and jquery in my node_modules folder


>107 different point-releases of lowdash

Would totally believe that lowdash is a lodash fork.


I don't know what you mean by "point-releases". I understand the hyperbole but pretty much every package manager will minimize different versions by installing one that's compatible with all requirements.


I’d wager a guess that bootcamps teaching JS producing lots of people. Eventually, some will want to recreate something from scratch. A law of large numbers thing. I could be wrong though.

As for where it’s going, Node based CLI programs. For example, `yarn upgrade-interactive` uses it (a chalk-like module)


Combination of so much JS programmers being

    * Young

    * Hipster

    * From bootcamps without any other serious knowledge.

    * A culture of resume padding

    * A total lack of care about security, performance or reliability.



Riddled with insecurity yet somehow lacking humility.


For both definitions of "insecure"


I think it's because they try to impress their non-technical friends with flashy colourful and matrix-like terminal windows and come off as hackers when in reality most of them don't even know what a stack overflow is.


This kind of programming elitism is a general bummer: what good does it do to gatekeep “hacker” in this way?

Even the context is absurd: we’re on a website that calls itself “Hacker News” but caters chiefly to the relatively narrow and un-hacker-like interests of a handful of overcapitalized investors.


I took it to mean a second definition describing a particular aesthetic identity, e.g. dark-mode everything, tiny and/or monospace fonts, use of the word "rice" as a verb, etc. I'm totally down for two of those so this isn't said with disdain ;)

Perhaps "hax0r" would be more appropriate.


You only need to read the linked Twitter thread to get a couple examples.


I read the thread, and it sounds like these libraries end up in what I think of (from other ecosystems) as “core” tooling: package managers, linters, &c. I definitely wasn’t expecting that: most of the other ecosystems I’ve interacted with have had a “vendor or reimplement” mentality when it comes to dependencies in common tooling.


Overwhelming majority of modern web frontend development is done with build tools written in JS. Node is a popular choice for backend and that also generates a lot of lines of terminal output.


Aside from who’s right and who’s wrong, although I do agree with this is an unattributed fork, the idea that JS OSS devs are incentivized to do this to increase their downloads number is absurd. Maybe we need to replace that with a star system including both security vulnerabilities and downloads that is less dopamine-inducing than a moving number.


Bugs should also come into play. Some people mentioned that the developer of nanocolors removed some edge case handling to make his microbenchmarks faster. I like fast software as much as anyone, but more than that I love correct software. I'd rather wait for something to finish than have to search why something exploded. Especially if it's a dependency of a dependency that I use, which is the case with Babel.


Why it is a unattributed fork if Colorette is mentioned in docs, COPYRIGHT and origin commits are in history?


You should mention your conflict of interest as the nanocolors “developer”.


I am mentioning it in Babel PRs:

> It will have a good support. My other projects from nano-series like very popular Nano ID shows a minimal number of bugs and excellent response time.


He meant you should mention your bias in the comments on HN, naturally you’re going to think you’re right (and they will think they’re right). It was my understanding that the commit history wasn’t originally saved - maybe this was wrong, did you have the commit history immediately after copying the code base? The main issue is then replacing it in open source software where the other version exists without due cause.

Should we copy your code, attribute it to you in a readme, and slightly optimize some of your code to replace your efforts everywhere?


I copied one file and I didn't know a way to keep the history of this file.

When people later explained how to keep the history of single file I tried to restored it.


This is JavaScript package-culture at work.

Many packages attempt to be those “as seen on Tv” gadgets which fix weirdly specific issues in a functionally-fixed way. Single-function goods are frequently given cutesy branding names in hopes of making their way into your home/package.json. Now we even have the product-level copycats.

Computer code is not an appliance, and no one cares how many people play with your little gadget.


> This is JavaScript package-culture at work.

Node.js ecosystem makes things worse because of package number inflation due to a piss poor standard library (praise DENO).

But this isn't limited to Javascript. It has everything to do with Github as a social platform. Case point, the same petty drama happens in the Go community with frameworks like "Iris" and the vitriol around it. Github is a repo service yes, but also a social platform, that makes or undo careers and there is potential money involved now.


Generally, I agree, and I find package systems and social coding tools to be a net positive. Perhaps there is something like a license that can help in these situations?

I’m admittedly pretty ignorant to software licenses but I’d imagine they can help in at least this scenario.


I wish the legal arguments (the fact that the original project was under the MIT license - that's right, the original author has no rights to draw consequences from this rip-off) didn't blind everyone to the fact that "ai" behaved not ok. Not in the spirit of OpenSource. If he encountered problems with the library, why didn't he want to contact the author first and suggest changes to the original project? Why didn't he write that the project is a fork? Why is he now pushing his library into projects that use colorette? Seems like an unclean pursuit of some imaginary power, instead of a desire to develop free software.


The MIT license still requires attribution, so no this isn't ok.


That doesn't conflict with anything they said.


it doesn't conflict with the overall sense of what they said.

but it does conflict with this particular remark:

"the original author has no rights to draw consequences from this rip-off"

since the license requires attribution, this is false.


I mentioned him in docs, COPYRIGHT and keep the origin history?

I clearly explain the reasons of fork creation and the changes https://github.com/ai/nanocolors/wiki/Colorette-Changes

What “fork rules” did I violate?


Every time there is a post like this I go check the license of the original project. Invariably, it is MIT. I think this is probably indicative of something, although I couldn't say what.


It's probably indicative of the fact that MIT is the de-facto default license in the JS ecosystem. It's not like other licenses require much more of forks than MIT does.


Everything in the npm ecosystem pretty much has to be MIT, or none of it would work.

You could poison most of the web dev ecosystem by changing the license on a handful of packages to GPL...


The GPL wouldn't affect server-side JS (you'd need the AGPL for that), but client-side JS would have to be released under the GPL in un-minified form.


Why? You could use GPL package in MIT licensed library.


Yes and then anyone using said library would have to open source their work.


I think it's likely indicative of the fact that the JS ecosystem doesn't really understand the meaning of open source (or the distinction between "open source" and free/libre software).

The author's comments are quite enlightening of their incomplete understanding of the licenses they use:

> nanocolors implementation and API are the same as

> Colorette. You essentially pirated my work.

After using a license that explicitly allows others to take their work, it's suprising the author thinks that someone "pirated" their work.

Hopefully this signals the start of an awakening within the JS ecosystem, with more and more developers switching to licenses like the GPL that actually respect the developers.


> After using a license that explicitly allows others to take their work, it's suprising the author thinks that someone "pirated" their work.

He stripped the license when he created his fork. (Only adding it after the thread on Twitter became actively noticed).

How is that _not_ pirating?


For libraries it is very difficult to chose a permissive license. Most companies have a whitelist for licenses for libraries they are allowed to use. And for a good reason. This is mostly MIT, BSD and Apache.

If you use a gpl licensed library in your project, it essentially becomes gpl licensed too. If you ever want to sell your software, this is probably a big no-no. It will become quite challenging, and could end up in a legal desaster.

So to create a successful library, other people are willing to use, you essentially have to release it without restrictions.


What about LGPL which is quite explicitly designed for libraries?


This could work, but it's just annoying. You'd have to modify your build process to serve this library separately instead of including it in your main bundle and then doing some code splitting.


the work being pirated is not the code but its place in the library marketplace, the license played a minimal role here (as it was infringed anyway)


What exactly would be different here if the project was under GPL?


I was going to say this.

IIRC, the MIT license does not require attribution (EDIT: it does)

Most people do not understand the philosophy of Open Source. It's not "hey look at me, I made this, look at me".

They should not give liberties to other people if they don't want them to use it.

EDIT: Seeing the comments to this one, this should be seen as a proof of Cunningham's Law[1]

  [1] - https://meta.wikimedia.org/wiki/Cunningham%27s_Law


It's literally three lines of actual content. It would not take you long to read it.

The MIT License (MIT)

Copyright © 2021 <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

He was violating the license until 19 hours ago: https://github.com/ai/nanocolors/commit/1d86f02ca751ad8c113c...

The MIT license is a bad license but in this case the terms of it were clearly being violated by a hostile actor.


They aren’t using the commit you referenced. Instead they went down this path where there is one license, with one copyright (new author), but they are citing the other work in the copyrights: https://github.com/ai/nanocolors/pull/15/commits/182c767583b...


No need to be condescending with phrasing like "It would not take you long to read it".


That was necessary to demonstrate that there was no need to falsely recall it. You could just read it. It's three lines, takes about thirty seconds to read carefully, and would have saved you the trouble of posting misinformation.


It was not necessary. I would have (and I did) edit my comment to rectify my error.

I did not claim I was "sure", which is the point of "IIRC". Calling this misinformation is a bit exaggerated.

You can choose to be kind.


You can also choose to read up on essential facts before posting. When people send me emails that require me to go out of my way to interpret and understand because they withheld easily accessible information (usually because of their laziness to type) I answer with a "?" and remove the email.

IIRC isn't necessary when the content is clearly and easily accessible for you to read, I would prefer to not have to read comments based on vague memory when the facts are right there. This is netiquette.


it wasn’t necessary, but as a bystander I enjoyed it :)


You should really read the MIT license text again. It's 3 paragraphs...

They're also not saying that they weren't allowed to fork it. Just that it was an asshole move, and in community efforts that matters too. The exact same thing could happen with a GPL project, no difference license-wise.


From the MIT license:

"The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."

It clearly requires attribution.


I feel I must come from a bizarro world. Most people on Twitter are supporting the actions of the “forker” despite it being clear he did no work to improve the code and is going out of his way to supplant the original project in other codebases.

What am I missing?


Most people probably don't realise that all attribution was gone at first.


What I find absolutely baffling about all this is that it could have been avoided by adding a throwaway line about how this library is a fork of the other one with performance in mind.

A lot of drama can often be avoided if people just communicate better.


The way that git history was removed makes me wonder if they preferred to claim as their own original work. Unless erasing the history was done by accident.

This doesn’t feel like a communication issue as much as an ethical question.


> Unless erasing the history was done by accident.

It couldn't have been. Forking 'properly' on GitHub is a single click. Doing what they did required cloning, erasing .git, then creating a new repo. The original history (now replaced with colorette's) even had an 'initial commit' by ai.

This was 100% malicious.


Isn't Jorge Bucaran the guy who contributed code to Oh My Fish and then tried to DMCA it for copyright violation (for the code that he had contributed) in order to get more traffic to his competitor project Fisherman? I'd not trust anything this guy says


I'm that person, but that's not exactly what I did.

Wahoo, a framework I had built, became the base for the then, new Oh My Fish.

I, myself, committed[1] it into the Oh My Fish repository, effectively replacing everything but the name. This was a huge change.

Regrettably, I didn't include a migration strategy, and ended up breaking other things down the line because of that. This and poor communication on my part, eventually led to a fallout with the other maintainer and I exited the project. So, I asked them to revert my changes or provide full attribution.

Reverting my changes would've made no sense at that point, and I realize that.

Attribution was left as "Copyright (c) 2015, Oh My Fish!". That didn't do it for me. My name was not anywhere. Ironically, my name is now almost everywhere Oh My Fish is brought up.

Filling a DMCA notice was my careless reaction to the situation. I know that I could've handled it better. I wasn't at my best.

[1] https://github.com/oh-my-fish/oh-my-fish/commit/2693a2fd18bd...


Every single step sounds like a nighmare to OMF.

1. You contributed code to the project that broke a lot of stuff

2. You tried to "take back" the contribution - this is really rich, as you already gave the code away as is without attribution according to the repo license.

3. Your ego just couldn't accept not being mentioned, so you thought attempting to kill OMF was a good idea. Your fame and glory was important enough to try to kill a popular open source project.

It's not that you could have handled it better, you behaved with ego and toxicity every step of the way.


Yes, indeed.

1. From a technical standpoint, it just meant swapping Oh My Fish for Wahoo and changing the name. But my complete lack of planning led to numerous issues that escalated to falling out with the team. I was new to FOSS, immature and reckless.

2. Absolutely. You can't take back gifts that you gave away in the first place. I could've looked for another way, but sadly, I didn't.

3. True. I felt slighted, and used that feeling to justify myself, but in hindsight, I was only being selfish.


Yes, same guy. was discussed here https://news.ycombinator.com/item?id=10271304


Good comment by one of the Chalk maintainers

https://github.com/babel/babel/pull/13783#issuecomment-92731...


I don't think the main message from chalk maintainers is good.

Chalk maintainers basically discard the performance improvement as micro-benchmarking (i.e. "doesn't matter in the real world"). Chalk maintainers also say tree shaking doesn't matter in the real world.

Why do they minimize these 2 improvements? If 2 libraries are equivalent, I'd go with the ones with extra improvements.

Chalk maintainers also mentioned that chalk would have no dependencies soon (not now, but soon). They also mentioned that chalk is well maintained for over 10y.

So, over the past decade, they can't remove dependencies? Suddenly, nanocolors show up, and now they will remove dependencies soon? That doesn't sound well-maintained.

Speed/tree-shaking aside, having no dependencies is a huge improvement.


> Chalk maintainers basically discard the performance improvement as micro-benchmarking (i.e. "doesn't matter in the real world"). Chalk maintainers also say tree shaking doesn't matter in the real world.

Chalk’s purpose is to color things printed to the terminal. Unless it’s performance is atrocious, which I doubt, it doesn’t matter unless a ridiculous amount of data is printed.

> Chalk maintainers also say tree shaking doesn't matter in the real world

No, they say it doesn’t matter for chalk’s use case. Which is command-line tools that are almost never tree-shaken.


> Chalk’s purpose is to color things printed to the terminal. Unless it’s performance is atrocious, which I doubt, it doesn’t matter unless a ridiculous amount of data is printed.

Chalk is downloaded 15 millions per day.

We probably can multiply how much time has wasted from 15 millions run per day. It matters collectively.

> No, they say it doesn’t matter for chalk’s use case. Which is command-line tools that are almost never tree-shaken.

Are you saying people don't package the terminal app when written in Node.js?

It matters in some cases, and it doesn't matter in some.

Chalk maintainers try to brush off these improvements, which seem like bad intents, tbh.


I don't have a horse in this race, but I am a bit bothered by two arguments, because I see variations on them so often (so this is less of a reply to you personally).

> Chalk is downloaded 15 millions per day. > We probably can multiply how much time has wasted from 15 millions run per day. It matters collectively.

If I give you back 5 seconds each day, will it matter to you? Will you be able to enjoy or do something that you otherwise wouldn't? I doubt it. I am certain that is true practically every person in those 15 millions.

The cumulative loss of something can be huge, but still don't matter because its distributed to a degree where it is barely a rounding error.

> Are you saying people don't package the terminal app when written in Node.js?

Details matter. Chalk is ~100K and nanocolors is 16K. Yes, 90K is meaningless saving for a terminal app.


> The cumulative loss of something can be huge, but still don't matter because its distributed to a degree where it is barely a rounding error.

Are you claiming it doesn't matter to anyone or just you?

> If I give you back 5 seconds each day, will it matter to you? Will you be able to enjoy or do something that you otherwise wouldn't?

I'd welcome the time back since I don't lose anything in return anyway.

So, a big YES here.

Generally I would put faster library as a plus.

Working in a big company, when choosing between 2 open sources, we will need to list down pros and cons.

Among other things, being 4x smaller is definitely one of the plus consideration. I try not to exaggerate this; it's not a major plus, but a plus nonetheless

Saying these doesn't matter is disingenuous.

To you, maybe, but not for most. If everything else is equal, you would choose chalk despite it is 4x bigger in size and slower? Most will choose the smaller and faster library.


Yes, I am claiming that saving 5 seconds out of 86400 in a day does not matter to any healthy person.

As a web developer I generally prefer things being faster and/or smaller too, but I would not change a working field-tested library for negligible effect. The problem in the case that is being discussed is not which library would be chosen when none is being used yet, but does it make sense to replace an existing one to save 90K of disk space and maybe a few seconds per day? To me this looks like very definition of bike-shedding and yes, I would definitely not switch library if these are the only compelling reasons.

4x smaller than the other one doesn't really tell anything without considering how big the whole app that uses this library is. On our fairly basic Nuxt project node_modules directory takes 250M. Do you really think any of us should care about 90K?

And lastly, you don't know me. Save your "disingenuous" remarks for people you do.


I guess to get 5 seconds back it would have to many many "green success" or "red failure". Then a slow network hop would get the 5 seconds back.


> We probably can multiply how much time has wasted from 15 millions run per day. It matters collectively.

The benchmark measurements they're discussing are on the order of tens-of-millions of operations per second: https://github.com/ai/nanocolors#benchmarks

Are the contents of your terminal changing that frequently?


Ouch!


There’s a discussion about this in GitHub: https://github.com/babel/babel/pull/13783


From that discussion it seems @ai (the fork author) did conduct himself in the spirit of open source, or at least it could plausibly be said so.

- contributed to the original project for a year

- forked the original project only after the author did not agree with the his requests/prs

- (turned out this was done latter after it became publicized) kept the commit history as well as attributing the author in the docs

- All in accordance to license (MIT)

- modified/improved on the original project in his fork.

It looks like he performed the fork after the original author moved the project in an undesirable direction. I mean what else would could he have done?

Isn’t the awesome part about open source that if someone changes their lib underneath you, in a way that you do not like, you _can_ fork it and keep it in the direction you desire. And after that “the market” decides which direction was more to the users liking?

I’ve been ripped off by others as well and know the feeling of betrayal when you see someone getting praise for work they have not done, but this seems hardly the case here.


> kept the commit history as well as attributing the author in the docs

He didn't. He added that after being publicly called out on it.


oh ok, missed that little wrinkle, but its there now at least


I don't think this behaviour is acceptable.

People should be encouraged to open source their code if it's useful for the community. They should not be worried that some big gun take it and promote it as its own.

I wonder how the community can best prevent this behaviour?


I completely agree with it.

This is why I used Colorette for a year, promote it and send PRs there. https://twitter.com/sitnikcode/status/1441824191624486924

For for created because Colorette changed API and author didn’t want to change it back. The reasons of fork is clearly desrcibed in project’s docs https://github.com/ai/nanocolors/wiki/Colorette-Changes

I mentioned Colorette in Nano Colors docs, COPYRIGHT and keep the origin history.

But when Colorette author backported my performance optimizations he refuses to do the same in return.


I don't feel very convinced by the case you are trying to make here.

You did not mention colorette until you were forced to do it. Why not talk to the author before making a fork?

You mention that you disagreed with changes in colorette, but you have no evidence for it. If you discussed it in an issue or PR, that would be easy to find and share.

You took all of colorette. The "backported" performance improvement is a single line of code. That you try to make it seem like exactly the same thing seems childish and bullish to me.

If you are really not acting in bad faith, why not drop your fork now that colorette has changed the API back?


I started to mention Colorette when author asked me.

First mention (it was changed later) was added 6 days ago (threat was created 2 days ago): https://www.npmjs.com/package/nanocolors/v/0.1.2

Webpack team ask Colorette’s author to rollback API 2.x changes here (discussion was cleaned by Colorette’s author, but he said that it is how it see the best API): https://github.com/jorgebucaran/colorette/issues/70

> why not drop your fork now that colorette has changed the API back?

Author continued to act impulsively. He rolled back API in patch release instead of major made breaking changes.


You mentioned colorette, but not that the package was a fork, only that the API was the same. It's very hard to not interpret that as dishonesty.

The author acted impulsively after you copied and rebranded his package and then started pushing it everywhere. And now that's your excuse to keep your fork.

To get back to my original post. We want people to open source their code if it's useful for the community. Your behaviour here is going to scare people away from doing that. One little mistake and then boom someone with a bigger name takes all of your work and fame.

Don't you see that this is not beneficial for the community?


One way is to "name and shame" so that the next time Andrey Sitnik's name comes up, people can point to his wrongdoing.


Until this is resolved stay miles away from anything Andrey Sitnik has ever developed.


I would stay away from both, unfortunately.

The colorette's creator, Jorge, tried to dcma other repos on GitHub: https://news.ycombinator.com/item?id=10271304

Use his libraries at your own risk.


I'm sorry to hear that. I address the Oh My Fish fiasco here:

https://news.ycombinator.com/item?id=28661561


AI's response on GitHub:

"@jorgebucaran sorry for PostCSS/Browserslist migration from colorette. I understand your feeling (but it was an only move in case of colorette 2.x API changes and following API breaking change in patch release).

If you want to send another PR and replace chalk to colorette, I am OK with it. Babel’s users will be happy in both scenarios, since all colorette and nanocolors are both much smaller than chalk.

rebranded it as nanocolors

It is not true. Nano Colors was influenced by colorette API and internal design and I mentioned it in top section of Nano Colors docs. However, it is not rebranding:

I mix ideas not only from colorette but also from kleur, another great color formatting library. colorette and nanocolors has very different results in benchmark showing difference in internal implementation. If you compare kleur, nanocolors, and colorette you will see many similarities (because it is open source, and they share ideas between each other), but also many differences: In color detection. Nano Colors uses process.argv to be compatible with Chalk. In color’s functions. Nano Colors do not generate RegExp on every call for performance reasons. It also doesn’t have init/raw separation. This is not in the true spirit of open source.

Forks and idea sharing are also an important part of open-source if they are coming with respect to authors of origin ideas and mentioning them.

You are mentioned not only in docs (colorette mentioning text in Nano Colors docs was even approved by you) but also in LICENSE.

Before colorette 2.x API changes, I promote your project to other projects because I tried to find chalk alternative. I sent you PRs. I used your library in all my projects for a year.

We all stand on the shoulders of giants. We both used Chalk color detection algorithm as reference. We both using other source code to find the best optimizations.

If you do not like that your tools is also used as an inspiration (with mentioning you), feel free to replace this PR with PR of replacing chalk to colorette."

https://github.com/babel/babel/pull/13783#issuecomment-92710...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: