From: Luca Ceresoli <luca@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC 00/15] Automatically produce legal compliance info
Date: Wed, 01 Feb 2012 22:47:59 +0100 [thread overview]
Message-ID: <4F29B30F.303@lucaceresoli.net> (raw)
In-Reply-To: <CAAXf6LVW_4J-aqqRx1DemP42dLnZbBFnGoiPBSa89QmN0E6yoA@mail.gmail.com>
Yann, Thomas,
thanks for your follow-ups.
Thomas De Schampheleire wrote:
>>
>> However, I can see something missing for GPL/LGPL packages. GPL/LGPL states
>> that you must also provide "the scripts used to control compilation and
>> installation of the executable."
>>
>> Which means that, for packages such as Linux, busybox and uClibc (maybe
>> others as well), the associated .config file should be bundled as well.
>>
>> Also, the config/build/install instructions for each GPL/LGPL package
>> must be provided. This could probably be done by bundling the buildroot
>> sources too in output/legal-info/sources/, or by leveraging the package
>> infrastructure to output the executed commands for every packages.
>>
>> Also, for packages that get patches applied by buildroot, you must make
>> sure that the tarballs for those packages do contain the pathced code,
>> or that the patches are bundled as well. From what I see, you currently
>> only copy the downladed tarballs. Of course, if buildroot is also copied
>> to the output/legal-info/sources/ the patches will be there.
>
> I agree with Yann: I think we should package buildroot itself as well.
>
> In fact, I think we should:
> - make distclean
> - create the manifest
> - download all needed sources
> - run a pre-legal-package script for customization
> - create a .tar file with the whole
>
> The pre-legal-package script (whatever the name) is similar to the
> post-build script, and allows projects to modify certain things. For
> example, modify the defconfig to disable some proprietary things that
> are not useful or usable by the customer.
>
> Also, I think the DL_DIR setting should be modified so that it points
> to the location where the source tarballs are downloaded. This way,
> the customer can directly use these sources from that location when
> re-building buildroot.
>
> I haven't done a technical review of your patches, but I went through
> them and agree with the principle. Thanks for posting them before the
> developer day, it will certainly help the discussion!
I think the best way is to just package BR itself in the legal-info
subdir. I'll have to check if/how it is feasible.
I'd also copy the current .config, which IMHO is part of the "scripts
used to control compilation".
OTOH I don't think a pre-legal-package script would be a good idea, as
it would easily allow to trick and create a fake GPL-compliant release.
In other words, what I use for building must go directly in the stuff
to be released.
Luca
next prev parent reply other threads:[~2012-02-01 21:47 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-29 15:11 [Buildroot] [RFC 00/15] Automatically produce legal compliance info Luca Ceresoli
2012-01-29 15:11 ` [Buildroot] [RFC 01/15] legal-info: new target to echo basic per-package legal info Luca Ceresoli
2012-01-31 17:15 ` Arnout Vandecappelle
2012-02-01 21:07 ` Luca Ceresoli
2012-01-29 15:11 ` [Buildroot] [RFC 02/15] legal-info: produce a manifest file with licensing info Luca Ceresoli
2012-01-31 17:25 ` Arnout Vandecappelle
2012-02-01 21:29 ` Luca Ceresoli
2012-02-01 22:15 ` Thomas Petazzoni
2012-02-02 7:41 ` Thomas De Schampheleire
2012-01-29 15:11 ` [Buildroot] [RFC 03/15] legal-info: save source tarballs for all packages Luca Ceresoli
2012-01-31 22:10 ` Arnout Vandecappelle
2012-02-01 21:38 ` Luca Ceresoli
2012-01-29 15:11 ` [Buildroot] [RFC 04/15] legal-info: do not copy sources for proprietary packages Luca Ceresoli
2012-01-29 15:11 ` [Buildroot] [RFC 05/15] mpc: define license Luca Ceresoli
2012-01-29 15:11 ` [Buildroot] [RFC 06/15] linux: " Luca Ceresoli
2012-01-29 15:11 ` [Buildroot] [RFC 07/15] m4: " Luca Ceresoli
2012-01-29 15:11 ` [Buildroot] [RFC 08/15] busybox: " Luca Ceresoli
2012-01-29 15:11 ` [Buildroot] [RFC 09/15] bzip2: " Luca Ceresoli
2012-01-29 15:11 ` [Buildroot] [RFC 10/15] directfb: " Luca Ceresoli
2012-01-29 15:11 ` [Buildroot] [RFC 11/15] iostat: " Luca Ceresoli
2012-01-29 15:11 ` [Buildroot] [RFC 12/15] lzop: " Luca Ceresoli
2012-01-29 15:11 ` [Buildroot] [RFC 13/15] tslib: " Luca Ceresoli
2012-01-29 15:11 ` [Buildroot] [RFC 14/15] foobar: create a fake proprietary package (testing only) Luca Ceresoli
2012-01-29 15:26 ` Diego Iastrubni
2012-01-29 15:50 ` Michael S. Zick
2012-01-29 16:08 ` Diego Iastrubni
2012-01-30 11:51 ` Luca Ceresoli
2012-01-29 15:11 ` [Buildroot] [RFC 15/15] Create a test config " Luca Ceresoli
2012-01-31 7:15 ` [Buildroot] [RFC 00/15] Automatically produce legal compliance info Arnout Vandecappelle
2012-01-31 22:27 ` Yann E. MORIN
2012-02-01 15:25 ` Thomas De Schampheleire
2012-02-01 21:47 ` Luca Ceresoli [this message]
2012-02-02 8:32 ` Thomas De Schampheleire
2012-02-02 9:27 ` Luca Ceresoli
2012-02-02 11:19 ` Thomas De Schampheleire
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F29B30F.303@lucaceresoli.net \
--to=luca@lucaceresoli.net \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox