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!
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.
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
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.
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.
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.
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.
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.
> 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.
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.
"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,
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.
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".
> 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.
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.
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.
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.
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.
> 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]
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.
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].
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 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.
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.
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.
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.
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.
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.
> 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.
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.
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?
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.
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.
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.
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.
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.
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.
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:
> 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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.).
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.
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.
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?
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.
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?
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.
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)
* Young
* Hipster
* From bootcamps without any other serious knowledge.
* A culture of resume padding
* A total lack of care about security, performance or reliability.
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 ;)
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.
> 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?
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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 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.
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. 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.
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.
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.
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.
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 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?
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?
"@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."
reading through the threads it does appear both individuals are vying for some semblance of "fame", that the forker forked without git history and that the change was small enough to be made in a pr and merged. I think most of the contention here is that the forker ended up switching over babels (a build tool for js) codependency over to the new fork and without git history.
A is the unchanged inclusion of the license statement including the attribution.
Sorry. You are not free to strip a MIT license.
(Even, if this would not be the explicitly stated in the license, everything adhering to any kind of publication would still apply. E.g., pretending that the work of others having originated genuinely from you would be considered as plagiarism.)
Edit: To make this clear, the question of license violation has nothing to do with the question of plagiarism. These are on entirely different levels. One is about use, the other is about authorship. (As it happens, the MIT license has also something to say about any note of authorship included in the license statement.)
The barrier to entry into the JS community is very low relative to most other language communities. This has many advantages.....and many disadvantages
Something I often repeat on here: popularity and merit are not the same thing. And lacking a strong error correction signal, various disguised forms of cheating and stealing are often rewarded by increased popularity.
Maybe we should add some consequence to these types of things.
Some months ago, most of HN didn't like the idea that China's Mars rover (and a large part of their space tech stack) were copied from the US, kinda like "just leave it alone, it's for the sake of humanity."
But I see totally different reactions here. What's the difference here? Or why the double standards? Please enlighten me.
> Sadly it is only part of the story... All this situation happened due to the changed in your lib and unwillingness (initially) to change API, and when you've did - it was too late. Any cases like that could be easily solved by message to the author, before trying to go publicly
> We just have to all remember how you copied colorette from kleur. Seem everyone in the ansi space all copying from each other. Just congratulate nanocolors — spotting a perf boost where no one else did. Took the best of all worlds.
When you make something open-source, you give others free right to copy your work and release their own derivative version. That’s basically the point of open-source. And this version might become more popular and yours.
BUT, if you copy someone else’s work you NEED to give them attribution. Which is what nanocolors did wrong.
GitHub should add a feature which lets you attribute various parts of your code to other open-source projects (or better, auto-attributes them for you). And then when a project gains reputation it’s attributed projects gain some also. This is already done with forks / packages, but it could be more explicit and for vendor dependencies and regions of code as well.
This is the part I dislike about these super permissive licenses. Attribution is required, but a couple lines in some random file do you a fat lot of good if someone forks your project, rebrands, and essentially builds on top of your hard work.
It's the ugly side of open source. The community runs on the assumption that we're all on the same side and we wouldn't stab each other in the back like that, but it happens, and when it does, it stings, and a couple lines in some README file don't make up for it.
Is there a license that permits usage as a package, allows people to contribute, but prohibits forking? I guess, similar to what happened with ElasticSearch and others, right?
> Attribution is required, but a couple lines in some random file do you a fat lot of good if someone forks your project, rebrands, and essentially builds on top of your ripped off hard work.
Creator of the original work understands their license, and is happy when this happens [1]. The problem is this minimal, low bar wasn't even met. It was a fork in all sense of the word with git history wiped, renamed, and attribution removed until it was brought up publicly.
tl;dr Three 100-line JS packages (about the length of a really nice exhaustive stackoverflow answer) duking it out for social media superstardom.
In all likelihood you have each of them copied a dozen times in your node_modules for some reason, all different versions and out of date (scary!) and they all give you vulnerability warnings when you run npm audit.
(Being a former front-end engineer writing Java for the last couple years, reading anything in the modern JS world is mind boggling- just my lived experienced)
From what I've gathered, the attribution was introduced retroactively, recently, by rebasing the repo with that and on top of the upstream commits, only after the discussion was picked up publicly.
> Why? Colorette clearly copies that line from nanocolors, no?
And he copied the entire source code earlier and didn't mind hiding who wrote that? But now suddenly a tiny fix (which might be tiny and obvious enough to not even meet any copyright standard, although that's always vague and difficult) is worthy of demanding attribution for? That's really not the moment to go nitpicking the other guy. (Would a mention in the commit message have been really good style anyways? yes.)
Nano Colors mentioned Colorette in docs and Colorette author in LICENSE before Twitter thread. Colorette’s author asked m and I add the mention and agreed on the text.
This jorgebucaran guy has an interesting history and kept getting involved in these dramas. Previous one involved Oh My Fish project which was discussed here https://news.ycombinator.com/item?id=10271304
It's easily agreeable that attribution should have been given before publishing, but the level of hysteria in this post is excessive.
The author of the fork immediately complied and had likely just made a mistake in a hastily published fork. I suspect the original author was more frustrated with the fork existing.
This is a pretty terse reply, talk with him when... a month ago, or yesterday. I don't care for either side but I'm suspicious when people reach for twitter shame - it's more plausible that insta-pressure just forced him to drop his daily activities and immediately make changes to save face in public.
> Their attitude since then has left a lot to be desired.
I reached out to him when I could've filed a takedown notice instead. Later, after the tweets, I even asked him to shake hands on the whole thing[1][2][3], but he was already sunk-cost-mode on and determined to die on a stupid hill. Only because I called him out is that we were able to had my git history restored and copyright attributed.
> Their attitude since then has left a lot to be desired.
That refers to the forker's attitude following the tweets[4][5].
This seems to be a completely normal fork. This is not the first time that happens to open source software, and is an important part of the open source ecosystem. Off course forks are not a nice thing for the original authors, but a lot of good things happened because of forks. Libreoffice, Xorg, and many more.
The original package was MIT licensed, so this is totally legal and okay to do so
If there is a good reason for this fork, is another question. But if the forked library is now getting more traction than the original one, it is maybe doing something better.
PS: the fork is also MIT licensed, so the original author can totally backport the improvements into his original project.
> The original package was MIT licensed, so this is totally legal and okay to do so
The MIT license requires attribution. The attribution was removed until the author was called out publicly, so... No. This was not totally legal and okay to do so.
This was missed in the first place, and was a violation of the license. But this was quickly fixed.
I don’t want to defend the „thief“ ai, but I think the original author is being a bit too dramatic. If you don’t like people „stealing“ your code, chose a more permissive license. But then also less people will use it.
It wasn't fixed until he went public. As a popular maintainer ai knows how to fork while preserving history. Not to mention that he originally claimed the API was merely "inspired" by colorette.
He should credit author at least. That would be more with the spirit of OpenSource. Not using licences as a defence that "it's legally okay". It is, many things are legally okay, but still a shitty thing to do.
It's NOT legally OK. The license permits use of the copyrighted work with certain terms, attribution being one. That term was violated, just as when a big company takes a low level gpl driver and uses it without releasing the source. AI could have rightly been subject to a DMCA takedown, which is a legal action, for example.
The other way to look at this is that this guy’s whole Twitter thread is not in the spirit of open source. It’s not about you. It’s about improving life for everyone by freely sharing code. If you want it to be about you, don’t pick MIT from that drop down.
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.
