Hacker News Reader

Comment by ctvo | Hacker News Reader

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

The problem with this behavior is as follows:

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

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

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

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

View on HN

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.

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

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

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

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

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

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

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

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

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

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

From the guidelines:

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

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

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.

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.

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

Many legal things are immoral.

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

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

So he was straight up lying?

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

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

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

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

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

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

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

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

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

In addition to what others have pointed out:

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

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

Reply on news.ycombinator.com