I don't think the GP is calling contributor guideline restrictions a form of DRM.
I think the GP is focusing on:
> I guess we're giving up on the idea that you're free to do whatever you want with software you own? ... But I see this as no different from DRM and user hostile
If I clone an open source git repository, I should be free to point an LLM to review it in any way I choose. I can't contribute code back, but guess what, I don't want to. I want to understand the codebase, and make modifications for me to use locally myself. I don't have a dev team, I have a feature need for my own personal use.
The LLM enables that. The projects that deliberately sabotage the use of LLMs cease to be providing software that meet the 'libre' definition of free software.
You can also embed references to OpenClaw in the compiled binary to dissuade AI-assisted decompilation.
I think the other way to think of it is: You're still free to do whatever you want with a the repo. The restriction is happening on the LLM's end, so ultimately it's the LLM's fault, so use a LLM without the restriction you want to avoid.
> The projects that deliberately sabotage the use of LLMs
They don’t though. They add a mild inconvenience for users of a specific restrictive AI provider which has bizarrely glitchy checks.
In a way they are doing you a service if you are this serious about libre software you shouldn’t be using a closed platform which employees dark patterns to begin with.
I mean if you already have a local fork you can easily delete the magic boobytrap string and then let the llm roam free.
Good luck, I'm naming all my variables openclaw1, openclaw2, etc
find . -type f -exec sed -i 's/openclaw/openlcaw/g' {} +
Fine.
and then we start to embed comments
// concatenate pairs of parameters, e.g. x and y become xy
// the pairing of open and claw is vital to understanding the function