Thread: [kvm-ia64-devel] FW: Follow up - IA64 uses Open Guest Firmware

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

FYI,
Here is some assessment on on shipping open GFW from
http://xenbits.xensource.com/ext/efi-vfirmware.hg for HVM guests on IA64
environment.
-Fred


Daniel P. Berrange wrote:
> On Fri, Mar 28, 2008 at 10:26:37AM -0700, Yang, Fred wrote:
>> Dan,
>> 
>> This mail is to follow up with
>> "https://bugzilla.redhat.com/show_bug.cgi?id=420421 FEAT: IA64
>> RHEL5.2 Xen to use Open Guest Firmware"  to make it for RHEL5.3.
>> In BZ, we have updated following information in addressing your 3
>> concerns,
> 
>> 1. The build process requires tools which are not part of RHEL-5 eg
>> the XML Beans Java libraries. This means that it is not currently
>> possible to produce an RPM of the firmware source which will build
>>   [Status] open GFW was originally derived from
>> https://www.tianocore.org/.  The build infrastructure is also derived
>> from Tiano core, which is a very unique in its own way.  Can Red Hat
>> release binary GFW (similar to the current RHEL5.2 in releasing Intel
>> proprietary GFW) associated with source code described in item#2 if
>> no short term tool change is available?
> 
> When we ship open source software we need to be able to guarentee that
> the binary and source code we ship are matching. ie, if someone gets
> the 
> source code, they will be able to build it and get the same result as
> the binary we built. This is neccessary for us to comply with the
> terms 
> of licenses such as the GPL. It is also neccessary for our support and
> maintainence procedures - if we patch something to fix a bug we need
> to 
> sure that we are building new updated RPM the same way.
> 
> The way we guarentee this is via our RPM build system. Every open
> source 
> package has a source RPM. This is fed into the build system to produce
> the binary RPM.  As such, we need to be able to build the binary RPM
> using 
> the tools available in RHEL.   We cannot simply ship a pre-built
> binary 
> and a collection of source code. It has to go via the RPM build
> system. 
> 
>> 2. The is no upstream official release. The build instructions are
>> just telling us to take a HG snapshot of the Xen patches, and a SVN
>> snapshot of the EDK sources. There really needs to be a properly
>> versioned, formal release of the firmware - preferably as a
>>   self-contained tar.gz of all the source code [Status] The open GFW
>> site http://xenbits.xensource.com/ext/efi-vfirmware.hg is now also
>> building binary as part of it release now.  Please see Changeset99
>> "Binary for CS 92"
> 
> This is not exactly what I meant. In fact, including and distributing
> the pre-built binary in the efi-vfirmware.hg would be a violation of
> the GPL 
> because you are not including any of the source from the tiancore.org
> Subversion  repository that is used to build it.
> 
> What we require is a single  tar.gz  file containing *all* the source
> code neccessary to build the firmware image - this will be a
> combination 
> of the source from efi-vfirmeware.hg, and the neccessary bits from the
> tianocore Subversion repository in one tar.gz file. This must *not*
> include any pre-built binary images - it must be all source code.
> 
>> 3. The is no clear statement of the licensing of the open source
>> code. I've picked a random selection of source files and found a
>> couple of different license headers - some BSD, some public domain,
>> and some referring to external license files which don't exist. The
>> source will need auditing to make sure its all consistent in terms
>>   of licensing. [Status] The code checked into
>> http://xenbits.xensource.com/ext/efi-vfirmware.hg  should all have
>> <signed-off> by community developers.  This would need Red Hat
>> address/sanitize from legal/license aspect.
> 
> The 'signed-off-by' lines indicate that the developer had the right
> to submit 
> the code. They do not, however, specify the license for files. Most
> of the 
> source code files contain a comment at the top of the file describing
> what license they are under. A number of source code files  do not
> have any 
> comment describing the license. These need to be updated to have
> explicit 
> license information. Second, the complete text of all the license
> should 
> be included in top level directory of the source code. Many of the
> files 
> simply say
> 
> "All rights reserved. This program and the accompanying materials
> are licensed and made available under the terms and conditions of the
> BSD License which accompanies this distribution.  The full text of
> the license may be found at
> http://opensource.org/licenses/bsd-license.php  " 
> 
> It is not sufficient to point to a website URL since this URL / site
> can disappear/change at any time. The actual text of the license
> should be 
> included in the .tar.gz file along with all the source code. There
> seems 
> to be a mixture of GPL, BSD and Apache licensed files, so you'll
> probably 
> need to include multiple license files in the tar.gz.
> 
> This should all the pretty straightforward, since most of the files
> are 
> correct - only a small number are missing comments about their
> license. 
> 
> Regards,
> Daniel.
>>> Red Hat, Engineering, Boston   -o-  
>>> http://people.redhat.com/berrange/ :| http://libvirt.org  -o- 
>>> http://virt-manager.org  -o-  http://ovirt.org :|
>>> http://autobuild.org       -o-        
>>> http://search.cpan.org/~danberr/ :| GnuPG: 7D3B9505  -o-  F3C9 553F
>>> A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|