Re: License text in finished built toolchain?

[Michael Hope <michael dot hope at linaro dot org>]

On 24 April 2012 05:19, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Per, All,
>
> Firts off, the usual disclaimer: I am not a lawyer, you should consult a
> competent lawyer and/or your company's legal departement for definitive
> advice.
>
> On Friday 20 April 2012 10:16:00 Per Arnold Blaasmo wrote:
>> If I use Crosstool-ng to build a GNU Toolchain and redistribute that
>> with my own product.
>>
>> Do we need to have the license files in the finished build tree?
>
> That's my understanding that the license texts for GPL and LGPL components
> be made available alongside with the distributed binaries. The same goes
> with the license texts for the BSD-like components.
>
> Whether you want to include these license texts in the same archive (a
> tarball or any other packaging of your choice), or as files residing
> side-by-side with the distributed archive, is up to you to decide.
>
> I for one would suggest that you bundle in the same archive, because:
> ?- you have the guarantee that the recipient of the archive does get
> ? ?the license texts, without requiring additional downloads;
> ?- if you distribute the archive on a physical medium, you are sure
> ? ?that the license texts wil actually *be* on the distribution medium;
> ?- the license texts will follow any subsequent distribution of the
> ? ?archive, if the recipient chooses to do so.
>
>> Should crosstool-ng copy those in to the finished tree?
>
> That's my opinion that crostool-NG should *not* do that automatically
> for you. There are a few reasons for my position:
> ?- you and/or your lawyer have to fully understand the licensing terms
> ? ?of each component, and decide and your own what those licenses imply;
> ?- some components are multi-licensed; for example part of gcc are
> ? ?GPLv3+ while some other parts are LGPLv3+;
> ?- the licensing terms for a specific component may vary with the
> ? ?version of this component; for example gcc 4.2 and earlier were GPLv2+
> ? ?and LGPv2.1+, while gcc 4.3 and later are GPLv3+ and LGPLv3+;
> ?- the licensing terms may change depending on the options you used
> ? ?when building the toolchain (I do not have a example coming to mind
> ? ?right now);
> ?- you anyway have to make available the complete and corresponding source
> ? ?code for the components that are used in the toolchain (at least those
> ? ?that are under copyleft licenses, such as GPL or LGPL).
>
> So, in theory, crosstool-NG *could* copy some of the license texts for you,
> but you would always have to manually check that the correct licenses have
> been copied, and that nothing was missing, and that a license text that does
> not apply was not copied.
>
>> What about crosstool-ng's license?
>> Do we need to add that to the finished built toolchain?
>
> This is a tricky question.
>
> The toolchain is generated by crosstool-NG, so the license of crosstool-NG
> does *not* apply to the toolchain (the same way that the license of gcc
> does not apply to the binary generated by gcc).
>
> However, the license of crosstool-NG explicitly states that crostool-NG is
> what the GPL names "scripts used to control compilation and installation
> of the executable." In my understanding, for example in the gcc context,
> this sentence applies to the scripts used to build gcc. I believe that
> crosstool-NG is what the GPL refers to in the sentence quoted above.
>
> So, it is my understanding that, if you distribute a toolchain built with
> crosstool-NG, you have to pass the complete and corresponding source code
> for the crosstool-NG you used to build said toolchain.
>
> Also, it is my understanding that the crosstool-NG's .config file is part
> of the afore-mentioned scripts, and that you have to distribute it as if
> it were part of crosstool-NG. This is already done automatically for you
> by crosstool-NG, which installs the script bin/<tuple>.ct-ng.config in
> the toolchain install directory.
>
> Also, do not forget that some components in the toolchain may also use a
> .config-like file; for example uClibc has a .config file, so you must
> provide it along with the uClibc sources, and eglibc can use config files
> which you also must provide with eglibc's sources.
>
> So, with respect to crosstool-NG, I would suggest that you put the archive
> of the crosstool-NG you used, prominently side-by-side with the archive
> of the toolchain you distribute.
>
> You may of course decide to distribute a single archive with everything in
> it:
> ?- the toolchain, in binary form
> ?- the crosstool-NG sources
> ?- the crosstool-NG's .config
> ?- the components' complete and corresponding source codes
> ?- the many license texts

For reference, we distribute:
 * The binaries themselves
 * A tarball holding all source tarballs used in the build
 * The crosstool-NG scripts used to build them
 * A README that covers reproducing the binaries using the source
tarballs and build scripts
 * Enough information to reproduce the build host
 * The full license text of all licenses as a page in the installer

We handle the .config problem via samples: the
'linaro-arm-linux-gnueabi' sample holds the config used to build the
binary.

See:
 https://launchpad.net/linaro-toolchain-binaries/+download

We should start including the licenses in $doc as well.

-- Michael

--
For unsubscribe information see http://sourceware.org/lists.html#faq