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 :|
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home