Hi Julius,
many thanks for bringing this up on the mailing list.
On 11.06.20 02:05, Julius Werner wrote:
Would it be enough to just create a second repository (3rdparty/restrictive_blobs or something like that) which is not automatically checked out by CONFIG_USE_BLOBS so people can make a separate conscious decision if they want to check it out?
Here is what I suggested somewhere on Gerrit [1]:
I was thinking we could move the current `3rdparty/blobs` to something like `3rdparty/limited_blobs` or `3rdparty/ restrictive_blobs`. And guard it like the `amd_blobs`. Then move anything without doubts about redistribution to a new `3rdparty/blobs`.
I guess this would be a good first step. If we want to further separate the restrictive blobs by their licenses, we can still do that later. However, if it turns out that there is close to nothing to move to the new repository, we could as well just keep the current one and disable its automatic download (and announce that people should stop mirroring it).
Keeping them all in one repository would be inconvenient for anyone who wants to download that repository of course. How bad it would be would depend on the amount of licenses to agree to. And, if one can't agree to a single license that would stop them from downloading, that would be annoying. Still not too hard to work around. I think any decision on that should come from our administrators, as they would be hit by any convenience trade-off.
If it doesn't allow redistribution, we'd have to check if coreboot.org can host such repos (because we redistribute all the time) or if there's some implied license by the licensor (they pushed it for redistribution after all), and if we can mirror it to github.com and other places (or if that's not implied anymore). As coreboot.org maintainers we won't accept a special "redistribution by coreboot.org allowed" type of license: if those bits are _that_ precious, we don't want them.
No, wait, sorry, I never said they don't allow redistribution.
That would have been me on Gerrit. I'm not 100% sure where distribution ends and redistribution starts. But some of the AMD licenses in the old blobs repository are either absolutely limited in redistribution or not redistributable at all (by any meaningful definition of the term). They explicitly limit distribution to be used with the distributors products "that incorporate AMD products". That thing is written for ODMs/OEMs but no-one else. And said distribution would not happen under the terms of the same license but an EULA embedded into it.
I guess what Patrick meant with an implied license is that we could say that AMD is distributing their blobs through coreboot.org to their customers, because AMD pushed it into the repository. But this would definitely end if somebody mirrors the repository on Github, because then AMD is not involved and only the EULA path is left.
This is nothing I would want to have on my servers. And also nothing I would want to mirror by accident.
Same applies to other licenses that I've seen recently, but for very different reasons. For instance one from Intel for Facebook to distri- bute their ME blob [2]. This one also includes an EULA, but kind of lets one choose if they redistribute things under the license or the EULA. Which seems much better than the AMD case, if there wasn't a clause that one is only allowed to redistribute if the recipient agrees to the license. It shifts the blame to the one who shares the blob, so again, I would be afraid to mirror that in public.
There's another concerning one, from Qualcomm, currently under review [3]. This one seems to do much better than those from Intel and AMD. No EULA, and the recipient is responsible to agree, AFAICT. However, there are two things that when put together would make my life harder: * Possession of the files falls under the license. * If one puts a copy on somebody else's computer, they have to be authorized to agree to the license on the owners behalf. If I consider my own employment for instance, and this got merged, I would have to either ensure that the blobs repo is not updated anymore or talk to our legal department before running `make`.
Nico
[1] https://review.coreboot.org/c/coreboot/+/41848 [2] https://review.coreboot.org/cgit/blobs.git/plain/mainboard/facebook/fbg1701/... [3] https://review.coreboot.org/c/blobs/+/41379/