Arguments that Broadcom is forcing their hand on this simply don't add up. It's not Broadcom that's stopping them from publishing even basic schematics of the board; that was their decision. Sure, they'd never be able to open the chip itself, but nobody is particularly asking them to (it's not like people have fabs in their garages).
Moreover it's pretty clear at this point that Broadcom is making SoCs custom-order for rpi at this point; see their original announcement on the rpi4, which makes it quite clear they were involved in the design process. Based on what I know about Broadcom's MO, it's simply not plausible that with that amount of money on the table, release of datasheets and register manuals couldn't be negotiated; it seems clear it's not a priority for rpi.org.
And as mentioned, rpi boards include vendor-lockin DRM in their binary blob boot firmware designed to prevent people from using third-party camera boards.
Not only is this unacceptable in itself, it also means rpi is actively depending on this boot firmware remaining closed, else people could easily remove this antifeature. People have been hoping for years that the firmware blobs required to boot the boards will eventually be opened, and pointed to some vague noises in this direction which were made by rpi.org years ago, but the fact that they're now relying on the fact of it being closed to enforce DRM causes me to find this increasingly unlikely.
I have worked with much more mundane integrated circuits where the manufacturer required you to sign an NDA before getting any kind of design support from them. One of the terms of the NDA was not publishing the schematic of the device using their product. I don't see why Broadcom wouldn't do something similar for their SoCs.
Broadcom is notorious for demanding NDAs for their datasheets, completely pointlessly. I've also heard of companies demanding their parts be redacted on schematics if published, even more ridiculously, though as far as I know Broadcom isn't one of them (I've seen public schematics with Broadcom parts).
Still, from what I've heard of Broadcom specifically, they're pathologically secretive with their documentation unless some star customer dangles enough money in front of them. rpi.org certainly fits that description. So I don't really buy this excuse for rpi here.
In reality, I suspect it's more the fact that rpi.org was started by ex-Broadcom engineers and they brought their culture of secrecy with them.
Yet the chips weren't sold by any distributor. To even just get engineering samples from the manufacturer you had to sign this draconian NDA that covered everything from software to hardware docs even remotely connected to their part. Even after signing the NDA they wouldn't disclose full datasheet for e.g. what some registers did. For some things the comments in the Linux kernel turned out to be more informative than anything we got through official channels.
But if they're the only source of parts you have to use, you have to dance by their rules. Ruin the relationship by breaching the NDA and you might just as well bury the product you spent a year developing.
It is open to a degree:
https://www.raspberrypi.org/documentation/hardware/raspberry...
About the only way to make a device with an LCD is to use the built-in HDMI.
https://github.com/anholt/linux/wiki/Raspberry-Pi-and-other-...
This is a theme with the RPi. They generally implement new hardware in their proprietary firmware first, for lack of skills/time to do a proper upstream job of it (or the convience of copy-pasting some vendor code), then pay someone to develop an open-source driver. For example, here is a massive 80 patch series nearing merge for the new display pipeline in the RPi 4:
There is a little thing called Google... ;-)
Device Tree and other things help with this, although you do still require certain BLOB's to access the GPU and other features.
https://github.com/librerpi/rpi-open-firmware https://github.com/itszor/vc4-toolchain/issues/7
The 4’s hardware support is still being merged upstream last I heard though, so the easy way for that is still to use the Foundation’s kernel (which is what Ubuntu does, probably to also make overlays work as expected).
The Foundation's charitable objective is education, so sure, it's not necessary, but there really seems to be no reason for it to be closed - I suppose it's just 'closed by default'?