2012-05-17 19:33:00 +02:00
|
|
|
Most of the packages that were used by Buildroot to produce the image files,
|
|
|
|
|
including Buildroot itself, have open-source licenses. It is your
|
|
|
|
|
responsibility to comply to the requirements of these licenses.
|
|
|
|
|
To make this easier for you, Buildroot collected in this directory some
|
|
|
|
|
material you may need to get it done.
|
|
|
|
|
|
|
|
|
|
This material is composed of the following items.
|
|
|
|
|
* The scripts used to control compilation of the packages and the generation
|
|
|
|
|
of image files, i.e. the Buildroot sources.
|
|
|
|
|
Note: this has not been saved due to technical limitations, you must
|
|
|
|
|
collect it manually.
|
|
|
|
|
* The Buildroot configuration file; this has been saved in buildroot.config.
|
|
|
|
|
* The toolchain (cross-compiler and related tools) used to generate all the
|
|
|
|
|
compiled programs.
|
2016-01-28 19:14:59 +01:00
|
|
|
Note: this may have not been saved due to technical limitations, you may
|
|
|
|
|
need to collect it manually.
|
core/legal-info: also save patches
Currently, the legal-info infra only saves the source archive of a
package. However, that's not enough as we may apply some patches on
packages sources.
We do suggest users to also redistribute the Buildroot sources as part
of their compliance distribution, so the patches bundled in Buildroot
would indeed be included in the compliance distribution.
However, that's still not enough, since we may download some patches, or
the user may use a global patch directory. Patches in there might not
end up in the compliance distribution, and there are risks of
non-conformity.
So, always include patches alongside the source archive.
To ensure reproducibility, we also generate a series file, so patches
can be re-applied in the correct order.
We get the list of patches to include from the list of patches that were
applied by the package infrastructure (via the apply-patches support
script). So, we need to get packages properly extracted and patched
before we can save their legal-info, not just in the case they define
_LICENSE_FILES.
Update the legal-info header accordingly.
Note: this means that, when a package is not patched and defines no
LICENSE_FILES, we will extract and patch it for nothing. There is no
easy way to know whether we have to patch a package or not. We can only
either duplicate the logic to detect patches (bad) or rely on the infra
actually patching the package. Also, a vast majority of packages are
either patched, or define _LICENSE_FILES, so it is best and easiest to
always extract and patch them prior to legal-info.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Luca Ceresoli <luca@lucaceresoli.net>
Tested-by: Luca Ceresoli <luca@lucaceresoli.net>
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-07 18:14:33 +02:00
|
|
|
* The original source code for all packages; this has been saved in the
|
|
|
|
|
sources/ subdirectory (except for the non-redistributable packages, which
|
|
|
|
|
have not been saved). Patches that were applied are also saved, along
|
|
|
|
|
with a file named 'series' that lists the patches in the order they were
|
2016-05-07 18:14:35 +02:00
|
|
|
applied. Patches are under the same license as the files that they modify
|
|
|
|
|
in the original package.
|
2012-05-17 19:33:00 +02:00
|
|
|
* A manifest file listing the configured packages and related information.
|
|
|
|
|
* The license text of the packages; they have been saved in the licenses/
|
|
|
|
|
subdirectory.
|
|
|
|
|
|
