----- Original Message -----
> From: "David Hendricks" <david.hendricks@gmail.com>
> To: "Timothy Pearson" <tpearson@raptorengineering.com>
> Cc: "coreboot" <coreboot@coreboot.org>
> Sent: Saturday, August 31, 2019 7:08:55 PM
> Subject: Re: [coreboot] Web site revamp

>> If people are not aware of the ME, PSP, AGESA, FSP, BinaryPI, and a host
>> of other proprietary components, they naturally take the statements above
>> at face value and assume that installing coreboot on their machine (or
>> paying for coreboot support for their system) allows them to replace the
>> entire proprietary firmware with an auditable, fast, secure OpenSource
>> firmware.
>>
>
> If people are confusing coreboot with ME, PSP, AGESA, FSP, BinaryPI, etc.
> then that is indeed a problem.
>
>
>> One of the problems as I see it is that coreboot is really two different
>> projects with two different goals right now, under the same label.  One is
>> the native init project, which at the moment is only viable for RISC-V,
>> POWER, and certain ARM SoCs.  The other is the open glue project for vendor
>> binaries, which is not well understood at this time among much of the open
>> source community, but seems to have significant support from vendors like
>> Google, Intel, and AMD.
>>
>
> I don't see the latter as a project goal, it's just something that enables
> coreboot to be used in non-libre platforms.

I think you've touched on the heart of the problem here.  What exactly does "using coreboot" mean?  As an analogy, if I use WSL (which exposes Linux-like interfaces but is actually a proprietary NT kernel under the hood) am I really "using Linux"?  To purposefully go to an extreme, if a vendor comes up with 128MB of proprietary firmware that calls ~10 lines of coreboot code in the end to handoff to an OS, is that "using coreboot"?

From a business perspective I see severe trademark dilution in an attempt to cater to non-libre platforms.  Is this the direction we want to go?  From our side at Raptor, if coreboot becomes synonymous with proprietary firmware / glue, we'd need to seriously reconsider our promotion / association given our focus on fully open / owner controlled computing (note this is not intended as a threat in any way, I'm simply trying to highlight that going to one extreme to capture x86 platforms as "coreboot" may make coreboot itself unattractive for open platform vendors).

>
>> Complicating matters, the trademark "coreboot" is currently known to some
>> members of the public as a trusted (albeit limited in compatibility) fully
>> open source replacement for their exiting board level firmware.  When the
>> word "coreboot" is used, very few people think of the glue project.  Do we
>> want to dilute / shift the coreboot trademark / branding to the glue part
>> of the project, or do we want to somehow reserve "coreboot" for the native
>> init part of the project?
>>
>
> Similar points have been made about Linux supporting binary modules. I'm
> not convinced that conflating the project's openness with that of
> third-party modules is helpful.

From where I sit, Linux can get away with it because the ratio of open code to binary modules is so high, and has remained extremely high with no indication of significant change.  I'd argue that this hard-to-reach goal being attained for so long is reflective of excellent leadership from Linus and the other folks in charge of Linux.

> The heading could read something like "Flexible, open source frameworks for
>> system firmware"
>>
>> and the detailed description could read "coreboot is an extensible
>> firmware platform that aims to provide a minimal boot environment for
>> modern computers and embedded systems.  As an Open Source project it
>> provides a flexible framework for insertion of vendor specific firmware
>> modules, and on open ISA platforms aims to provide a fully open, auditable
>> boot process with maximum control over the technology."
>>
>
> Adding the word "framework" somewhere in there could be useful. I'm don't
> think the rest needs to change, at least not much. The goal is always to
> provide maximum openness, auditability, and control. The hard part is
> conveying that one cannot achieve this goal 100% on many platforms
> (especially in the x86 world).

Where I take issue still is that we're nowhere near 100%.  On modern platforms we're somewhere below 50% and oftentimes well below that.  The wording is confusing and misleading as-is.  Another bad analogy: if I start a project for "maximum control" of an airliner, but the reality of the situation is the best level of control I can ever attain is how far back my seat reclines, then the wording is purposefully grandiose, opaque and (IMO) rather weasel-worded to make it sound like the project is doing something far more than it can ever accomplish.  Do we really need to stoop to this level with coreboot?  What is to be gained by hiding the reality of the situation from non-technical users visiting the website?
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org