Maintainers must not be able to change the license that original author chose, and based on which contributors made contributions. When one stepped up to be maintainer, it was a trustee role, not owner role.
It should be perfectly ok (by maintainer or anyone for that mater) to be inspired from a community project and build something from scratch hand-crafting/ AI sloping, as long as the imitation is given a new name/ identity.
What rubbed me off personally was maintainer saying "pin your dependncies to version 6.0.0 or 5.x.x", as if maintainer owns the project. maintainer role is more akin to serve the community, not rule.
If it is completely new, why not start a new project with new name? No one will object. And of course leave the old project behind to whoever is willing to maintain it.
And if the new name project is better, people will follow.
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.
Say a community builds a hall with an explicit intent of community use only, led by single person or a group, and then a person/ a group is appointed as a caretaker. Caretaker of the community hall decides unilaterally to convert the hall into a business convention center, razing old building to ground and rebuilding, disregarding community wishes, to make hall business friendly. How would you react to this situation? Caretaker has the ownership of the community assets, including the ground on which the hall is standing?
my understanding of the situation is:
Is the caretaker paying from his own pocket to maintain the hall? no
Is the caretaker paying from his own pocket for community usage of the hall? no
Is the caretaker spending time to maintain the community hall? yes
Is caretaker obliged to spend time on community hall? no
Is caretaker free to stop spending time on community hall? yes.
Is caretaker free to raze current hall, build new hall on same ground for new purposes WITH community agreement? YES
Is caretaker free to raze current hall, build new hall on same ground for new purposes WITHOUT community agreement (even if paying all the bill)? NO
Is caretaker free to build another similar hall someplace else? YES
Reasoning of your comment is of someone who is hell bent on staking claims on community resources (like big companies) without having slightest concern of the wishes or well-being of the community. Not sure of the commenter's motive either, given the new account with just two comments, supporting such blatant disregard of basic human decency.
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.
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.
Just one question, why maintainer is hell bent on using existing name and removing LGPL and not create an entirely new project by new name and new license (after all this is completely new code... right)?
First reason would be use the "name recall", and second guess would be to do another rug-pull to re-licence under some other conditions.
> It's owned by the maintainer
This is completely in-correct. GPL and variants (FOSS, not OSS) were meant to make software free of "any ownership".
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.
this guy's forked MIT'd version 0 will be as real and valid as version 6 of original chardet.
instead of
> Your fork of version 6 is just as real and valid as the MIT'd version 7!
Supporting for a decade is not a basis for unilateral takeover. In last 3 months there seem to be at least 3 other active contributors, any many dozens in past, who share the copyright on parts (ownership)
> nobody is entitled to this guy's pip account or GitHub account just because he rewrote the library
this guy's also not entitled to takeover what is communal, exactly in the same manner.
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.
Then we are back to... if this is a complete re-write, why not a new name for new code?
I guess it's futile to argue in this circular logic when full picture is not considered and argument are being put forward only for the sake of winning argument. Have a good $time_of_day.
> There's also a worrying underlying assumption being made here that the answers your LLM will give you are accurate and trustworthy.
I first hand saw in, AWS devDays, an AI giving SIWINCH as "root-cause" of Apache error in a containerized process is in EKS for a backend FCGI process connection error.
It has been extremely hard since that demo to trust any AI for system level debugging.
If we were smart we'd use AI to grok a system in order to help us reduce its complexity. I don't think we're anywhere close to even being able to provide all the necessary context to solve problems like this.
While this is a sound theoritical advice, the real world has changed a lot.
Parents and elder siblings are not the only people kids interact with. For every parent mindful of dangers of unsupervised internet access, there are many parents who give unrestricted access to tiktok (and rest of the internet) because everyone other person does that, and then kids share.
Businesses don't care for the careful minority when they know such advices will be shared, silencing those who really care.
Even the feature name "parental control" is chosen to induce guilt in parents.
>> Kernighan's Law - Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
Now question is..
is AI providing solutions smarter than the developer using it might have produced?
And perhaps more importantly, How much time it takes AI to write code and human to debug it, even if both are producing equally smart solutions.
Way back in 90's, when I arrived on an Indian Railway station about 10 minutes before the train's scheduled time, I was pleasantly surprised to find the train at the platform.
Only when I checked the passenger reservation list, I found this was train from yesterday, late by 23:50 hours.
(for the curious... No, I could not get my reserved birth and had to travel on unreserved ticket, but at least I reached destination on my planned time.)
DB last year: I took train last year from Frankfurt airport to Bonn only to see Bonn sail past the window and train to go to Cologne.
I asked locals what is going on, turns out that all trains were late, and this train departed from the platform already marked for Bonn! “You should watch what train number you board on DB, not trust sign on platform!” locals helpfully advised me.
I was in a similar situation in Egypt once. At the specified time a train arrives, I board it. Only to see that my seat is occupied. We started to discuss the situation and the other passenger showed me his ticket - it was one of the previous delayed trains. We figured it just in time for me to jump out of the wrong train before it left the station :)
This has certainly happened to someone if not the OP.
I did wait in a single spot for almost 10h, my 5-6h journey became a 15h one, in Serbia in the late 2000s. IIRC, a large part of the railway was down that day, couple hundred km, electricity issue or something. Some people walked off the train, which was in between cities but near the road. I was a student, didn't have an alternative, so I didn't. They didn't organize a replacement bus.
This kind of thing was (maybe not to that extent) common, like once every year or two. They rarely reported on it in media if the cause wasn't notable.
> I wrote this because everyone is talking about Claude Code right now and it's all over my timeline.
Feels more like peer pressure induced post, than evaluating a tool critically for pros and cons.
> Claude Code has this effect where you KNOW it's good but can't quite say WHY.
Definitely gives the "vibe" of social media's infinite scroll induced dopamine rush.
Overall, this post just seems to be enforcing the idea that "fuzzy understanding of business domain will be enough to get a mature product using some AI, and the AI will somehow magically figure out most non-functional requirements and missing details of business domain". Thing is that figuring out "most non-functional requirements and missing details of business domain" is where most of the blood and sweat goes.
It should be perfectly ok (by maintainer or anyone for that mater) to be inspired from a community project and build something from scratch hand-crafting/ AI sloping, as long as the imitation is given a new name/ identity.
What rubbed me off personally was maintainer saying "pin your dependncies to version 6.0.0 or 5.x.x", as if maintainer owns the project. maintainer role is more akin to serve the community, not rule.
If it is completely new, why not start a new project with new name? No one will object. And of course leave the old project behind to whoever is willing to maintain it. And if the new name project is better, people will follow.
reply