[yocto] can all of the licensing discussion be centralized in an appendix?

[Rudolf Streif]

Scott,

 **
>
> >>
> http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html
> .****
>
> ** **
>
> Yes, I looked at that one but I now noticed that I referenced it
incorrectly. This is the latest version, however, in the revision history
it shows "Revision 1.1, October 6, 2011, Released with the Yocto Project
Release 1.1".

Now, this one
http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html
is
the current one but its revision history shows "Revision 1.1.1, March 15,
2012, Released with the Yocto Project Release 1.1.1".

Ok, now I get how I confused myself successfully. I presume that the first
is the newer one although its revision history suggests otherwise? Would
you mind updating the revision history with something like "Revision 1.2,
WIP, To be released with Yocto Project Release 1.2"?

The latest one does not seem to have a section about writing recipes
anymore at all. Are you planning on putting it back? While the previous one
had a section on writing recipes it did so in a "vacuum". It told you how
to write a recipe but not really where to put it and how to include it with
an image. The latter it explained in the next section about customizing an
image.

The info about the licensing is great and dead-nuts on, however, a reader
new to the Yocto Project would be missing the context. A good add-on to
that paragraph would be that if you omit the md5 parameter in the
LIC_FILES_CHKSUM variable Bitbake will actually spit it out for you which
is in particular useful if the checksum is calculated over a subset of a
license file specified by startline and endline because md5sum won't easily
do that for you.


These are my suggestions:

* Remove 3.3 x32 and 3.4 Licenses from section 3. Section 3 currently looks
a little bit like a kitchen sink. The first two paragraphs deal with build
system components and architecture, x32 then mixes a very specific
technology into it for particular targets, and then Licenses tops it off
with package licensing details. I would dedicate Section 3 to Yocto Project
Build System Architecture only.

* Then I would dedicate a section 4 to Build Customization:
** The first subsection could deal with the most trivial customization
through local.conf: EXTRA_IMAGE_FEATURES, IMAGE_INSTALL_append and
CORE_IMAGE_EXTRA_INSTALL (formerly known as POKY_EXTRA_INSTALL)
** The second subsection should then explain how to create your own layer
within the build environment because before adding any recipe you need to
have a layer to add it to. Mixing your own recipes in with meta or
meta-yocto works but is not sustainable when upgrading to a newer release
of the Yocto Project. And it's good practice too to keep your own stuff
separate.
** The third subsection should then explain how to extend images writing
your own recipes:
*** writing a recipe that includes a base image and then adds more packages:
    require recipes-core/images/core-imabg-base.bb
    IMAGE_INSTALL += "strace"
*** writing an image that inherits from core-image
    IMAGE_INSTALL = "task-core-boot task-core-extended"
    IMAGE_FEATURES += "blabla"
    inherit core-image
** the fourth subsection should then explain how to add your own packages
with your own recipes. Now you already have everything in place: a layer to
add to and a ways of including your recipes with an image. And here we then
also need to explain the licensing stuff because recipes for building
packages won't fly without.
** the fifth section should then just reference the BSP manual for BSPs.

Finally for my concept, we need to find a home for x32. I would put that
under an "Advanced Topics" section which could act as a container for other
stuff too such as multi-lib etc.

Rudi


>
>
> *From:* yocto-bounces at yoctoproject.org [mailto:
> yocto-bounces at yoctoproject.org] *On Behalf Of *Rudolf Streif
> *Sent:* Monday, March 26, 2012 2:52 PM
> *To:* yocto at yoctoproject.org
> *Subject:* Re: [yocto] can all of the licensing discussion be centralized
> in an appendix?****
>
> ** **
>
> >> there's *way* too much coverage of licensing sprinkled throughout.
> >> most people are not going to care about licensing until the time comes
> >> to maybe start distributing their BSP.****
>
>  The ability of collecting licensing information, tracking license
> changes and providing the license information automatically with the images
> and packages for deployment is in my opinion a major feature of Yocto
> albeit underestimated. Most people will only appreciate it once they have
> to deliver that information with a product for the end user. However, it
> starts much earlier, with the recipe.****
>
> ** **
>
> How to include licensing tracking information with your recipe needs to be
> part of the section explaining how to write recipes of the reference
> manual. In both, the current 1.1 and the upcoming 1.1.1, versions of the
> manual the license tracking section is a little disjoint from the sections
> explaining how to add packages/recipes in my opinion. The examples include
> the license tracking info, of course because otherwise the sanity checker
> will not allow building the recipe, but they don't explain that you
> actually need it (unless you use LICENSE = "CLOSED").****
>
> ** **
>
> Since the license tracking and deployment feature follows the rule
> "garbage in, garbage out" the manual cannot stress enough providing the
> correct info in particular when writing recipes for upstream projects.****
>
> ** **
>
> Side note: And nice features for a future release are SPDX info (already
> worked on as far as I know) and providing the license info in
> ${TMPDIR}/deploy/licenses according to the images in ${TMPDIR}/images so
> that one knows what licenses are in use for what image. That would be very
> convenient when building multiple images with different package content.**
> **
>
> ** **
>
> Rudi****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20120326/5da18c64/attachment.html>