[coreboot] coreboot binary policy

[Stefan Reinauer]

* Alex Gagniuc <mr.nuke.me at gmail.com> [151030 18:59]:
> On Fri, Oct 30, 2015 at 9:03 AM, Marc Jones <marcj303 at gmail.com> wrote:
> > It might be a good idea, but that might be too limiting
> 
> I think historically, it has been assumed that everything in blobs is
> open up for RE and modification. There are plenty of examples of
> people reverse-engineering stuff in blobs, and also modifying the blob
> itself [1]. First and foremost, we should protect the project, and
> with that, our contributors.

Alex, I think this is a great suggestion, but as I have explained to you
in person before, from a perspective of reaching a legal agreement this
is almost equivalent (if not more effort) than working on an agreement
to open source that code to begin with. The coreboot project's objective 
is not to reimplement what other people have done, but to change the
industry to create more open computing devices.

That said, if you want to drive an example terms of use with your
employer that fulfills your advanced criteria, you are more than welcome
to do so, and I believe it would serve as a role model in the silicon
industry.

I am happy to help with such an arrangement, and would be even happier
if we could just open source the code in question. But we can take this
offline.

> We can have a process where we might grant exceptions from these
> (proposed) rules to certain non-ISA blobs. For example, we might
> exempt microcode on the basis that (we believe) It's impractical to
> RE, and keeping that avenue open is not of any particular value.

Reverse engineering is impractical in all cases. Specifically this
document is focussing on what BLOBs we can ship in the 3rdparty/blobs
directory, not generally which BLOBs are allowed in coreboot.

In terms of many blobs (like FSP, hint hint), we are not even at the
point where we can redistribute them in 3rdparty/blobs yet. Adding
additional restrictions would, if anything, change nothing at all
(except that our users will have to get their own collection of BLOBs if
they want to participate).

> We can grandfather in existing blobs, or we can have a process where
> we keep them for a while (a year?) while we try to work out
> appropriate licensing terms with the power-that-be of said blob.

I would like to get the existing BLOBs into 3rdparty/blobs first before
we talk about removing them in a year (e.g. FSP, hint hint).

All the best,
Stefan