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

[<tgi...@fr...>]

My comments inside.

Quoting "Yang, Fred" <fre...@in...>:
> 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.

This is currently a stopper.  We are not able to provide a source package
that can be build without Java (+ XMLBeans + ... )

{ Note that tianocore is switching to a python based builder so the future is
open.  But we haven't switched to the new infrastructure.  }

> >> 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.

This is of course doable.  But won't fix point 1.

Do you do this for xen x86 ?

> >> 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.

Ok, I will add the license files. (patches are also welcome).

Tristan.