Comment Re:A better law (Score 1) 37
You miss the little detail where US law is not enforceable globally and most of the globe does not give a rat's ass about US law.
You miss the little detail where US law is not enforceable globally and most of the globe does not give a rat's ass about US law.
If you depend on everybody here being incompetent, you are dead wrong.
And every tool has a limited range of things where it can actually give you those productivity gains (if used correctly). It looks more and more like production code generation is NOT an area where you can get those improvements from an LLM.
Yes. There have been several attempts to automate software generation. When I studied CS, the 5GL project had just failed resoundingly. The idea was to write specs in constraint logic and then have the machine write code. What made it fail? Turns out writing a full spec is a lot more effort and requires significantly better qualifications and experience than writing the code directly. The idea of getting code automatically from a spec has since failed again with other approaches, essentially due to the same problem.
Now, LLM code generation has the same issue: If you do not explicitly specify it, you may or may not get security features, for example. Input validation, minimal privilege, authentication on APIs, secure session tokens, etc., may be there, may be there but insecure, or may be not there. But LLMs are worse: Even if you specify everything, the LLM may still omit stuff. And this can happen due to several different reasons, like window compression, training data claiming to do one thing, but not actually doing it, etc. Hence LLMs are _worse_ than those failed previous attempts.
Essentially, LLMs are just a way to make software creation more risky, more expensive and more stressful (reviewing LLM code is apparently a really bad experience). Or you can make cheap, somewhat functional code that is an insecure, unmaintainable, intransparent mess.
The problem is not on the tech side. The problem is on the legal side. The problem is that LLM code does not get new copyright. If nobody was copied close enough, LLM code does not qualify for copyright and you cannot slap a license on it. But if it is close enough to something in its training data, it will very likely be found to be still unter the original copyright, license and ownership. And that is a legal nightmare.
Yes, this nuke may need a few years to detonate. But anybody that followed the SCO lawsuits should understand how potentially catastrophic this is. Only requiring a tag was already a pretty bad decision, but it would at least have allowed triage and ripping stuff out. And if a contributor had been lying and omitting the tag, the person liable would likely have been that contributor. But if the tag is optional, that responsibility shifts to the maintainers. Not good at all.
Now, it is possible this will not blow up. But risking it like that is just one thing: Deeply stupid.
Exactly. Linus is creating a potentially catastrophic legal problem here. And he does so after the GCC folks have clearly explained the problem. Stupid. Or maybe he is getting old and does not care that much anymore.
The problem is not with code quality. The problem is with copyright and license. They are currently falling into a potentially deadly trap, same as anybody that accepts LLM generated code.
Exactly. If you allow LLM generated code in your project, you may lose it completely. Suddenly it may be under a different license, or, worse, several different ones. And your ownership and original license may be gone. The GCC folks understand that catastrophic risk. It looks like Linus does not or does not want to deal with it. That does not work and is an exceptionally bad idea.
The absolutely very least and lowest level of caution would be mandatory tagging of all LLM written code. Because with that you at least have a chance to rip it out (at great cost) later. But if you do not even do that, you will very likely kill the project long-term.
An LLM is not a compiler or a valid step between specification and code, unless you put a lot of safeguards and extra effort in place. First, an LLM comes without specification of what it will do. The Language specification a compiler is based on is critical for it to be useful at all. Otherwise you have no reliable idea what the compiler will do with some input and things may change without warning. For an LLM, this is even worse: Things may change between one run and the next and things may change an entirely different place when you add or change something in one place. The whole process is opaque and not actually well understood.
Second, LLMs hallucinate and they do it in surprising and unpredictable ways. And third, an LLM may arbitrarily decide to leave out stuff that is important, even when you specified it. This is devastating for all security properties and for general reliability.
Hence while Linus is not generally wrong, he vastly overestimates the result quality and performance of LLMs.
And on the legal angle, there is a very good reason why the GCC folks have done a categorical "no" to LLM code. Depending on how the legal battles go, some LLM code may end up being owned by the original owners of the training data before it was stolen. The very least you need to do to prepare for that possibility is being able to identify it all to be able to rip it out. Making the tag optional is exceptionally foolish. Sure, people can lie about that tag, but then it is on them. But if you make it optional, that is on you.
No, a good lawyer would explain why unlawful restraint doesn't apply in this case.
Section 2903 seems written such that "another" means a natural person (someone who has "liberty", as a robot generally does not, because it is chattel). PA law classifies delivery robots as pedestrians for the purpose of Title 75 of state law, not as people or "another" under Title 18. Do you have some precedent that says false imprisonment can be committed against a robot?
Not because of patch quality, the quality gates on the kernel are fine. It is a really bad idea because of copyright. Depending on how the copyright battle in the courts goes, this may seriously taint the kernel and removal of the tag may make cleanup impossible.
Shows that Linux, unfortunately, does not understand the legal angle.
No law says that, just like no law says you as a pedestrian have the right of way over other pedestrians; it says who must yield the right of way. Regardless of who has the right of way, neither you nor professors are generally allowed to block other pedestrians from proceeding down a sidewalk. In Pennsylvania, it doesn't matter if the other pedestrian is a delivery robot.
As for Islamic countries, there's only two that ban women from driving: Afghanistan and Turkmenistan - both de facto / arbitrary / adminstrative bans rather than official bans (e.g. refusing to issue/renew licenses, requiring guardians for long-distance travel, or things of that nature). Saudi Arabia revoked their ban in 2018. And Iran has always allowed women to drive (though they have to cover their hair while driving).
The biggest difference between time and space is that you can't reuse time. -- Merrick Furst