> Clearly, the rules should be the same for all blobs, so if
> some blobs with language like this are already in the repository, it
> shouldn't be grounds to reject new blobs from landing.
It's not unheard of to adapt rules to new realities or to tighten them up to implement what was meant originally and grand-father in violations.
But that only works if we can find an interpretation that doesn't put us all in violation _right now_. In that case, we'll have to remove these binaries (and respin the blobs tarballs of the last few releases).
> If we can come
> up with an alternative that people would feel more comfortable with,
> we should also apply it to those existing cases.
It might be possible to procure statements from the licensors to that end, perhaps something akin to "$licensor grants a license to everyone to download and redistribute the following files in the exact form uploaded to
coreboot.org by the licensor: [list of files with hashes]" that we can simply append to the license text.
> 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?
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.
Patrick
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado