Re: [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)
On Tue 17/04/12 04:53 , Peter Stuge peter@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.
-
Xavi Drudis Ferran