FastAPI's underlying library, Starlette, has been going through licensing shenanigans too lately: https://github.com/Kludex/starlette/issues/3042
Be really careful who you give your projects keys to, folks!
No right to relicense this project
11–20 of 388 posts
Re: No right to relicense this project
#12I torn on where the line should be drawn. If the code is different but API compatible, Google Java vs Oracle Java case shows that if the implementation is different enough, it can be considered a new implementation. Clean room or not.
That whole clean room argument makes no sense. Project changed governance and was significantly refactored or reimplemented... I think the maintainers deserve to call it their own. Original-pre MIT release can stay LGPL.
I don't think this is a precedent either, plenty of projects changed licenses lol.
I keep kind mixing them up but the GPL licenses keep popping up as occasionally horror stories. Maybe the license is just poorly written for today's standards?
Re: No right to relicense this project
#13As part of my consulting, i've stumbled upon this issue in a commercial context.
A SaaS company who has the mobile apps of their platform open source approached me with the following concern.
One of their engineers was able to recreate their platform by letting Claude Code reverse engineer their Apps and the Web-Frontend, creating an API-compatible backend that is functionally identical.
Took him a week after work. It's not as stable, the unit-tests need more work, the code has some unnecessary duplication, hosting isn't fully figured out, but the end-to-end test-harness is even more stable than their own.
"How do we protect ourselves against a competitor doing this?"
Noodling on this at the moment.
Re: No right to relicense this project
#14Sounds like they didn’t build a proper clean room setup: the agent writing the code could see the original code.
Question: if they had built one using AI teams in both “rooms”, one writing a spec the other implementing, would that be fine? You’d need to verify spec doesn’t include source code, but that’s easy enough.
It seems to mostly follow the IBM-era precedent. However, since the model probably had the original code in its training data, maybe not? Maybe valid for closed source project but not open-source? Interesting question.
Re: No right to relicense this project
#15I torn on where the line should be drawn. If the code is different but API compatible, Google Java vs Oracle Java case shows that if the implementation is different enough, it can be considered a new implementation. Clean room or not.
That whole clean room argument makes no sense. Project changed governance and was significantly refactored or reimplemented... I think the maintainers deserve to call it their own. Original-pre MIT release can stay LGPL. I don't think this is a precedent either, plenty of projects changed licenses lol. I keep kind mixing them up but the GPL licenses keep popping up as occasionally horror stories. Maybe the license is…
No. Because they couldnt have done any of that refactoring without a licence to do so, and that licence forbids them from relicencing it.
Re: No right to relicense this project
#16Sounds like they didn’t build a proper clean room setup: the agent writing the code could see the original code. Question: if they had built one using AI teams in both “rooms”, one writing a spec the other implementing, would that be fine? You’d need to verify spec doesn’t include source code, but that’s easy enough. It seems to mostly follow the IBM-era precedent. However, since the model probably had the original c…
This seems right to me. If you ask a LLM to derive a spec that has no expressive element of the original code (a clean-room human team can carefully verify this), and then ask another instance of the LLM (with fresh context) to write out code from the spec, how is that different from a "clean room" rewrite? The agent that writes the new code only ever sees the spec, and by assumption (the assumption that's made in all clean room rewrites) the spec is purely factual with all copyrightable expression having been distilled out. But the "deriving the spec (and verifying that it's as clean as possible)" is crucial and cannot be skipped!
Re: No right to relicense this project
#17As part of my consulting, i've stumbled upon this issue in a commercial context. A SaaS company who has the mobile apps of their platform open source approached me with the following concern. One of their engineers was able to recreate their platform by letting Claude Code reverse engineer their Apps and the Web-Frontend, creating an API-compatible backend that is functionally identical. Took him a week after work. I…
The famous case Google vs Oracle may need to be re-evaluated in the light of Agents making API implementation trivial.
https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....
Re: No right to relicense this project
#18Sounds like they didn’t build a proper clean room setup: the agent writing the code could see the original code. Question: if they had built one using AI teams in both “rooms”, one writing a spec the other implementing, would that be fine? You’d need to verify spec doesn’t include source code, but that’s easy enough. It seems to mostly follow the IBM-era precedent. However, since the model probably had the original c…
Yeah I think, the Compaq / IBM precedent can only superficially apply. It would be like having two teams only meet in a room full of documentation - but both teams crammed the source code the day before. (That, the source code you are "reverse engineering" is in the training data.) It doesn't make sense.
Also, it's weird that it's okay apparently to use pirated materials to teach an LLM, but maybe not to disseminate what the LLM then tells you.
Re: No right to relicense this project
#19I torn on where the line should be drawn. If the code is different but API compatible, Google Java vs Oracle Java case shows that if the implementation is different enough, it can be considered a new implementation. Clean room or not.
That whole clean room argument makes no sense. Project changed governance and was significantly refactored or reimplemented... I think the maintainers deserve to call it their own. Original-pre MIT release can stay LGPL. I don't think this is a precedent either, plenty of projects changed licenses lol. I keep kind mixing them up but the GPL licenses keep popping up as occasionally horror stories. Maybe the license is…
> plenty of projects changed licenses lol.
They usually did that with approval from existing license holders (except when they didn't, those were the bad cases for sure).
Re: No right to relicense this project
#20Sounds like they didn’t build a proper clean room setup: the agent writing the code could see the original code. Question: if they had built one using AI teams in both “rooms”, one writing a spec the other implementing, would that be fine? You’d need to verify spec doesn’t include source code, but that’s easy enough. It seems to mostly follow the IBM-era precedent. However, since the model probably had the original c…
> Sounds like they didn’t build a proper clean room setup: the agent writing the code could see the original code.
It doesn't matter how they structure the agents. Since chardet is in the LLM training set, you can't claim any AI implementation thereof is clean room.