Stojsavljevic, Zoran wrote:
This what I have proposed binds to current Coreboot FSP support/framework
Even though seamless integration of FSP with upstream coreboot is probably what Intel would want that approach is not neccessarily a satisfactory solutoin for the greater coreboot community.
If Intel contributes squaky clean changes for coreboot which add support for the FSP then we can perhaps have further discussion.
//Peter
On Tuesday, February 25, 2014 07:28:04 PM Peter Stuge wrote:
Stojsavljevic, Zoran wrote:
This what I have proposed binds to current Coreboot FSP support/framework
Even though seamless integration of FSP with upstream coreboot is probably what Intel would want that approach is not neccessarily a satisfactory solutoin for the greater coreboot community.
It's the worst solution, and a lot of persons in the community, myself included, are very opposed to anything of the nature. If one wants to use coreboot, then one should be prepared to provide coreboot-quality source. If providing source is not something that person/company wants to do, then coreboot is not for them. There are other options in the market. As a rights holder in the coreboot project, I am of the opinion that distributing coreboot with FSP binaries whose source is not also provided is a violation of the coreboot license and an infringement of my copyright.
We've allowed libpayload to be BSD-licensed in order to allow proprietary blobs. The payload and onward is where blobs can appear without source, but not any earlier. The intention is, in my view, that anything doing with essential hardware initialization --the stuff needed to load a payload and boot the OS-- must come with a GPLv2 compatible license. Anything else is up for grabs in the payload.
Alex
when I've had vendorcode in the past I never brought it into the tree. I used it as a reference for a port. The UEFI code is not something I want to bring in.
ron
Hello Alex,
I tried to provide to you all the best as I could, from my end. Please, do note that I am from INTEL, but I am NOT officially entitled, and my notes are NOT officially covering INTEL opinions and these/mine are NOT INTEL official notes!
I am the guy who does not hide, so my views, as INTELer one, are also important for INTEL inside people. I am trying to push INTEL from my end to be closer to Open Source, and this is why it is important that somebody from INTEL, as very close to Open Source, is giving his/my own opinions, so INTEL(ers)/people from INTEL subscribed to this list can read my notes, and think about them. And I am trying to close this gap... :)
Now, I guess, I gave you quick high level hack - opinion how it all should be done just in order to fulfill in almost zero time some Quark FSP porting to Coreboot. Since you all know that Quark BWG, Quark EDK2 is posted on official INTEL public sites, and are available for grab after some electronics signature to accept the INTEL agreement is provided.
Other than that, I have no problems for you to rewrite the Quark EDK2 PEI code, if agreement says so (I did not read these agreements), but if I were you/Coreboot maintainer, I'll read this agreement to see if this is allowed, and what are terms to do that.
My approach is legally clean, my best guess... And provides to you/Coreboot very quick solution.
About GPL2 contract violation with binary blobs... This is the domain I would like to stay off. I am not lawyer, just trying to maintain my R&D focus. For such stuff, I guess... This is Legal Domain, I refrain from, and not at all entitled to participate in this, from INTEL side, as well as from my personal side.
(Sending from Embedded World 2014, Nuremberg, Germany)
Thank you, Zoran _______ Most of The Time you should be "intel inside" to be capable to think "out of the box".
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of mrnuke Sent: Tuesday, February 25, 2014 8:13 PM To: coreboot@coreboot.org Subject: Re: [coreboot] how to model the Quark architecture
On Tuesday, February 25, 2014 07:28:04 PM Peter Stuge wrote:
Stojsavljevic, Zoran wrote:
This what I have proposed binds to current Coreboot FSP support/framework
Even though seamless integration of FSP with upstream coreboot is probably what Intel would want that approach is not neccessarily a satisfactory solutoin for the greater coreboot community.
It's the worst solution, and a lot of persons in the community, myself included, are very opposed to anything of the nature. If one wants to use coreboot, then one should be prepared to provide coreboot-quality source. If providing source is not something that person/company wants to do, then coreboot is not for them. There are other options in the market. As a rights holder in the coreboot project, I am of the opinion that distributing coreboot with FSP binaries whose source is not also provided is a violation of the coreboot license and an infringement of my copyright.
We've allowed libpayload to be BSD-licensed in order to allow proprietary blobs. The payload and onward is where blobs can appear without source, but not any earlier. The intention is, in my view, that anything doing with essential hardware initialization --the stuff needed to load a payload and boot the OS-- must come with a GPLv2 compatible license. Anything else is up for grabs in the payload.
Alex
-
mrnuke -
Peter Stuge -
ron minnich -
Stojsavljevic, Zoran