I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark. [LWN.net]

I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark.

Posted Mar 26, 2026 16:40 UTC (Thu) by bertschingert (subscriber, #160729)
In reply to: I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark. by koverstreet
Parent article: Vibe-coded ext4 for OpenBSD

> The bigger concern with LLMs writing code is maintainability and refactoring.

Not to mention the more fundamental question of whether writing new code is the right way to solve a problem. This snippet from the conversation seems pretty important:

On Mon, Mar 23, 2026 at 08:32:43AM +0000, Stuart Henderson wrote:
> On 2026/03/23 03:45, Thomas de Grivel wrote:
> > I did check everything and it did look like ext2fs code with minor
> > modifications that I fully understand to support ext4 extents and
> > checksums it's not that big of a deal : ext4 is just ext2 with 64 bit,
> > different checksums and extents tree walking.
>
> Why standalone rather than done as diffs to ext2fs?

If a tool makes it extremely easy to generate lots of code, then people will tend to solve problems by generating lots of code. I already see this with my coworkers writing multi-thousand-line programs to do something that could be done with a short bash script combining existing tools. As a sysadmin, every new program I have to read, understand, and maintain is another burden.

to post comments

I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark.

Posted Mar 26, 2026 21:45 UTC (Thu) by ballombe (subscriber, #9523) [Link] (3 responses)

> If a tool makes it extremely easy to generate lots of code, then people will tend to solve problems by generating lots of code. I already see this with my coworkers writing multi-thousand-line programs to do something that could be done with a short bash script combining existing tools. As a sysadmin, every new program I have to read, understand, and maintain is another burden.

Exactly. I start to receive LLM-generated patches that are the equivalent of the coreutils maintainers receiving a patch labelled "cp: add --url option to copy remote files, like cp --url https://lwn.net/ lwn.html", the end result being that every software will blow up to include a unmaintainable and barely working reimplementation of every other, with both an editor AND a MTA.

I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark.

Posted Mar 26, 2026 22:43 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

Haven't you forgotten a complete functional copy of emacsOS? :-)

Cheers,
Wol

I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark.

Posted Mar 28, 2026 0:00 UTC (Sat) by vmanis (subscriber, #163384) [Link] (1 responses)

And, per Greenspun, an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark.

Posted Apr 1, 2026 18:47 UTC (Wed) by dgm (subscriber, #49227) [Link]

Ah, the good ol' AIBS-Common Lisp!

I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark.

Posted Mar 31, 2026 18:05 UTC (Tue) by marcH (subscriber, #57642) [Link] (9 responses)

This.

In just a few decades, we went from "code-reuse is hard" to "code-reuse is too easy and insecure" https://queue.acm.org/detail.cfm?id=3344149. But fighting against duplication to reduce high maintenance costs was a constant concern the whole time.

So today's newest trend is... back to massive duplication! Everyone's is re-inventing "20 years of work in 20 hours" but... who is going to debug and fix these huge amounts of code? Getting in someone else's head to debug their code is hard enough, good luck debugging code generated by copy/paste on steroids. Human bugs follow certain patterns (which LLMs are great at spotting, now _that_ is a great use case) but I bet LLM-generated bugs are much less predictable.

Assuming LLMs are able to help with the debugging and fixing too, how's that more efficient and economical than good old code re-use?

===> Who needs that much code? <====

I just don't get it. Not so long ago I read somewhere some devops joke that went something like "I don't write production code any more, just build scripts and yaml configuration files gluing existing code together." What happened since?

Granted, there are some "throw-away" / "once-off" use cases where all this duplication and generated code look useful: prototyping, learning, niche use cases with very few users,... But working around copyright and licences does not exactly look like technical progress. Also, once you have one GPL and one BSD implementation of ext4, how many more ext4 duplicates do you need?

I'm aware some boilerplate and duplication is required across drivers in the same OS. That looks like a good use case for automated generation but 1. it's again a fairly specific use case and 2. good driver frameworks should require very little boilerplate. Fix the driver framework instead.

I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark.

Posted Mar 31, 2026 19:22 UTC (Tue) by mb (subscriber, #50428) [Link] (1 responses)

Duplicating the existing ext* code is exactly how it was done on Linux, too, initially.
This has nothing to do with AI.
It totally makes sense not to touch good working code, expecially if it's as critical as filesystem code.

I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark.

Posted Mar 31, 2026 21:15 UTC (Tue) by marcH (subscriber, #57642) [Link]

> Duplicating the existing ext* code is exactly how it was done on Linux, too, initially [...] It totally makes sense not to touch good working code

Duplication == divergence which _is_ touching code.

"Copy/Paste" should really be spelled "Copy/Paste/Diverge". The 2-words form is missing the most important keyword and entire problem! I'm pretty sure that's why so many developers underestimate duplication issues: because language shapes the way we think. One of the most hilarious developer lies: "we will keep these duplicates in sync".

Branching and forking (the same thing) are "divergence under control" where merging (and rebasing) are the most important features: because they control _divergence_. Yet again, version control literature wrongly uses the term "branching" much more than "merging" - even when discussing merging.

Good luck keeping AI copy/paste/diverge under control. The copyright meltdown is the only good engineering news.

Note I have zero concern with other uses of AI, like AI code reviews for instance. These seem quite useful. Repeating "Did you run checkpatch / the tests / the linter / etc.?" to every new contributor (multiple times for some contributors...) is pre-existing and hard to avoid "duplication". Better let robots handle all those repetitive jobs. Great news. Finding bugs and vulnerabilities looks awesome too. Static analyzers had their chance! And they are not mutually exclusive.

But if _coding_ was a very repetitive job, then something was wrong in the language / framework / tooling in the first place and AI looks like a terrible workaround. "Code re-use" has been one of the top industry topics since software was invented. And it just vanished now that AI came on the scene? Stunning.

If coding involves a _small_, reasonable amount of repetition, then AI does not save much.

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark.

Posted Apr 15, 2026 12:01 UTC (Wed) by QxDEADBEEF (guest, #175948) [Link] (6 responses)

I am pretty sure that you can direct the AI to not re-invent the wheel. I have been using AI tools to refactor code which is referred in multiple parts of the project and also I have been using AI to write small and well defined parts of a project. In both cases the AI tool used an existing function for both the refactoring and the new code implementation.

I see the current capabilities of AI tools like a junior inexperience developer who starts immediately with the implementation of the code and tries to re-invent all the well knows algorithms. I have seen common known sorting algorithms being implemented (of course wrongly) when instead a relevant library is available for use.

I believe we all have been in this situation when we were young developers.

So I believe the issue is not with the AI tools but with the instructions that we provide to them (e.g. prompts, skills, methodology) and the datasets that are trained.

I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark.

Posted Apr 15, 2026 12:17 UTC (Wed) by pizza (subscriber, #46) [Link] (4 responses)

> So I believe the issue is not with the AI tools but with the instructions that we provide to them (e.g. prompts, skills, methodology) and the datasets that are trained.

So... "everyone is using/creating the tools wrong".

But it's totally not the tools themselves.

Sure.

I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark.

Posted Apr 16, 2026 6:27 UTC (Thu) by QxDEADBEEF (guest, #175948) [Link]

I didn't used the correct wording.

"So I believe the issue is not only with the AI tools..."

My point is that like any other tool there is the correct way of using it and the wrong one.
Unfortunately in case of the AI tools the ambiguity of the user's input does not result to an error (e.g. like using a programming language wrongly which results to compiler error) but instead the AI makes guesses which results to wrong solutions.

I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark.

Posted Apr 17, 2026 12:51 UTC (Fri) by cpitrat (subscriber, #116459) [Link] (2 responses)

> So... "everyone is using/creating the tools wrong".

It's not a very charitable reading of what was said.

Understandably, people are learning how to use AI properly (in the same way that people had to learn how to use programming languages properly). And at the same time, AI is evolving (in the same way that programming languages evolved, though less transparently: you don't have a new version of a language or a new language. At best you have a new model, but you also get changes you're bot aware if like prompt evolving, integration with tools changing, etc ...)

It will take time for clarifying what "using AI properly on task X" means and in the meantime, there are conflicting views and arguably, yes, nobody is using it correctly.

I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark.

Posted Apr 17, 2026 13:21 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> Understandably, people are learning how to use AI properly

Are they really, though?

They are using these LLM tools in the way their vendors suggest, ie "let the LLM do all the [hard] thinking/work/etc"

I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark.

Posted Apr 18, 2026 14:01 UTC (Sat) by marcH (subscriber, #57642) [Link]

Users, vendors, others,... I don't think "who is to blame" matters much in the grand scheme of things. Experimentation is inevitable and that's a good thing, it's the only way we learn:

https://www.ted.com/talks/tim_harford_trial_error_and_the...

Sure, some people involved with AI will come out richer (gold rush/shovels) while others will be poorer but that's hopefully just a "1st world problem".

I'm concerned about duplication and un-debuggable technical debt. And rising costs of energy at a time when we've reached "peak oil" and only decades away from "peak fossil/dictator fuel". But it doesn't really matter who's to blame because as long as something is more or less legal then there will always be some people doing it. There is no "People should just...". Every sentence beginning like this is very ignorant of human nature.

Taxes are a good tool in situations like this, often better than bans. For instance: make data centers pay more for electricity than households. Tariffs work too - unless you ask an LLM to write them :-D

I can't help but feeling like if we're just going to be talking about copyright, we've jumped the shark.

Posted Apr 15, 2026 13:39 UTC (Wed) by marcH (subscriber, #57642) [Link]

Thanks for sharing!

It's difficult to find good software productivity metrics. One metric we heard a lot - hopefully less often now[*] - is: number of new lines of code per day. I hope this was a "streetlight effect": looking at that particular metric because it's a simple metric despite it measuring the "wrong" thing. Yet I heard it from many managers and even from some "respected" developers... :-(

Using AI to automate refactorings or to find bugs sounds great, I'm all for it. Throw-away prototypes and some other uses are fine too. But every experienced software developer should cringe when hearing "Look at how many lines of code I can write per day!". It does not matter whether all this new code is reviewed by humans or AI or both: duplication is a massive waste, period.

[*] Claude Mythos seems to be affecting the focus and news cycle right now. Great.