Not quite.

A and B in this case are both black boxes. The way clean room protocol works is to gaurentee that the surfaces of A and B are identical. Everything you can see, looks exactly the same. If however, you open up the boxes, you will very likely find entirely different contents that just happen to produce the same surface behaviour. If you were to clean room something, and produce identical A and B - i.e. not only is the behaviour exactly the same, but the code is exactly the same too, you would *very* likely find a court taking an extremely sceptical view of the idea that your clean room was in any way clean. That is, you'd still get found liable for the copyright infringement.

The purpose of the clean room is not merely to provide plausible deniability, it is to provide *actual* deniability. The thing you plead to the judge is not "Your Honor, we didn't look at the code, we pinky promise", it is "Your Honor, this can't be copyright infringement, look, the implementations are entirely different." The implementations necessarily will be different because without the system being trivially simple to the point of uncopyrightability, there are so many different ways to implement the same behaviour, that the chance of selecting the exact same one will be basically 0.

While your argument has some merits, there are counter arguments.

If I as a company hold patents, I will likely avoid GPLv3 code like the plague. I don't want to accidentally give up the rights to my patents because I happened to touch some GPLv3 code that was in vaguely the same area.

A good example of this would be Apple. They dropped bash for zsh, dropped gcc and wrote clang instead, dropped gdb and wrote lldb instead, dropped samba and wrote SMBClient and SMBX instead, dropped GNU tar and used libarchive/bsdtar instead, dropped GNU rsync and used openrsync instead,

- For zsh they appear to have contributed relatively little code upstream, but that's maybe expected for a mature project that is maintaining stability at this point rather than adding exciting new features.
- For gcc/gdb, they appear to have voluntarily given away *massive* amounts of code, clang and lldb simply didn't exist before Apple created them and open sourced them.
- For openrsync despite only having adopted it last year, they've contributed quite a lot of feature parity code to it (not just macOS compatibility code)
- For bsdgrep, it seems like you may be more right - it seems like Apple prefers to maintain a fork there rather than substantially contribute upstream.
- Samba seems to be a mixed bag - they went from a GPLv3 implementation to a BSD/APSLv2 client, and a proprietary server. The client they are contributing code actively. The server they're keeping all to themselves.
- For libarchive, it looks like Apple's made a ton of fixes, and contributed them upstream, same for bsdtar.

WebKit didn't replace a GPLed project, but Apple has written about 80% of the code in the repository, and licensed it mostly as BSD (with some licensed as LGPL to comply with KHTML's original licensing). BSD is their default license for new WebKit code.

With CUPS/OpenPrinting the story is similar - they adopted a GPLv2 project, relicensed it more permissively, and then proceeded to contribute massive amounts of code.

There's a bunch more cases of the same thing going on.
  - XNU - weak copyleft licensed, continues to upstream changes
  - Swift - permissively licensed, continues to upstream changes
  - libdispatch - permissively licensed, continues to upstream changes
  - mDNSResponder - permissively licensed, continues to upstream changes
  - dyld - weak copyleft licensed, continues to upstream changes
  - launchd - weak copyleft licensed, continues to upstream changes
  - Swift Foundation - permissively licensed, continues to upstream changes
  - bsd libc - BSDed apple contirbutes heavily upstream
  - OpenSSH - BSDed, apple contributes upstream
  - curl - BSDed, apple contributes upstream
  - sqlite - public domain, apple contributes upstream
  - libxml and libxslt - apple adopted them, and actively maintain them.
  - Heimdal - Apple appears to have forked it, the license remains BSD in their fork, and all their changes are there.
  - OpenPAM - looks like apple keeps its changes to itself here.

The overall picture is that despite all these BSDed projects, Apple in particular still contributes code upstream heavily. This is of course one anecdotal example, but at least from it, it doesn't appear that the motivating factor for changes being contributed upstream is being forced to with a copyleft license. Instead, it looks much more likely that it's simply that having the community all work together on single, standardised components is much more efficient for the industry than everyone having their own implementations, with incompatible quirks, bugs etc.

I don't think this is true. Generally court rulings on whether AI output is infringing have centred around whether the output looks like the copyrighted material, and have generally ignored whether the copyrighted material was included in the training data.

If the AI produces code that looks fundamentally the same as the original. It uses the same algorithms, the same structures, has the same performance characterestics, many of the same bugs etc, then you've almost certainly infringed copyright.

If the AI produces code that looks fundamentally different. It uses different algorithms, different acceleration structures, has different performance characteristics, has new and exciting bugs, but implements the same functionality, then you've almost certainly not infringed copyright

Because merely describing what something does is not the same as copying its source. Importantly, your description must say things like "the list must be sorted by the identity of the objects", not "use mergesort on the UUIDs of the objects"

1. Okay, lets assume you're right. Defendant is simply going to go "okay, well, we did some simple performance testing on A and B. A's algorithmic complexity came out to scale as n^1.89, while B's scales as n^1.16. Different algorithmic complexities can exist only where different algorithms are used, ergo, these use different algorithms, ergo, they haven't stolen the code." There's going to be a whole succession of this kind of thing that a court is going to look at and go "look, the code looks completely different, the performance characteristics are completely different, the functionality is even slightly different in these corner cases, how is this copyright infringement?"

2. There's already been several courts that have ruled that you can't look at individual inputs to an LLM's training data, and say "well, if 0.000001% of the training data was X, then the output of the LLM is X". More precisely, the rulings (GEMA vs OpenAI, NYT vs OpenAI, Doe vs Github, Getty vs Stability AI, ...) seem to paint a picture that what courts are finding important is "how similar is the output to the original". If your clean roomed implementation looks exactly like the original code, you're gonna have problems. If like above, it has different performance characteristics, different cope, subtly different functionality etc, you're likely not.

I don't really get why the open source guys would complain about this situtaion either. The entire *goal* of the open source movement was that I as a user ought to be able to take the software that I own, modify it, do what I like to it, fit it to my needs, make it work for me etc.

AI seems like a pretty massive step forward in getting there.

Legal arguments that involve *waves hands* "uhhh, it's just different." don't usually hold up very well.

No, not just clean room implementations of that code. By your logic, you can not ever work on any other project, because your knowledge of the original copyrighted work will taint the new project with its license. If I learn about a technique for organising multithreading while working on one project, and then apply something kinda vaguely similar at any point in the future, by your reasoning, I am now violating the original project's copyright.

Sounds like these users should all just use an OS that *will* do an account transfer from an old windows install, like many Linux distros, or macOS

Because we donâ(TM)t have enough good flock cameras. Everyone knows that the solution to something bad is more of the same thing but good. We clearly just need more good flock data and thatâ(TM)ll shoot the bad flock data.

Okay, and in 1969 the Navy installed an LM2500 with zero real world use. What makes you think that companies won't do that today?

I think you're imagining that large projects like this are like consumer products. They're absolutely not. Buying a system that is brand new, or very limited run is completely normal when you're buying things this large. You're not going to find one that's produced in the thousands.

To give you an example - Google are even planning on building these with CFS's fusion power plants. That's not just a completely untested design of an existing well understood mechanism, it's a completely untested design of a completely untested way of generating power, with a near century long history of "don't worry, we'll have it working in 20 years".

Gas turbines are extremely efficient. They are of the order of 60% thermally efficient, which if you're going to burn fossil fuels, is about as good as you can get. Of course, renewables would be better, but if you need power in a specific place, right now, gas turbines are about as good as you can do.

Right - "pivots" seems like the wrong way to frame this. They're not (yet) going "we're not going to build supersonic jets, we're going to build power plants", they're going "we need to develop a highly efficient, powerful jet engine, we can fund that by building power plants, and use that as a stepping stone to a supersonic jet".

I'm guessing you paid significantly more for those computers than if Sam Altman had not been involved. For many people, his buying power is enough to simply disallow buying a computer at all.