Raspberry Pi Zero 2 W

I've tried to find the record of that rejection, the closest I can find is http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037106.html - none of your other commits seem to have any replies?

As I said, I'm willing to pursue stuff with Phil, but I need to know who I'm trying to satisfy. Personally I'd prefer to have whomever is specifically raising the objection communicate directly with Phil to work this out though.

My goals are not specific to the Pi Zero 2, but that repository is highly beneficial for all Pi devices for technical reasons - such as VHT80-capable clm_blobs - that "minimal" 43455 blob isn't useful for my application, but one could easily argue that it would be a sensible default for OpenWRT since a lot of people are probably running in AP mode.

I have a pile of local commits that I'm eventually going to upstream (need to pursue formal authorization with management and legal to submit stuff developed on company time), I really don't want to have the RPi-firmware repo also on the list.

I've been told not to publish it in a private message. I asked the person to NAK the patch, the response was "no, I do not touch brcm shit".

WOW. I can understand that attitude in general, but it's BS in this case since it's a Pi product, given that the Pi Foundation have singlehandedly advanced the state of Broadcom FOSS support by years.

In my case "I do not touch brcm shit unless it's a Raspberry Pi product".

But even for non-Pi brcm stuff, I would not pull a stunt like rejecting a patch but refusing to go on record as to why. That's utterly ridiculous. If this person doesn't want to touch "brcm shit", then they should actually NOT touch brcm shit and get out of the way of efforts by others to do so. I dislike Broadcom, but not so much that I'd go out of my way to sabotage the efforts of those who want to work with their products - ESPECIALLY in this case because they're basically saying the Pi Foundation's efforts to open up Broadcom deserve no consideration.

Licenses are one of the things that would allow ridicolous amounts of legal trolling to happen so you don't run on assumptions and make exceptions to the rules that actually try to provide some form of protection from them.

OpenWrt does not need to support raspberry pi or any other specific piece of hardware, and is usually more important to safeguard the project as a whole vs supporting something new

1 Like

I'm not making an assumption.

There is a published license for the file, and not one person has published a legitimate concern about said license, or any concern for that matter about the contents of the license itself. The person who killed the effort won't even publically do so. (I have a suspicion who it might be...)

Just some ridiculous belief that somehow, just somehow, the license file for those files doesn't actually apply to those files. To come to such an insane conclusion requires some seriously outlandish mental gymnastics.

Edit: There is a small potential concern regarding Broadcom vs Cypress due to the IP for some of BCM's WLAN products being sold off to Cypress. This has come up a few times elsewhere and it's messy. I've submitted a request for clarification as an issue on the correct respository.

You mean a text file written in an unoffficial repo?

Stintel said multiple times that the repo is not official. Not official means that whatever is on it may be fictional or stolen. That's a valid concern about the license, and the raspi foundation should know better at this point than do this gray area nonsense, this isn't their first product.

You answered him by pointing out his email address in the commits, which is quite frankly comical. I can make commits to my git repos as Mark.Zuckerberg@raspberrypi.org too. It means nothing, it's a git setting you can change on the local repo and then push stuff to Github. If you own the repo you can be whatever you want on it.

It's not like sending an email where you can't send an email from a domain you don't own (you actually kinda can with some effort, which is why serious email stuff is using GPG signatures, but I digress).

Also the fact that he works for raspi foundation and is a mod in their forums means nothing. That's not what makes stuff official and you kinda know this.

You literally also said yourself you don't like having to use that repo

I have a pile of local commits that I'm eventually going to upstream (need to pursue formal authorization with management and legal to submit stuff developed on company time), I really don't want to have the RPi-firmware repo also on the list.

so why are you so strongly advocating for OpenWrt devs to use it? It would seem like you are trying to get someone else to solve your problems.

Don't look at me, I'm just a wiki admin, if I had the power to command devs around like that with a quick PM from the shadows this would be a very different place.

That said, yes there are some butthurt people and other people that shouldn't take orders from them, but this is just one more reason to get the raspi foundation to do their part and publish firmware in a way that these kinds of people can't find anything to stop you.

1 Like

No, a text file in an official repo that is pointed to by Raspberry Pi Foundation employees whenever someone asks them what the official repo is.

Stintel was dead wrong multiple times with his statements that the repo is not official. It IS official.

They already have. In their official repo, with a license attached.

I've already stated multiple times why upstreaming to linux-firmware is undesirable - because the linux-firmware team makes it clear they only accept generic (read: cripppled) worldwide blobs. While the latest RPi 43455 commits make it clear that BCM43455 firmwares are not just board-specific, but are application/usecase-specific due to RAM limitations.

No, I never said such a thing. Unless you're misinterpreting my comment that I don't like having to manually grab from that repo and override files, or keep a local patch to point to it that is rebased repeatedly against master.

Edit: Yup, you didn't even bother to read what I wrote. Bolded my clarification.

That repo is as official as it gets. If you want to keep making the ridiculous assumption that it is not:

https://www.raspberrypi.com/software/ - go flash an offficial OS image and find me one BCM43455 or BCM43456 blob that cannot be traced back to that repository.

Edit: Just to indulge you:

adodd@censored:~/Downloads/mnt/lib/firmware/brcm$ md5sum ~/gitrepos/firmware-nonfree/debian/config/brcm80211/brcm/brcmfmac43455-sdio.bin
c4f0aa9d18c0f9dea70b0d75a708638c  /home/adodd/gitrepos/firmware-nonfree/debian/config/brcm80211/brcm/brcmfmac43455-sdio.bin
adodd@censored:~/Downloads/mnt/lib/firmware/brcm$ md5sum brcmfmac43455-sdio.bin
c4f0aa9d18c0f9dea70b0d75a708638c  brcmfmac43455-sdio.bin

Requires rewinding the repo by a few commits due to that blob being updated on November 17 in the official repo, and the last image release being October 30 - but the official images are getting their firmware blobs from that repo, just like the Pi Foundation's employees said they were.

Edit: If that isn't the official repo used to generate official images, despite having multiple Pi Foundation employees stating that it is official, and the firmware blobs in their official OS images on their downloads page being an exact md5sum match, please tell me - what is? I'm fine pointing to that if you can provide an actual answer. You keep on insisting that it's not an official repo - prove it by providing the URL of the "alternative" official repo from which the official images distributed on their official website are pulling their files.

Oh yeah, also:

You clearly don't work in corporate America. I do. If Phil were not fully legally authorized to be distributing these files, he would have been fired years ago for NDA violations, or at the very least, had his access to any Broadcom or Cypress IP revoked.

if it is an official repo then why it is not in the list of official repos listed on their website? https://www.raspberrypi.org/github/

pointed to by Raspberry Pi Foundation employees whenever someone asks them what the official repo is.

the word of employees isn't the word of the company. To be official it needs to be on material published under the company name/domain/logo like the website, the documentation, and so on. It's appalling that I need to explain this, but here we are.

Stintel was dead wrong multiple times with his statements that the repo is not official. It IS official.

They already have. In their official repo, with a license attached.

That repo is as official as it gets

the argument here is that some people think this repo isn't official, answering with "yes it is official" or variations thereof is not a valid rebuttal.

I've already stated multiple times why upstreaming to linux-firmware is undesirable

From what I understand, (ignoring the "fk broadcomm" PM thing, as all raspberry pis so far have been merged regardless of this person's opinion) the main requirement here is that the repo gets some form of official recognition (i.e. it goes in the main website in the place I mentioned above, for starters) or they move that repo under their officially recognized github organization, here https://github.com/orgs/raspberrypi/repositories?page=1

You literally also said yourself you don't like having to use that repo

No, I never said such a thing.

Well you did, but OK, you didn't say that because you kinda know that "works for raspi foundation and is a mod in their forums means nothing", but just because it's annoying to maintain a patched tree.

go flash an offficial OS image and find me one BCM43455 or BCM43456 blob that cannot be traced back to that repository.

How do you define "trace it back" to that repository? Yes hashes are the same but that just means someone has taken the same files and hosted them somewhere. I can git clone that repo and re-upload it as mine, does not mean I can re-license their binaries as GPLv2.

You mean you see the source of their build system pulling files from it? That would be better than nothing (better than the git committer's email for the very least) but it is still kind of weak evidence.

prove it by providing the URL of the "alternative" official repo from which the official images distributed on their official website are pulling their files.

Not sure why you assume they must be in a public repo.
What about internal shared folders or internal repositories? Because in a lot of embedded devices the firmware blobs can be extracted by the firmware (obviously) but there is no repo anywhere for them, and they are not in the GPL code drops (also obviously).

You clearly don't work in corporate America. I do.

raspi foundation is in the UK, and even then, I've seen my share of random stuff getting posted or bundled with source drops then retconned a while later when legal finds out what has actually happened and scrambles to protect the company's IP

1 Like

my understanding(assumption after 12+ months of trying to obtain the latest and greatest firmware blobs as a mere downstream user) is that that repo is 'officially grey' or 'officially not official'

if their forum is to be treated as bonafide official proof, then google drive is also a source for raspberry-pi foundation (approved/official?) blobs... :eek:

the maintenance burden on these boards is intensive... unclarity on upstream is one part of that... and I think having reservations/needing clarification or more stable, reliable, consolidated and clear upstream resources is an extremely valid argument/question before taking on more...


sidenote: "phil is the licence holder" and "ask phil" are really poor ways to manage a companies/hardware support for something people have purchased... i'm not sure there is another device in the world with this much distribution where we must reference/refer to a single person for 'official' responses...

is it time that they hire more people/rectify this?


the fact that they sell hardware AND distribute raspiOS's means they have skin in the game, and has contributed alot to the greyness above...

(unless you appear to be a source of revenue, don't bother asking a question about another OS on the pi-foundation forum pretty much the case for github also...)

OpenWrt has been responsible for $100,000AUD+ in rpi4 sales in the past year... i'd say this justifies more action on their behalf...

1 Like

you mean unless you are a "source of lost revenue".
Even if they do nothing, people will still buy rpi to run OpenWrt on it, therefore they don't really need to do much about any request.

1 Like

I've reached out to Phil to request clarification on documentation and an answer on why traceability to RPi-distro is so bad. I think this may be partly an artifact of the Raspbian->Raspberry Pi OS transition... It seems like historical Raspbian releases have been retconned to be Pi OS at https://en.wikipedia.org/wiki/Raspberry_Pi_OS - the whole Raspbian->Pi OS thing is as clear as mud...

As to Google Drive - they make it pretty clear via multiple statments that anything posted in Drive is an early test firmware (release candidate not formally released). It gets committed to RPi-distro/firmware-nonfree when formally released, and then at some point (TBD) a Debian package gets rebuilt and uploaded to http://archive.raspberrypi.org/debian/pool/main/f/firmware-nonfree/ - the contents of http://archive.raspberrypi.org/debian/pool/main/f/firmware-nonfree/firmware-nonfree_20210315-3+rpt3.debian.tar.xz are an exact match to commit b3eec612566ca08913f0830d299f4df70297428f of RPi-distro/firmware-nonfree (with the exception of some symlink-derived oddities...)

For those who object to pulling straight from RPi-distro/firmware-nonfree because of insufficient traceability, is pointing to tarballs http://archive.raspberrypi.org/debian/pool/main/f/firmware-nonfree/ official enough? https://www.raspberrypi.com/software/operating-systems/ points to official operating system images, and the contents of /etc/apt/ in those images point directly to http://archive.raspberrypi.org/debian/ as the official package repository. That's unambiguous traceability as an official repository.

1 Like

They have yet to provide a single shred of evidence to back up their claim that the repo is not official, in direct conflict with large amounts of evidence that it IS official:

https://www.raspberrypi.com/ has a "Forums" link at the top, which links to https://forums.raspberrypi.com/

https://forums.raspberrypi.com/ has an Announcements section - https://forums.raspberrypi.com/viewforum.php?f=117&sid=2223df669854dd621f8cd3744a82cd78 - normal users are not able to post here, thus anyone with posting privileges here is an official spokesperson for Raspberry Pi Trading. Phil has posting privileges here, thus Phil is an official spokesperson for Raspberry Pi Trading.

Phil, in his role as official spokesperson for Raspberry Pi Trading, has stated that https://github.com/RPi-Distro/firmware-nonfree is the official location to obtain binary blobs

In addition to that, there is ANOTHER traceability route:
https://www.raspberrypi.com/software/ points to official software images
/etc/apt in those official software images points to archive.raspberrypi.org/debian
.debian.tar.xz packages there for firmware-nonfree with +rptN suffixes are exact content matches to the state of the RPi-distro/firmware-nonfree repository at the time the package was created

Ah yeah, like a email account in a third party repo, posts in a forum, and an employee's opinion.

It seems you don't understand the issue here, we are talking of legal compliance, not the fact that this guy is legitimate. He is most likely posting the right stuff, but he is not doing it in the right way for other projects that care about legal compliance.

As the developer said, ask a lawyer, and I'm sure you would get similar answers. This is veeeery gray area, the raspi foundation is hella sloppy, as usual.

Wtf is this? Forum announcement sections are not a legally defined way to determine someone is an official spokesperson, you can't just play logic deduction and assume stuff.

Which if I understand it correctly (you mean they have a copy/snapshot of the whole repo in those tar-gz files? Not just the same firmware binaries that means nothing), it is decent. And at least somewhat proves raspi foundation is using that repo to bundle the firmware in their images.

But just because they seem to use it, it does not mean it's automatically an official repo (OpenWrt for example pulls tarballs from thousands of different projects that are not affiliated with it), so it does not help third parties that want to ensure they are taking firmwares with a real license.

Is that enough for legal compliance? I doubt it.

If that fails your standard for being legally in the clear, then this project should just shut down, because there's nothing whatsoever that is legally binding about Signed-off-by either.

Absolutely nothing about the presence of an SoB line indicates that the developer was being honest when they filled out that line. For example, in my current state - I'd be lying if I submitted any patches related to Raspberry Pi WLAN performance to OpenWRT and filled out the SoB line, because my employment contract says that unless approved otherwise by management and legal, the company owns intellectual property rights to anything done on company time. I have not yet received such approval to upstream things (and at this point I'm seriously considering not bothering to seek it, because the excessive paranoia here clearly shifts the cost/benefit analysis to the point where I can no longer honestly justify to management that attempting to upstream anything will save more time in the long run than the time spent trying to upstream any fixes.), so if I were to fill out an SoB line for anything related to the investigations I've been doing in order to improve the performance and reliability of the support equipment I maintain here right now, I'd be lying. Now the chances that my company would bother suing over a bunch of small bugfixes is slim to none, but still - the level of paranoia here is such that you should just shut down the project, because to meet your standards of CYA, you would need documentation via certified mail with official letterhead from the employers of every single contributor that they are being honest when they fill out SoB lines in their commits, because they either have management approval or they don't have a clause in their employment contract that makes the company own everything developed on company time (it's rare for people not to have such a clause unless their company explicitly hired them to contribute to external FOSS projects).

I routinely submit requests to a lawyer to legally review licenses so that I can use software at work (our current ISO 270001 process requires any software that is installed on our workstations to have its license reviewed by our legal department - and yes, our OpenWRT internal tools are in a grey area I'm working on de-graying, but I have yet to find a feature in OpenWRt similar to Yoct's license manifest - https://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#maintaining-open-source-license-compliance-during-your-products-lifecycle so that effort is taking quite some time - while OpenWRT is derived from buildroot, it lacks the 'make legal-info' target documented at https://buildroot.org/downloads/manual/manual.html ). Not once have they ever questioned whether the license file for a repository is actually the legitimate license for the files in that repository, like you are doing here.

That is irrelevant, the goal is shifting the blame, not direct identification. The SoB is a signature of acceptance of a contract https://elinux.org/Developer_Certificate_Of_Origin

If you lie when you accept a contract, which you 100% can do with any other contract as well, then any blame for wrongdoings is shifted on you, and not on the project.

Just think about how NDAs work, can you lie in a NDA and then leak the stuff? Yeah sure you can. But with the contract you signed, the company you work for can shift the blame to you, and you get sacked.

The SoB is admittedly weaker since the ID can't be verified. But it's extremely unpractical to require/check/enforce IDs for an opensource project that has thousands of contributors worldwide like the Linux kernel, or smaller projects that have less controbutors but also much less resources.

what did they tell you about that repo?

So you can use whatever repos you want from github, even those that are clearly a leaked SDK from a hardware manufacturer as long as the license file is "OK" (i.e. someone edited it to be ok but it's obviously not the original one)? I know that for closed source the standards are low (I've seen some stuff and I'm just an IT admin), because it's all "protected by obscurity" so I'm not shocked, but in open source world you have to be more weary.

Afaik most packages have license defined in their makefile

and if that is missing (because of specific/nonstandard license) you get a pkg license file
https://github.com/openwrt/openwrt/blob/master/package/firmware/amd64-microcode/Makefile#L19

And this system has been created ages ago https://github.com/openwrt/openwrt/commit/81a3d9ba3104aab63e6b5b9725060f3267b8e4fe

At the moment it's used to add the license info to the package manifest, I don't know if there is a script or make option to make the manifest without compiling the packages too, you probably need to ask this in a new thread in developer section. If there is not one it should be easy enough to add, since the data is there for packages (or can be added).

For example, this is the manifest of the packages https://downloads.openwrt.org/releases/21.02.1/targets/x86/64/packages/Packages.manifest from here https://downloads.openwrt.org/releases/21.02.1/targets/x86/64/packages/

FYI, I drafted a mail to the SFC to ask for advice regarding this matter. I hope to send it out soon, but waiting for review by the liaison officer team.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.