Right after posting this I saw the previous post in this community linking to some slides which let me know that my info is outdated: https://riscv-europe.org/summit/2024/media/proceedings/plenary/Tue-11-30-Krste-Asanovic.pdf

Some platform standards have now been ratified, I think? Though I'm not sure if I'm reading right; that might refer only to the architecture profiles.I don't know if any shipping hardware supports them yet, though. The kernel drivers situation still remains tricky because upstreaming takes time and many of these chips are pretty new.

I'd be happy to be corrected on any of this, but I think right now there are two main problems that make what you want challenging to achieve:

• Few, if any, RISC-V SOCs have enough drivers in the mainline kernel tree for a generic kernel build to be workable today. The installers for mainstream distros run on the Linux kernel and so cannot run if there is not sufficient driver support.
• On x86_64 hardware there is a baseline set of expected platform hardware and a standard boot process, which general-purpose distribution installers rely on to get running enough to get the remaining needed software installed, and then once installed again the standard boot process means that distributions can ship a single bootloader that works across many different systems. Last time I checked (admittedly a while back now) the RISC-V general purpose platform spec -- describing such things as what operating systems can expect from UEFI firmware when running on RISC-V -- is still under development and not implemented on most (any?) shipping SOCs or boards.

The first problem is probably the harder one to deal with. For the second it is in principle possible to arrange for the SOC's boot process to jump into a port of a UEFI implementation that has sufficient driver support to get the OS's own bootloader started, but then the OS can't do much if it doesn't even have drivers for necessities such as USB and graphics.

With that said, I think the main special thing in these board-specific Linux distro images is a custom kernel with not-yet-upstream drivers compiled in, and so if that kernel is new enough it is likely possible to get another distribution's userspace running on top of it, using tools like Debian's debootstrap. It's nowhere near as mainstream-ready as we're accustomed to with x86_64, though.

(I've answered for RISC-V only here because I've been paying more attention to the situation there than on Arm, but I have the sense that the Arm situation is similar aside from the platform spec being further along, and some companies are shipping expensive server-class hardware that supports it.)

The more I thought about the interior references part the more questions I had! For example:

• The actual characters in a String belong to a dynamic memory allocation rather than to the String object itself, so the lifetime of &str references into there is "until any operation that might change the size of the allocation". Since that level of detail doesn't seem visible to to the type system even with the discussed addition, I guess it would reduce just to disallowing any mutable reference to the string so that its content cannot possibly move to a new allocation while the internal references are live. 🤔
• I also thought about the idea that a reference whose lifetime is related to another field in the same object could be represented as an offset from the object's address rather than an absolute pointer and then generate relative accesses when dereferencing, but that would mean that the referents would need to always live inside the object itself, and not in a dynamic allocation as would be the case for &str into a String.

So, with all of that said, I'd love to read an article with more details on that part!

It's nice to see this starting to get tested in court.

I doubt this will really upset "Hollywood Studios" too much, though. They are unlikely to be creating entire productions using ML techniques, and instead using it for smaller parts of an overall production. It seems like e.g. generating a voice or image for one part of a film would not invalidate copyright on other parts of the work or of the overall work taken together.

Film studios also rely on other non-copyright protections such as trademarks to dissuade derivative works.

I think the bigger test will be: is it copyright infringement to use a work as part of a training set for a model? It's all very well saying that the output is not copyrightable, but there's still a big question about the input.