Hacker News: hoopyKt

New comment by hoopyKt in "No right to relicense this project"

hoopyKt — Fri, 06 Mar 2026 16:05:54 +0000

You're ignoring the part where the maintainer demonstrated that version 7 isn't a relicense of LGPL work but a complete rewrite based on public domain research and algorithms. That stack overflow article is irrelevant to this situation, and again, versions 6 and before have not been "taken over" they still exist exactly as they did a week ago and are still available to anyone that wants them in full license compliance. LGPL requires the source be made available, not that the source's distribution channels never be used for something else.

New comment by hoopyKt in "No right to relicense this project"

hoopyKt — Fri, 06 Mar 2026 14:09:23 +0000

Possibly they're "hell bent" on using the existing name because they've been using that name for their project in their github repository with their pip package that they've been supporting for a decade now. If they chose to make a new name, new package, new repo the current one would simply be abandonware. That's no different from what they're doing now, but with the added benefit of including a mechanism to inform their users of the situation.

You're acting like they've just swooped in in the last week to steal this repo out from under the community, when you have to go back to 2024 to see another person's name in the commits and to 2022 to see another person show up more than once. This one guy has been thanklessly maintaining chardet for years, decided to do a fresh rewrite and decided he'd like to use a different license now that the opportunity is here.

> GPL and variants (FOSS, not OSS) were meant to make software free of "any ownership".

And you're right! Version 6 and earlier is (functionally but not actually) free of "any ownership"! It still exists in this repo and out in the world! You can still personally fork it and make your own LGPL with a version 7 if that's the world you want to live in! If you don't want to use an OSS project using MIT you still have the community non-ownership of that code!

But you're not upset that the new code is MIT, you're upset that the new MIT code is using that name in pip and GitHub, but pip is MIT and GitHub is proprietary! The parts you're mad about were never LGPL! Because reminder! This code works outside of pip! Git is decentralized, this GitHub repository isn't the source of truth! Your fork of version 6 is just as real and valid as the MIT'd version 7! Your fork of version 6 can still be called chardet and will still work and is still community owned! You never had to use this guy's repo and this guy's pip publication! And nobody is entitled to this guy's pip account or GitHub account just because he rewrote the library, the community is entitled to the software and they still have it. This is all 100% valid under even the strictest FOSS license, much less LGPL.

New comment by hoopyKt in "No right to relicense this project"

hoopyKt — Fri, 06 Mar 2026 12:38:17 +0000

There is a certain irony here as well that this project was considered for actual community ownership by being added to the standard library, but it was decided that it was ineligible due to the LGPL license. Had this been MIT from the start you'd actually be correct about the community having some kind of ownership over how the project is operated, but that isn't the case here, it's not community owned. It's owned by the maintainer, it's their IP broadly and they can do as they wish within that LGPL license, including removing the LGPL licensed code.

New comment by hoopyKt in "No right to relicense this project"

hoopyKt — Fri, 06 Mar 2026 12:14:42 +0000

I think your metaphor is flawed though, firstly because we're not talking about the maintainer being a caretaker, for all intents and purposes they are the owner of chardet, just not a subset of the IP within, those are two separate entities here. Secondly, the original author doesn't have any ties to this project within the last decade, to imply that they're paying for it or have any ownership over how the project is operated beyond the scope of the license is just wrong.

If you'd want to correct the metaphor, this is a more accurate understanding of the situation:

Is the maintainer obligated to the terms of the original license? yes

Does the original IP holder have any rights beyond that license? no

Is the maintainer free to raze the current hall, as long as the IP-holder's property is appropriately removed first? YES

Now if it were to come out that ownership of the chardet name, pip package, or github organization were transferred to the maintainer under an agreement that the project always stay LGPL regardless of the actual terms of the license that's a whole other thing, but nobody has stated that is the case. The only contention is whether LGPL was violated by the rewrite under a new license, but if that's not the case it is entirely the prerogative of the project maintainers to do as they wish.

That's what free software is all about.

If the community wants the old "community hall" it still exists, they can still use it and do what they want with it. They have a right to the hall, but the maintainer has a right to the repository and the package name and one does not nullify the other.

New comment by hoopyKt in "No right to relicense this project"

hoopyKt — Fri, 06 Mar 2026 07:12:27 +0000

A distinction should be made between ownership of the code and its copyright and ownership of the repository and associated distribution channels. As far as I know, there's no precedent to state that owning the former means ownership of the latter. The original author abandoned this project years ago and likely has no legal basis to maintain that the project itself stays LGPL, only that their code and derivatives of it stay LGPL. Unless it could be proven otherwise, a rewrite of the project under a different license made without directly referencing the original is likely well within the rights of the owners of the repository to do.

New comment by hoopyKt in "No right to relicense this project"

hoopyKt — Fri, 06 Mar 2026 07:00:48 +0000

Further, while the copyright of the original code and its derivatives are still owned by the original author does that hold true to the rights to the name and package namespace? Supposing this were indisputably a clean room implementation instead of an unclear one, would the maintainers then have a right to relicense under the same name? I would imagine that yes, they do have the right to relicense in that case because the copyright only applies to the code, not the project itself.

Other questions that haven't really been explored before also are maintained: the original author hasn't been involved in some time, technically the copyright of all code since still belongs to those authors who might be bound by LGPL but are also the only ones with the right to enforce it and could simply choose not to. What then?