[coreboot] [SPAM] Re: Binary blobs in the source tree (was: Re: New patchto review for coreboot: e4fc528 Add the memory reference codebinary for sandybridge chipsets)

[Xavi Drudis Ferran]

On Tue 17/04/12 04:53 , Peter Stuge <peter at stuge.se> wrote:
> 
> You imply that you experience a change in direction, but as I tried
> to make clear already in my last email, I do not consider coreboot
> to have changed direction at all. The recent progress is a leap
> forward; as already confirmed by Andrew, coreboot is more valuable
> with Sandy Bridge support.
>

We disagree about change of directions. We agree that the value 
of coreboot is different with or without that blob. I prefer the previous value.
My preference is of no particular concern since I don't have commit
rights and tend  to seek consensus more than clearness of my own preferences. 

> > if coreboot starts filling with blobs it will be just another BIOS,
> > only somewhat delayed or playing catchup with some features.
> 
> I'm not sure if you realize how absurd that is. In case you didn't
> notice, coreboot has been playing catchup with all hardware for the
> first 12 years.
>

And I guess it will still play catchup with blobs. When AMD started 
commiting lots of code for their chipsets this didn't magically create
implementations for all the AMD enabled motherboards out there. 
Before the blob, it was a catchuper which had the unique value that was free and could be 
modified and understood. After the blob it won't have this value, 
just like most BIOSes, and will still be a catchuper. It will just 
be trying to catch up with a bigger slice of available hardware.
But I'm playing too much devil advocate. If the blob was free software
the new hardware support would be much welcome.

> You may think that 12 years is a long time for a project, but in fact
> coreboot is only since a year or so, when AMD announced their
> support, starting to grow up, and even then there are many things
> that desperately require your contributions to increase it's success.
>

I want to thank AMD for their support. But I also want to thank all people
that worked in coreboot those 12 years. AMD may not have come without
them. 
 
> OR - you can go to a vendor and pay them for the service of doing it
> on your behalf. Currently there exists no such service for coreboot,
> but the more popular coreboot becomes the more likely it is that such
> a service provider (or several!) will appear.
> 
> YOU have to research details to ensure that YOUR requirements are met.
> 
> Blobs do not change this fundamental fact in any way.

Blobs reduce the set of people able to adapt them to just one party.
Blobs provide functionality that may discourage some people to implement
free alternatives (fortunately you try to compensate by encouraging people to do so). 

>  If there are no
> blobs then your "zero blobs" requirement is very easy to check off
> the list of requirements, while other metrics such as "computational
> performance" or "power consumption" remain exactly as difficult to
> check.
>

If there are blobs you still have to measure performace or power. 
 
> You have no right to spit on coreboot (which is what you say that you
> would do if it became "a blob loader") just because one part of it
> solves problems which you do not want to solve, while other parts
> solve exactly the problems you do want to solve.
>

Sorry. I didn't mean to spit on coreboot, just on some options about
its future. But I didn't mean to spit at all. I just didn't feel commited 
enough to be more polite than some rushed people. Maybe I wasn't
just polite enough. Sorry about that. 
 
> Further, as Ron already pointed out - and as you know from your
> experience with PC bootstrapping, you can't really ignore that many
> coreboot systems already depend on another blob during startup - the
> VGA BIOS. It's not really related to coreboot, but to the way the PC
> platform is expected to work by PC operating systems.
>

Nonfree VGA BIOSes are not distributed with coreboot as far as I know. 
I would have objected just the same to committing nonfree VGA BIOSes.
I wish one can do without them, but I haven't claimed that's possible. 
 
> > it will be like what linux has become, you no longer know much by
> > the statement that linux runs on something. If android is free
> > software
> 
> Who has said that Android is free software? That's stupid. If you
> want to discuss Linux not being free enough then you can always try
> to take it up with Linus.
>

I was just trying to show examples of projects that include free and nonfree 
parts and achieve what you seek: support for more hardware. And  I hinted
at what I don't like from them, that they make really hard to tell free from nonfree apart. 
 
> > Coreboot may choose to go that route
> 
> Third time: coreboot has never changed direction and I do not see any
> reason to do so in the future.
>

Coreboot is not yourself only. It's very likely more yourself than myself, 
but you can't just decide it on your own. And there are other people
objecting, maybe with a better attitude than myself. 
 
> that fit their needs. You can pretend that coreboot actually does not
> support Sandy Bridge and Ivy Bridge at all, and you are still golden!
>

A free software project is some people trying to work together to achieve
some goal. When you use a free software project you have some work
already done for you. Keeping the code free, legaly sound and testing
it with different hardware is an important work that I appreciate in free
software projects. Projects which mix free and nonfree parts and require
users to identify the nonfree parts, learn what they support and pretend 
they aren't there, don't provide this work done and I miss it. 
 
> Indeed it is. What you write is extremely offensive. You are
> disrespecting the magnitude and excellence of the work that has been
> contributed to the coreboot project by the Chromebook team and I just
> find that to be really really poor form, regardless of your reasons.
>

I didn't mean to offend anyone. If I did I apologise. I just want the 
work of all previous committers to a truly free software project 
to be respected. I may be attributing intentions to others, but I'll
have to make do with that until I learn mind reading.

> > Does someone else besides intel and google have permission to
> > distribute the blobs?
> 
> Please see
> http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
> 
> I expect you to actually have solid knowledge of this already, since
> you have already sent contributions.
>

You can rest.
I stand by my sign off. My contribution was a) small b) possibly replaceable
with later code by AMD c) safe to sign off to the best of my knowledge. 
This assumes the code present in coreboot before my changes was legally safe,
since my contribution is a derived work of it, but I didn't do any legal audit
of code already in the repository. 
 
Now that you pointed this out, let me quote that page: 

  License Issues

    * Contributed code must be GPL'd (preferrably 'GPLv2 or any later version', but 'GPLv2' is fine, too). 
At the very minimum the code must have a GPL-compatible license. 

My understanding of a GPL-compatible license is one that in particular
allows anyone with the binary to obtain the source from the distributor.

Mr. Ron Minnich, please, I downloaded 

e4fc5283d5c2e5fe8f75875a8229319696f8990b

and can't find the licence, can you specify which GPL-compatible license 
it is under ? 
Can you please provide the source code ? 

> > coreboot users have usually assumed they had permission to
> > distribute the tree freely under GPL,
> 
> You speak for all of them? I am sure that you realize how absurd
> that is. Noone can claim anything on behalf of "coreboot users."
>

In the same message you linked to a page that demands each 
contribution to be signed off, defines sign off as a process whereby 
the contributor grants or certifies the availability of an open source
license and the open source license is further constrained to a GPL-compatible
license, preferably GPLv2 or later. 

GPL-compatible licenses grant the right to distribute the licensed 
material. By "freely distributing" I meant distributing under some conditions
that keep the software free. In the sense I meant, a tree full of GPL licensed
content can be "freely distributed". By "freely distributed" I didn't mean
unconstrained by the GPL. I'm sorry for any misunderstanding.

Mr. Stuge, can people assume the page you just sent to accurately 
describe this project ? 
 
> 
> Ask away about anything that is unclear!

Thanks. I'm trying. 

> Reality check. Vendors are not fighting each other over who can be
> more compatible with coreboot. For 12 years coreboot has been chasing
> hardware. You need to understand the full impact of this.
>

Reality check. The fact that google wants to buy millions of chromebooks 
and their available firmware does not fit their requirements, so they want to 
use coreboot with a blob for some hardware models will not magically lead 
every OEM to implement coreboot for their systems.
A new system will be added, the legal clarity of the project will be compromised,
and people will still wait for the next volunteer to port a similar board replacing or working
around the blob if the hardware requires it. 
 
> > if you can't even rely on a FSF priority project to get free
> > software.
> 
> As I am sure that you already know, coreboot is not an FSF project.
>

Sorry for writing too loosely. I meant :
"If you can't even rely in a project that appears in the FSF's high
priority projects list to get free software."
See
 http://www.fsf.org/campaigns/priority-projects/

The fact that FSF asked people to help coreboot does not mean 
that coreboot is a FSF project. I didn't mean it. I just meant that
I expected them to ask support only for free software (and I believe
they're not aware of the issue or are waiting for a resolution before
editing that page).

> I will not bother biting on this last piece of flame bait. I am
> confident that you understand that coreboot is more free than your
> other options. If it's not free enough for you at this time then
> please either go away or please help us out. In any case you are
> *NOT* helping by complaining.
> 

Very clear, mister. I hope I can help by asking for license clarification.
That's hopefully more constructive than talking about pride, half-bakeness
or likeliness of future hardware support.