[resend to mailing list with approved address]
On Tue, Jun 9, 2020 at 6:41 PM Julius Werner jwerner@google.com 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)?
I think creating a separate repository e.g. for the fbg1701 would be a bad idea.
Would separating the mainboard blobs from the others be an idea.
You only need a single mainboard to be in the tree. A mainboard can trigger cloning a specific branch of this repository after warning for the license.
By doing this the mainboard blob would only be checked out when desired.
The bad thing is that the branch will be in the mainboard repo even when not checked out. I am not 100% sure if that will be good enough. What are your ideas about it?
Something else that came to mind is to put the specific files with a "download" license on the server as files and only download them if you approve. The problem is that it is at least much harder to control as it doesn't fit the standard release mechanism.
The other items are mainly related to a specific chipset or vendor. It is more worthwhile to have a separate repository for them.
Best regards,
Wim Vervoorn
-----Original Message----- From: Julius Werner [mailto:jwerner@chromium.org] Sent: Wednesday, June 10, 2020 3:44 AM To: Coreboot coreboot@coreboot.org; Nico Huber nico.h@gmx.de; Angel Pons th3fanbus@gmail.com; Patrick Georgi pgeorgi@google.com; Stefan Reinauer stefan.reinauer@coreboot.org; Ryan Case ryandcase@google.com; Wim Vervoorn wvervoorn@eltan.com; Frans Hendriks fhendriks@eltan.com; Martin Roth martinroth@google.com Subject: Re: Supporting blobs with licenses that you agree to on download
[resend to mailing list with approved address]
On Tue, Jun 9, 2020 at 6:41 PM Julius Werner jwerner@google.com 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)?
Am Mi., 10. Juni 2020 um 03:43 Uhr schrieb Julius Werner < jwerner@chromium.org>:
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
On Wed, Jun 10, 2020 at 12:11 AM Wim Vervoorn wvervoorn@eltan.com wrote:
You only need a single mainboard to be in the tree. A mainboard can trigger cloning a specific branch of this repository after warning for the license.
So I think you're basically just suggesting to use branches instead of different repositories to separate them, but still separate them all individually. I don't think it makes much of a difference, just that branches are usually used in Git to track different versions of the same thing, so I think it might be confusing to use them to track different things instead. I think if we decide that every affected vendor should have their blobs isolated by themselves, we might as well just make them different repositories (unless Patrick has any preferences about what scales better on the infra side there).
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.
No, wait, sorry, I never said they don't allow redistribution. I think it's clear that we can't host them if we can't redistribute them. (Note that blobs with licenses like this are hosted in other projects' big blob repos like https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/... too.)
These licenses explicitly *do* allow unlimited redistribution. It's just that the license text says you're only allowed to download it if you're agreeing to the license (whether that's enforceable in each jurisdiction is a different question, of course). So if anything this is on the downloader, not on the redistributor. Personally, I think this isn't much different than one of those bundled EULAs that say "if you don't agree to this, you must bring the CD back to the store"... but I'm not a lawyer and I can understand that some people may feel more concerned about it, so I'm hoping we can find a solution that allows those people to avoid downloading these blobs unintentionally.
-----Original Message----- From: Julius Werner [mailto:jwerner@chromium.org] Sent: Thursday, June 11, 2020 2:05 AM To: Patrick Georgi pgeorgi@google.com Cc: Julius Werner jwerner@chromium.org; Coreboot coreboot@coreboot.org; Nico Huber nico.h@gmx.de; Angel Pons th3fanbus@gmail.com; Stefan Reinauer stefan.reinauer@coreboot.org; Ryan Case ryandcase@google.com; Wim Vervoorn wvervoorn@eltan.com; Frans Hendriks fhendriks@eltan.com; Martin Roth martinroth@google.com Subject: Re: Supporting blobs with licenses that you agree to on download
On Wed, Jun 10, 2020 at 12:11 AM Wim Vervoorn wvervoorn@eltan.com wrote:
You only need a single mainboard to be in the tree. A mainboard can trigger cloning a specific branch of this repository after warning for the license.
So I think you're basically just suggesting to use branches instead of different repositories to separate them, but still separate them all individually. I don't think it makes much of a difference, just that branches are usually used in Git to track different versions of the same thing, so I think it might be confusing to use them to track different things instead. I think if we decide that every affected vendor should have their blobs isolated by themselves, we might as well just make them different repositories (unless Patrick has any preferences about what scales better on the infra side there).
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.
No, wait, sorry, I never said they don't allow redistribution. I think it's clear that we can't host them if we can't redistribute them. (Note that blobs with licenses like this are hosted in other projects' big blob repos like https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/... too.)
These licenses explicitly *do* allow unlimited redistribution. It's just that the license text says you're only allowed to download it if you're agreeing to the license (whether that's enforceable in each jurisdiction is a different question, of course). So if anything this is on the downloader, not on the redistributor. Personally, I think this isn't much different than one of those bundled EULAs that say "if you don't agree to this, you must bring the CD back to the store"... but I'm not a lawyer and I can understand that some people may feel more concerned about it, so I'm hoping we can find a solution that allows those people to avoid downloading these blobs unintentionally.
[WIM] I think this exactly explains what it is. This is indeed the intention of these licenses. On the other hand, if having those is a problem. It may still be better to find a good solution to solve these type of issues. I was thinking about this again and you're right about the separate mainboard repo with these separate branches. Wouldn't it be better to host blobs with a "dubious" license separately on github and pull them in when needed (and after a warning)? This way they are not part of the coreboot project and we don't spend a huge amount of time on them discussing the license. This github repo is then the responsibility of the board maintainer.
Wim
Hi!
I also consider using branches within the same repository to separate different binaries to be a very bad idea. What if you need some blob from one branch and another form another branch for the same board? Also not having a branch checkout out doesn't imply not having downloaded the data. And having the license in the same repository as the blobs you should only be downloading after having accepted the license reduces that part of the license to absurdity.
Regards Felix
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/
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).
Okay, sounds like we have general agreement on the second repository approach? I don't think we'd want to disable automatic downloading for the primary blobs repository because I think many people value that for convenience. I agree that we can start with a single restricted_blobs repo for now and see if there is a need to split it up further later.
Patrick, any further concerns from your side? If not, would you mind creating a new repository for this? I can write the patches to move blobs and adjust the Makefiles afterwards.
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.
Yeah, upon reading the AMD license a bit more closely I agree the redistribution parts look a bit concerning to me as well. I don't know exactly what we'd want to do with that, but let's please keep that discussion separate from the one about other blobs that only have the "must agree to license when downloading" problem (I am mostly just trying to find a way to get my Qualcomm board supported right now). The amd_blobs already have a separate repo, so I guess someone should clean up the affected stuff from the main blobs repo for now and then we can decide what to do with the amd_blobs repo (maybe we put a big warning on it not to clone and rehost this publicly or something).
Am Mi., 17. Juni 2020 um 02:47 Uhr schrieb Julius Werner < jwerner@chromium.org>:
Patrick, any further concerns from your side? If not, would you mind creating a new repository for this? I can write the patches to move blobs and adjust the Makefiles afterwards.
I will create a repo for the qc stuff (let's discuss the details offline), but also started writing up some clarifications for the blobs repo at https://review.coreboot.org/c/blobs/+/42476
I think in the long term we might do best by having two licenses on blob contributions: their regular license agreement and a download+redistribution license as outlined in the CL. That way the only requirement on their license would be that coreboot users can use it in some way (because otherwise, why ship it?)
It may be good to get the various blob owners on board with such a license so that we can have a single one that allows mere (re)distribution with little effort on their and our part. Could you ask the QC folks if there's interest in sorting this out?
Patrick
I will create a repo for the qc stuff (let's discuss the details offline)
Okay, cool, thank you. Repo is created and I uploaded a patch to hook it up to the build system here: https://review.coreboot.org/42548
It may be good to get the various blob owners on board with such a license so that we can have a single one that allows mere (re)distribution with little effort on their and our part. Could you ask the QC folks if there's interest in sorting this out?
I have mentioned this option to them already but they didn't really pick it up. It seems to be *really* hard for them to make even the slightest changes to any license text (I mean months to just change a sentence or two), so I think the separate repository approach will be the best we can do in the near term. On a scale of years we can keep pointing out the friction caused by this and try to convince them to move to a simpler license like Intel did (but remember how long that took).
This still leaves the fbg1701 blob in the main blobs repository... have you decided what to do with that?
-
Felix Held -
Julius Werner -
Nico Huber -
Patrick Georgi -
Wim Vervoorn