[resend to mailing list with approved address]
On Tue, Jun 9, 2020 at 6:41 PM Julius Werner <[email protected]> wrote: > > Trying to generalize the discussion from > https://review.coreboot.org/c/blobs/+/41379 here. > > Some of the blobs in our 3rdparty/blobs repository have license > language that basically says you have to agree to the license terms to > even download the file, and otherwise you're not allowed to possess > it. Some example language from the fbg1701 license: > > > Do not use or load software from this site or any associated materials > > (collectively, the "Software") until you have carefully read the following > > terms and conditions. By loading or using the Software, you agree to the > > terms of this Agreement. If you do not wish to so agree, do not install or > > use the Software. > > As far as I can tell this affects > 3rdparty/blobs/mainboard/facebook/fbg1701/license.txt and (with > slightly more ambiguous language) almost all AMD licenses (e.g. > 3rdparty/blobs/soc/amd/stoneyridge/license.txt). We're trying to add a > new blob needed to support a Qualcomm platform that comes with similar > language. > > Some people pointed out on that CL that they are uncomfortable with > licenses like this in the blobs directory, since it means they cannot > clone the whole repository without agreeing to all licenses with this > sort of language in the repo (even if they only want to use a > completely unrelated blob). The concern was also raised that this > violates the binary policy (the "unlimited redistribution" part)... I > guess it's a matter of interpretation whether a license that allows > you to redistribute the binary *if you agree to it* is still > "unlimited". It seems that there were already similar concerns raised > when the fbg1701 license landed (https://review.coreboot.org/34441) > but it was submitted despite the unresolved disagreement. > > Can we come up with and implement a solution here that both respects > people's concerns and still allows us to support the affected > platforms? 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. If we can come > up with an alternative that people would feel more comfortable with, > we should also apply it to those existing cases. > > 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? It seems > that something similar to this was already attempted with the > 3rdparty/amd_blobs repository (but it looks like the work wasn't > finished because those blobs are still in 3rdparty/blobs as well?). Is > it enough to put all these blobs into a single separate repository or > do we need to make a separate repository per license (that might be > okay for the big AMD case but it probably wouldn't scale well for > small one-offs)? _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
