A notable JavaScript developer shamelessly copied one of my most downloaded nod
twitter.com
twitter.com
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.
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.
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...
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-...
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.
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.
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.
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
> 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.
"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.
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.
> 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
This [0] might be what you are looking for, it has both is-number and is-odd.
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.
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
Edit: Maybe HN is to blame as well.
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.
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.
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.
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.
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.
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
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.
Fork has violated the license of original by stripping the attribution and history.
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...
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.
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
We’re on the same page about them not deserving it.
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
Any source to this? Your referenced link does not support your hypothesis.
* 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.
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.
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.
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.
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.
Would you mind sharing a link to such PR?
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.
And was that before or after you opened several PRs to replace Colorette with Nano Colors?
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.
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)
It's terrible that clout is such a thing in open-source, but there are complex incentive issues that led to this point.
Tangentially: it's somewhat interesting that we don't consider the source code history in our OSS licenses...
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.
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.
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).
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.
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.
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.
Licensing of version control history might need to have a legal debate, actually.
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.
Is there any way to have an open source license that protects history?
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.
> 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.
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.
https://github.com/testdouble/standard
https://github.com/testdouble/standard/blob/main/config/base...
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.
https://github.com/ai/nanocolors/commits/main?after=566a49b0...
Disgusting.
Colorette’s author created this thread because of my PR to Babel.
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.
https://github.com/jorgebucaran/color-bench-test/runs/371243...
Something tells me they wouldn’t be so calm about the whole affair
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?
https://github.com/jorgebucaran/colorette/issues/78
Just look at performance changes history,
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?
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?
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).
https://twitter.com/sitnikcode/status/1441827379454746637?s=...
Fork button will not work for this case.
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...
Desperate people do desperate things and this surely looks desperate.
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 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
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>
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?
In Python, the experience has been the opposite. We had to wait until recently to have once very good decent terminal coloring lib: rich.
Very interesting mix of JS+CLI indeed
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.
Would totally believe that lowdash is a lodash fork.
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.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.
Perhaps "hax0r" would be more appropriate.
> 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.
Should we copy your code, attribute it to you in a readme, and slightly optimize some of your code to replace your efforts everywhere?
When people later explained how to keep the history of single file I tried to restored it.
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.
I’m admittedly pretty ignorant to software licenses but I’d imagine they can help in at least this scenario.
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 clearly explain the reasons of fork creation and the changes https://github.com/ai/nanocolors/wiki/Colorette-Changes
What “fork rules” did I violate?
You could poison most of the web dev ecosystem by changing the license on a handful of packages to GPL...
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.
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?
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.
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_LawThe 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'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.
"The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
It clearly requires attribution.
What am I missing?
A lot of drama can often be avoided if people just communicate better.
This doesn’t feel like a communication issue as much as an ethical question.
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.
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...
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.
https://github.com/babel/babel/pull/13783#issuecomment-92731...
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’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 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.
> 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.
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.
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.
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?
- 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.
He didn't. He added that after being publicly called out on it.
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?
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.
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?
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.
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?
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.
"@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...
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.)
Maybe we should add some consequence to these types of things.
But I see totally different reactions here. What's the difference here? Or why the double standards? Please enlighten me.
> 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.
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?
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.
1 - https://twitter.com/jorgebucaran/status/1441741173085786116
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)
We even agreed on the attribute text.
Also at the end Colorette’s author back-ported Nano Colors performance optimizations, but this time he refuse to mention another developer. https://github.com/jorgebucaran/colorette/issues/78
And he incorporated it into his benchmark to show that colorette is as fast as nanocolor.
It sounds like an important optimization.
If this wasn't copied, colorette would have been objectively worse than nanocolor.
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.)
I agree with you here, but aren't we talking about something else?
> But now suddenly a tiny fix
It's an impactful fix. Now colorette can claim that there's no performance difference between colorette and nanocolors.
If this fix wasn't there, colorette would be objectively slower than nanocolors.
If I am the user, I will choose the one that is faster, so this is an important improvement.
> is worthy of demanding attribution for?
Yes. Are you against both attributing each other accurately?
Nanocolors currently attributes colorette for the whole fork (albeit after being called out).
Colorette still refuses to attribute nanocolors specifically for this important performance improvement, even after being called out.
> That's really not the moment to go nitpicking the other guy.
Why not? The current topic is about improper attribution.
It's fair to look at improper attribution on both sides, not just one side.
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.
It seems many other comments claiming that attribution is only provided after being called out.
If Nano Colors are following all Colorette’s author asks, why he didn’t do it in return?
iskin on HN is Andrey Sitnik (ai).
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.
https://twitter.com/DerianAndre/status/1441851684095811585
As a "prolific and known" open source personality you'd think they'd be more careful? Their attitude since then has left a lot to be desired.
> Yes
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.
What are you referring to? (not rhetoric)
> Their attitude since then has left a lot to be desired.
That refers to the forker's attitude following the tweets[4][5].
[1]: https://github.com/ai/nanocolors/pull/14#issuecomment-927757...
[2]: https://user-images.githubusercontent.com/56996/135221889-52...
[3]: https://twitter.com/jorgebucaran/status/1442055448899641348
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 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.
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.
Copyright © Jorge Bucaran <https://jorgebucaran.com>
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.