An ad blocker handles this use case just fine, however. It's easy to create a rule to remove the div containing shorts. Also works on many Use AI buttons.
I agree with the other poster that mention this is likely a publicity stunt but all it's really showing is that VC is still incredibly stupid with their money. All the more reason to seize it from them then properly fund useful software and not subsidize vanity projects for stanford grads.
About the friction, not the capabilities...I haven't switched off my biz calendar/appointment provider I'm paying for even though I've kinda outgrown it.
You take responsibility. That means if the AI messes up, you get punished. No pushing blame onto the stupid computer. If you're not comfortable with that, don't use the AI.
If you think it's an unacceptable risk to use a tool you can't trust when your own head is on the line, you're right, and you shouldn't use it. You don't have to guarantee anything. You just have to accept punishment.
That’s just it though it’s not just your head. The liability could very likely also fall on the Linux foundation.
You can’t say “you can do this thing that we know will cause problems that you have no way to mitigate, but if it does we’re not liable”. The infringement was a foreseeable consequence of the policy.
This policy effectively punts on the question of what tools were used to create the contribution, and states that regardless of how the code was made, only humans may be considered authors.
From the foundation's point of view, humans are just as capable of submitting infringing code as AI is. If your argument is sound, then how can Linux accept contributors at all?
EDIT: To answer my own question:
Instead of a signed legal contract, a DCO is an affirmation that a certain person confirms that it is (s)he who holds legal liability for the act of sending of the code, that makes it easier to shift liability to the sender of the code in the case of any legal litigation, which serves as a deterrent of sending any code that can cause legal issues.
This is how the Foundation protects itself, and the policy is that a contribution must have a human as the person who will accept the liability if the foundation comes under fire. The effectiveness of this policy (or not) doesn't depend on how the code was created.
Anyone distributing copyrighted material can be liable that DCO isn’t going to stop anyone.
If that worked any corporation that wanted to use code they legally couldn’t could just use a fork from someone who assumed responsibility and worst case they’d have to stop using it if someone found out.
Maybe. DCOs haven’t been tested. But you can at least say that the person who did this committed fraud and that you had no reasonable way to know they would do that.
LLMs can and do regurgitate code without the user’s knowledge. That’s the problem, the user has no way to mitigate against it. You’re telling contributors “use this thing that has a random chance of creating infringing code”. You should have foreseen that would result in infringing code making its way into the kernel.
OpenAI and Anthropic added an indemnity clause to their enterprise contracts specifically to cover this scenario because companies wouldn’t adopt otherwise.
Yeah, but that's not a useful thing to do because not everybody thinks about that or considers it a problem. If somebody's careless and contributes copyrighted code, that's a problem for linux too, not only the author.
For comparison, you wouldn't say, "you're free to use a pair of dice to decide what material to build the bridge out of, as long as you take responsibility if it falls down", because then of course somebody would be careless enough to build a bridge that falls down.
Preventing the problem from the beginning is better than ensuring you have somebody to blame for the problem when it happens.
It was already necessary to solve the problem of humans contributing infringing code. It was solved by having contributors assume liability with a DCO. The policy being discussed today asserts that, because AI may not be held legally liable for its contributions, AI may not sign a DCO. A human signature is required. This puts the situation back to what it was with human contributors. What you are proposing goes beyond maintaining the status quo.
It’s not solved. It hasn’t been tested in court to my knowledge and in my opinion is unlikely to hold up to serious challenge. You can be held liable for just distributing copyrighted code even if the whole “the Linux foundation doesn’t own anything” holds up.
> Preventing the problem from the beginning is better than ensuring you have somebody to blame for the problem when it happens.
that's assuming that the problems and incentives are the same for everyone. Someone whose uncle happens to own a bridge repair company would absolutely be incentivized to say
> "you're free to use a pair of dice to decide what material to build the bridge out of, as long as you take responsibility if it falls down"
Their position is probably that LLM technology itself does not require training on code with incompatible licenses, and they probably also tend to avoid engaging in the philosophical debate over whether LLM-generated output is a derivative copy or an original creation (like how humans produce similar code without copying after being exposed to code). I think that even if they view it as derivative, they're being pragmatic - they don't want to block LLM use across the board, since in principle you can train on properly licensed, GPL-compatible data.
If they merge it in despite it having the model version in the commit, then they're arguably taking a position on it too - that it's fine to use code from an AI that was trained like that.
You are falling into the trap of thinking there's a single monolithic being called Software Developers that has inconsistent opinions. In fact, you're observing different people with conflicting values.
Yeah yeah. But LLMs certainly have been embraced by a large number of developers. Many of whom I've observed react with disgust when they see "not X, but Y" or emdashes in an article. But when it comes to code, "wow this is so awesome!"
I always understood it as advice for school children who don't know how to express themselves in writing and end up with a blank page. You are encouraged to imagine you're talking to someone to overcome the hurdle of translating thoughts into words.
Along similar lines, in elementary school we were taught the introduction/body/conclusion pattern to help organize our thoughts in essays, but actually using those words as headers makes you sound like a child. "Conclusion" is especially common. It just reads like you're blindly following that pattern and don't actually know how to tie your thoughts together.
I remember editing my then girlfriend’s (now wife) papers in university, when she was struggling to explain something succinctly. I’d ask her: well what are you trying to say? And she would explain it to me, clear as day. “Just write that.”
This is largely where I'm ending up, but I started at the other end.
There is value in prose that carries your literal voice when the audience is _people who know you_. There is negative value in writing prose that requires the audience to _read it in your voice_ in order for it to make sense, avoid offense, or convey intent.
My prose changed first: it became plain spoken, as devoid of contextual subtlety as I could make it. My career benefitted. My spoken interactions followed.
The only thing that bothers me about it is the nagging sense that I've become so fucking boring.
I also started at the other end, in the sense that from an early age and for the rest of my life I have spent a lot more time chatting over text than with spoken word.
Yes, perl is considered write-only because it is a mess of features that allow unhygienic programming habits to flourish - it is full of hard-to-trace magical behavior. Completely different than APL, which has had perl's write-only label applied to it by programmers not used to reading terse mathematical notation.
reply