No right to relicense this project

- the outputs, even if correctly deduced, are often incompatible: "utf-16be" turns into "utf-16-be", "UTF-16" turns into "utf-16-le" etc. FWIW, the old version appears to have been a bit of a mess (having had "UTF-16", "utf-16be" and "utf-16le" among its outputs) but I still wouldn't call the new version _compatible_,

- similarly, all `ascii` turn into `Windows-1252`

- sometimes it really does appear more accurate,

- but sometimes it appears to flip between wider families of closely related encodings, like one SHIFT_JIS test (confidence 0.99) turns into cp932 (confidence 0.34), or the whole family of tests that were determined as gb18030 (chinese) are now sometimes determined as gb2312 (the older subset of gb18030), and one even as cp1006, which AFAIK is just wrong.

As for performance claims, they appear not entirely false - analyzing all files took 20s, versus 150s with v6.0. However, looks like the library sometimes takes 2s to lazy initialize something, which means that if one uses `chardetect` CLI instead of Python API, you'll pay this cost each time and get several times slower instead.

Oh, and this "Negligible import memory (96 B)" is just silly and obviously wrong.

The similarity is an established fact - the authors claim that this is chardet, to the extent that they are even using the chardet name!

Had they written a similar tool with a different name, and placed it in its own repo, we might be having a very different discussion.

You'd have to make that claim absent any proof and then there better not be any gross similarities between the two bodies of code that can not be explained away by coincidence.

And then there is such a thing as discovery. I've been party to a case like this and won because of some silly little details (mostly: identical typos) and another that was just a couple of lines of identical JavaScript (with all of the variable names changed). Copyright cases against large entities are much harder to win because they have deeper pockets but against smaller parties that are clearly infringing it is much easier.

When you're talking about documented protocols or interface specifications then it is a different thing, those have various exceptions and those vary from one jurisdiction to another.

What can help bolster the case for the defense is for instance accurate record keeping, who contributed what parts, sworn depositions by those individuals that they have come up with these parts by their lonesome, a delivery pace matching that which you would expect from that particular employee without any suspicious outliers in terms of amount of code dropped per interval and so on. Code copied from online sources being properly annotated with a reference to the source also helps, because if you don't do that then it's going to look like you have no problem putting your own copyright on someone else's code.

If it is real, then it is fairly easy to document that it is real. If it is not, after discovery has run its course it is usually fairly easy to prove that it is not if it is not.

https://repo.or.cz/tinycc.git/blob/3d963aebcd533da278f086a3e...

The interesting part is that the original author is against it but some people claims it could be a rewrite and not a derivative work.

I don't know the legal basis of everything but it's definitly not morally correct toward the original author.

> Unfortunately, because the code that chardet was originally based on was LGPL, we don't really have a way to relicense it. Believe me, if we could, I would. There was talk of chardet being added to the standard library, and that was deemed impossible because of being unable to change the license.

So the person that did the rewrite knew this was a dive into dangerous water. That's so disrespectful.